Why We Don’t Use Docker for Odoo at Cloudpepper (And Why That’s Good for You)

In the world of modern software deployment, Docker has become the undisputed king. It’s the default answer for developers, the cornerstone of CI/CD pipelines, and the darling of DevOps engineers. So, when people look under the hood of Cloudpepper’s high-performance Odoo hosting, they’re often surprised to find we don’t use Docker containers for your production instances.

Instead, we use a battle-tested, “old-school” approach: Systemd running directly on bare-metal servers.

This isn’t because we’re behind the times. It’s a deliberate architectural choice made for one simple reason: Performance and reliability for mission-critical business applications.

While Docker is fantastic for development and testing, we believe the trade-offs it introduces are not worth it for a production ERP like Odoo. Here is why we chose a different path.

The Core Philosophy: Persistent Servers vs. Disposable Containers

The fundamental difference between our approach and a containerized one is often described as “Pets vs. Cattle.”

• Docker treats applications as “Cattle.” Containers are designed to be ephemeral. To update an app, you kill the old container and spin up a new one. They are disposable, standardized, and temporary.
• Cloudpepper treats your Odoo server as a “Pet” (that we manage for you). Your server is a persistent, long-lived entity with its own filesystem, database, and identity. When it needs an update, we surgically upgrade the code in place, preserving everything else.

For a complex, data-heavy ERP system, the persistent model offers significant advantages in stability and performance over constantly churning disposable containers.

The Hidden Costs of Containerization

Docker solves a huge problem for developers: “it works on my machine.”. By bundling dependencies into a single package, it ensures consistency. But in a production environment, this convenience comes with hidden costs.

1. The Performance Tax

The most immediate benefit of skipping Docker is raw performance.

• No Network Overlay: Docker containers typically communicate through a virtual bridge network on the host, which adds a small but measurable amount of latency to every network call.
• No Storage Overlay: Docker uses special filesystem layers (like OverlayFS) to manage container data. While efficient, this is not as fast as writing directly to the host’s NVMe SSD.
• Direct Resource Access: With Systemd, the Odoo process runs directly on the host kernel, with zero abstraction layers between it and the CPU or memory.

For a high-traffic e-commerce site or a backend serving dozens of concurrent users, removing these thin layers of abstraction results in a snappier, more responsive system.

2. The “Official Image” is a Black Box

Many people assume using Docker means using Odoo’s official image. But as experienced developers point out, the official image is far from perfect for production.

• Opaque Builds: The official image is built in a way that makes it difficult to see exactly what’s going on inside. You’re relying on a “black box” build process.
• Configuration Nightmares: Until very recently, you couldn’t configure key Odoo settings using simple environment variables (the standard Docker way). You had to mount complex configuration files, defeating the purpose of “simple” container usage.
• The “Dependency Hell” Illusion: While Docker hides dependency issues inside the container, it doesn’t eliminate them. The official image often relies on downloading .deb packages during build, creating its own form of downstream dependency chain that can break.

3. The Persistence & Permission Headache

The number one issue new Docker users face is data loss. Because containers are ephemeral, if you forget to explicitly map a “volume” for your database or filestore, your data vanishes when the container restarts.

Even when you do map volumes, you run into the infamous Linux permissions issue. The user running inside the container often has a different ID than the user on the host server, leading to “Permission Denied” errors when Odoo tries to save an attachment or read a custom addon.

With our Systemd approach, everything runs as the standard odoo user on a standard Linux filesystem. There is no confusion, no mapping, and no disappearing data.

How Cloudpepper Gives You the Best of Both Worlds

The main argument for Docker is that it solves “dependency hell”: ensuring that a server update doesn’t break the specific Python libraries Odoo needs.

Cloudpepper solves this exact same problem, but without the Docker overhead.

Our platform acts as an automated, expert sysadmin. We use automated scripts to provision your server, create a dedicated virtual environment for Python, and install the exact, pinned versions of every library Odoo requires.

• We get the consistency of a containerized environment through rigorous automation.
• You get the performance of a native, bare-metal installation.
• You get the simplicity of standard Linux tools. If you need to debug something, you don’t have to “exec” into a shell inside a container. You can just SSH into your server and tail the logs in /var/log/odoo like a normal pro.

Conclusion

Docker is an incredible tool that has revolutionized software development. We use it ourselves for testing and building! But for hosting a live, production Odoo database that is the lifeblood of a business, we believe the additional layers of abstraction, configuration complexity, and potential for performance degradation are a poor trade-off.

At Cloudpepper, we choose the proven stability and raw speed of Systemd on bare metal, using advanced automation to solve the problems Docker was designed for. It’s not the trendy choice, but it’s the right one for performance-critical Odoo hosting.