Sovereign Odoo hosting: which model should you choose?

The essentials.

• Three hosting models exist for Odoo: Odoo Online and Odoo.sh, both run by Odoo SA, and hosting managed by your implementation partner, such as DynCloud at Dynapps.

• Odoo Online accepts no third-party modules and limits customisation to Studio and server actions. Odoo.sh accepts code, but shuts workers down when idle, production included.

• On Odoo Online and Odoo.sh, the physical infrastructure is Google Cloud. On DynCloud, data is processed and stored in Belgium, in Combell data centres, within European borders.

• DynCloud runs on a managed Kubernetes cluster, with a recovery point objective (RPO) of 4 hours and backups every 4 hours, plus one daily backup kept for 30 days.

• The decision comes down to three questions: who answers when the infrastructure fails, what you are allowed to install, and where your data lives.

If data sovereignty is one of your criteria, only one of the three models names the country, the operator and the contractual commitment: hosting managed by your implementation partner. Both Odoo SA platforms run on Google Cloud, and their infrastructure is managed by Odoo SA, not by your integrator. This article compares the three models on what they actually allow, and on what they refuse you.

What does sovereign Odoo hosting actually mean?

A sovereign Odoo hosting service is one where you know the physical location, the operator, and the contractual commitments.

For DynCloud, these three elements are specified. The data centres are Combell’s facilities in Diegem and Zaventem, Belgium. Data is processed and stored there within European borders. Combell complies with the GDPR, and the processing of customer and user data follows the customer’s instructions, as outlined in a Data Processing Agreement (DPA). Both Dynapps and Combell are ISO 27001 certified.

For Odoo Online and Odoo.sh, the physical infrastructure is Google Cloud. Odoo SA is also ISO 27001 certified, with SaaS hosting and the Odoo.sh platform included in the scope, and Odoo.sh adds SOC 2 certification. On Odoo Online, backups are replicated across three data centres in Europe and Canada, with a copy stored in cold storage. The architecture is robust. However, the commitment is different: Odoo SA is responsible for managing the infrastructure, and the geographic scope of the backups extends beyond Europe.

A helpful note for French readers: DynCloud is hosted in Belgium, not in France. The promise applies to Europe and to a specific service provider, not to France specifically.

What are the actual limitations of each mode?

The limitations are not due to Odoo, but to what each platform allows in connection with Odoo: the code, network access, resources, and the location of the data.

Eight criteria distinguish the three modes.

Who manages the infrastructure?

• Odoo Online: Odoo SA.

• Odoo.sh: Odoo SA.

• DynCloud: Dynapps, on Combell's infrastructure.

Third-party modules, custom code, and integrations.

• Odoo Online: no third-party modules, customisation limited to Studio and server actions, no software integration.

• Odoo.sh: marketplace modules and custom developments are allowed; full customisation is possible, but system packages are not supported.

• DynCloud: full customisation, third-party modules, and system packages that can be installed via Dynapps.

Worker availability.

• Odoo Online: managed by Odoo SA.

• Odoo.sh: workers are shut down when idle, including in production, and undergo a cold start on the first request after a period of inactivity.

• DynCloud: all workers are kept active at all times, with periodic restarts.

High availability and fault tolerance.

• Odoo Online: automatic failover in the event of hardware failure, virtually no data loss, but no high-availability PostgreSQL.

• Odoo.sh: fault tolerance at the worker level; no high-availability PostgreSQL either.

• DynCloud: automatic fault tolerance, load balancing, and database replication available upon request.

Minor updates to Odoo.

• Odoo Online: automatic updates, pushed by Odoo SA.

• Odoo.sh: released weekly by Odoo SA, with a freeze period of up to 3 months and manual intervention on the client side.

• DynCloud: every 3 months, managed by Dynapps, with an adjustable schedule.

Production backups.

• Odoo Online: 14 backups over 3 months, replicated across three data centres in Europe and Canada.

• Odoo.sh: daily, retained for 7 days, 4 weeks, and 3 months.

• DynCloud: every 4 hours, or 6 times a day, plus a daily backup retained for 30 days.

Network and database access.

• Odoo Online: no VPN, no IP whitelisting, no direct database access, no static IP, and no server access.

• Odoo.sh: same rejections, and a fixed IP address that is only partially fixed, since it can change upon notification via an API call.

• DynCloud: VPN tunnels, IP whitelisting, direct database access, static IP, and server access for configuration.

Data location.

• Odoo Online: Google Cloud, managed by Odoo SA.

• Odoo.sh: Google Cloud, managed by Odoo SA.

• DynCloud: Belgium, Combell data centres certified to ISO 27001.

Odoo Online: simple and closed.

Odoo Online is suitable for businesses that use the standard Odoo Enterprise applications, without any additional code.

The limitations kick in right from the first integration. No third-party modules, no direct connection to the database, no VPN, no static IP, no whitelisting. Customisation is limited to Studio and server actions. Test databases expire after 14 days. And the default email configuration uses Odoo’s servers with an Odoo domain, such as info@client.odoo.com, with the risk of being marked as spam if the configuration is not set up correctly.

Odoo.sh: open to code, constrained by the platform.

Odoo.sh removes code restrictions: marketplace modules and custom developments are allowed, and full customisation is possible.

Three limitations remain, and they have an impact on production. First, workers shut down when idle, even in production: the first request after a period of inactivity undergoes a cold start. Second, minor updates are pushed weekly by Odoo SA, with a freeze period of up to 3 months and requiring manual intervention by the customer. Finally, system packages cannot be installed, and tools that depend on network or database access (such as VPN, ETL, PowerBI on a shared environment, and IP whitelisting) remain out of reach. The IP address is fixed in theory, but it may change; the customer is notified of this via an API call.

As for environments, the staging branch requires a new copy of the production environment every 30 days. And storage is capped at 512 GB for shared hosting customers.

DynCloud: managed, open, and what it asks in return.

DynCloud is a Kubernetes cluster managed by Dynapps, in collaboration with Combell since 2023, featuring automatic fault tolerance, load balancing, rapid restart of failed containers, and both vertical and horizontal scaling.

In practical terms, this provides: direct access to servers and containers for configuration changes, IP whitelisting, PG Agent connections, VPN tunnels, direct proxy access to the database, and specific third-party connections. Resources, including CPU, memory, and disk space, can be temporarily scaled up to handle a monthly bulk reconciliation or an import campaign without disrupting day-to-day operations.

What this requires in return, because this article would be misleading without this section. Minor updates are not automatic: they are managed every 3 months by Dynapps and tailored for complex environments. Email configuration is handled through an external provider, with integration support provided. And responsibility for the infrastructure is shared between Dynapps and Combell, not with your teams. That’s the benefit of this model, but it assumes that this arrangement works for you.

And what about proprietary infrastructure?

Hosting on your own infrastructure remains a fourth option, and the only one that gives you complete control over the environment.

It shifts the burden rather than eliminating it. Backups, Linux patching, certificates, DNS, high availability, and certification become the responsibility of your IT department or IT partner. This is a logical choice when on-premises hosting is a business requirement, not a default option.

How do you size the environment you need?

Sizing depends on actual usage, not just the number of users.

The factors that matter: the number of Odoo users, their profiles (a light user, who only logs their hours, doesn't count as much as a heavy user), the number and type of applications (CRM and Sales alone, or also Inventory, Manufacturing, Accounting and Project management), the presence of an e-commerce shop, integrations with other systems, and the scope of custom development.

There are four levels covering common situations. Recommended usage levels are provided for occasional use, followed by intensive use.

• Small, 10 sporadic users or 2 intensive. Simple sale orders, purchase orders and invoices, low traffic web shop, custom development with limited load impact.

• Medium, 20 sporadic users or 10 intensive. Mainly simple orders and invoices with a few complex ones, medium traffic web shop with a steady flow and no large spikes, custom development with medium load impact.

• Large, 75 sporadic users or 20 intensive. High volumes of simple and complex orders, medium traffic with spikes, large reports to print, regular processing of large data volumes, a large database sped up by caching.

• Custom, dedicated sizing. Custom code with specific requirements, a very large user base, a web shop with high traffic spikes, large data volumes, dedicated resources.

Each stage includes a complete DTAP (Development, Testing, Acceptance, Production) pipeline, meaning four distinct environments, each with its own database, configuration, and code, with the code moving from one environment to the next after validation.

These tiers are for reference only. At the start of a project, the exact requirements are never known: estimates are based on the information available, then reassessed during implementation and adjusted as necessary. Customisations and workload spikes related to your business cycles have a significant impact on the final result.

Why Dynapps?

DynCloud exists because hosting shapes the quality of the implementation, and because depending on a third party in a critical situation slows the response down.

Run with Combell since 2023, DynCloud gives Dynapps complete control of the infrastructure: a faster emergency response, and compatibility with our internal procedures for code validation and release management. The platform is built for co-development, with three parties in the loop: the external developer, Dynapps for code validation and release management, and the client. Dynapps and Combell are ISO 27001 certified.