Guides

How to Build a Multi-Tenant Odoo Instance

Multi-tenant Odoo (serving many isolated businesses from one standardised platform) is how you turn Odoo into a product: SaaS backends, franchise systems, merchant platforms. We run this in production at 150+ merchants for Insight Technologies SAS, a digital payment provider in the Republic of Congo, and this guide condenses the architecture lessons that scale actually taught us.

Full delivery story: the case study. Service page: multi-tenant deployment.

What it takes in practice

  • Choose your isolation model first. Database-per-tenant gives the cleanest isolation, simplest per-tenant backup and sanest compliance story; it’s what we run at scale. Shared-database alternatives trade isolation for density and are rarely worth it above toy scale.
  • Automate provisioning from day one. Tenant creation must be a pipeline (database, baseline modules, configuration, branding, users) measured in minutes. If onboarding involves a human checklist, your platform economics are broken before launch.
  • Standardise the module set ruthlessly. One codebase, versioned, deployed fleet-wide. Per-tenant custom modules are the death of upgradability; per-tenant configuration within a designed policy layer is how variation stays survivable.
  • Build fleet upgrade machinery. Canary tenants, automated test suites, staged waves, rollback points. Upgrading 150 tenants safely is an engineering product in itself, and it’s the capability that separates platforms from collections of instances.
  • Operate at fleet level. Monitoring, backups, error aggregation and health dashboards across all tenants in one view. Individual-instance operations don’t scale past a dozen tenants.
  • Design the commercial policy layer. What can tenants configure, what costs extra, what’s forbidden: product decisions enforced technically. The platform’s long-term margin lives in this discipline.

Where a specialist earns the fee

This is real engineering, not configuration, and the design decisions matter more than the code. We’ve built these systems at production scale, from real-time WIP accounting carried live across Odoo v15 to v19 to a platform running 150-plus tenants, and the value we add is the judgement to avoid the expensive wrong turns rather than just the hours to type. If the scope here matches something you need built properly, we scope it with a fixed quote and an hours breakdown before anyone commits.

Common questions

What stack surrounds Odoo in these setups?
Containerised instances, configuration management, a provisioning service, centralised PostgreSQL management and monitoring. The exact shape varies; the principles above don't.
How do tenant-specific integrations work?
As configurable options within the standard codebase: tenants enable and configure from a menu of supported integrations. Bespoke per-tenant code is refused by policy, politely.
What does 150+ merchants teach that 10 doesn't?
That everything manual eventually breaks: provisioning, upgrades, monitoring, support triage. Scale converts every casual process into either automation or an outage.
How do you stop one broken tenant affecting the others?
Database-per-tenant isolation, so each tenant's data, backups and upgrades are independent. A problem in one is contained to one, which is why the isolation model is the first decision in the guide.

Not sure where to start? Book a free discovery call and we’ll map your current setup, or request a free Odoo health check if you’re already running Odoo.

Next step

Ready to fix your ops?

Book a free discovery call. We'll look at your current setup and tell you honestly whether Odoo is the right move and what it would involve.