Containerized Odoo Tenancy: How We Isolate 100+ Instances Safely

When you’re building a managed ERP platform, the most critical question isn’t “how many features can we add?” but “how safe is my neighbor?”

In a traditional multi-tenant application, users share a single database and a single application process. If one user triggers a memory leak or exploits a code vulnerability, everyone suffers.

At JengaStack, we rejected the shared-process model. Instead, we use Strict Containerized Isolation. Here is a look at the architecture that allows us to run hundreds of Odoo instances on a single cluster without them ever knowing the others exist.

The Isolation Hierarchy

We isolate at three distinct layers: Network, Filesystem, and Compute.

1. Network: The Traefik Barrier

Each Odoo instance lives on its own internal Docker network. There is no “east-west” traffic allowed between customer containers.

The only way into an instance is through Traefik, our edge proxy. Traefik handles:

• SSL Termination: Automatic Let’s Encrypt certificates per subdomain.
• Path Routing: Directing client-a.jengastack.app to the specific internal container hash.
• Middleware Security: Rate limiting and header sanitization before the request even touches Odoo.

2. Filesystem: Atomic Volumes

Odoo stores attachments (PDFs, images) on the disk. In a shared environment, a misconfigured script could theoretically read another user’s files.

We solve this by mapping each instance to a unique, encrypted directory on the host:

volumes:
  - /mnt/data/tenants/client_a/filestore:/var/lib/odoo/filestore
  - /mnt/data/tenants/client_a/config:/etc/odoo

By the time the Odoo process starts, it only “sees” its own slice of the world.

3. Compute: Resource Quotas

One client running a massive report shouldn’t crash the server for everyone else. We use Docker deploy limits to enforce hard caps on CPU and RAM:

deploy:
  resources:
    limits:
      cpus: '0.5'
      memory: 1G

The Architecture Diagram

Why Not Just Use "Odoo Multi-DB"?

Odoo has a built-in "Multi-Database" mode. It’s great for a single company with three branches. It is dangerous for a SaaS.

• The Global Lock: One long-running SQL query can lock the entire Postgres process.
• Shared Modules: If one database requires a custom module, it must be available to all databases in that process.

By containerizing the entire Odoo process (Python + Addons) per customer, we allow every client to have their own specific module set and own performance profile.

Final Thought

True multi-tenancy in 2026 isn’t about sharing resources—it’s about sharing the control plane while isolating the data.

It’s more work to build, but it’s the only way to sleep soundly at 2 a.m. knowing that a spike in "Client A" will never become an outage for "Client B."

Stop sharing processes. Start isolating value.