Odoo hosted with your integrator: who does what between the host, the integrator and the client

An integrator's first request is often SSH access "to stay autonomous". In practice, many drop it as soon as the question is looked at seriously. A shell on a Kubernetes platform you do not use every day is the fastest way to make a handling error. And when something breaks, nobody knows who is accountable any more: the host that runs the platform, or the integrator who typed a command on it.

Nobody wants to paste AI-generated Kubernetes commands into production on a technology they do not master, on a Friday evening. The integrator wants to stay in charge of what they know (the Odoo code, the modules, the business data) without having to absorb the complexity of the infrastructure.

So, no SSH access: fewer handling errors, and a clear line between what the host does and what the integrator does.

Giving up SSH does not mean working blind. The integrator needs a few precise actions, and nothing more:

• Restart the Odoo instance after a deployment or a configuration change.
• Read the application logs, to tell whether a problem comes from the code or from the infrastructure before opening a ticket.
• Manage backups: request one before a sensitive operation, get a copy for the staging environment.

In the managed services offer, Bunker scopes these actions with the integrator at quote stage: which ones are open, on which environment, for whom. Access is named and logged. You know who restarted what, and when.

The RACI is the document that prevents arguments in the middle of an outage. Read it line by line: for each topic, who does the work (R), who decides and signs off (A), who is consulted beforehand (C), who is informed afterwards (I). Here is the template we suggest you start from, then adapt to the contract.

Three lines deserve a closer look.

The two kinds of upgrade are separate. Moving from one Odoo version to the next is an application project: data migration, module adaptation, acceptance testing, sign-off by the client. That is the integrator's job. Upgrading PostgreSQL, Kubernetes or the operating system is the host's job. Each consults the other before acting, because an upgrade on one side can have effects on the other.

Qualify before opening a ticket. When Odoo slows down or throws an error, the integrator reads the logs and the host checks its metrics. The ticket goes to the right team, with every party in copy. That avoids the outage that bounces from one provider to another for a whole morning.

Production is only restored with the client's go-ahead. More on that below.

A serious integrator has their own continuous integration chain: they build an image containing Odoo and its modules, test it, then submit it for deployment. Our rule is simple: the image tested by the integrator's CI is the one that goes to production. The host does not rebuild it from the commits. Rebuilding means shipping something other than what was tested, and opening the door to software supply-chain attacks.

In the managed services offer, the typical setup looks like this:

• Two separate repositories. The application repository belongs to the integrator. The infrastructure repository belongs to the host and is read-only for developers: they can see how Odoo is deployed, they cannot change it.
• Pipeline triggers connect the two. When the integrator publishes a validated image, the infrastructure pipeline deploys it, to staging first.
• Staging and production are isolated in two separate environments, with separate storage keys: staging can read production attachments, it cannot write to them.
• Named, logged access, so you know who deployed what.

Your developers do not touch the infrastructure, and the host does not touch your image. Everyone stays in their lane.

On the data side, here is what Bunker's managed Odoo platform does today, as described in the Odoo guide:

• The PostgreSQL database is run by CloudNativePG, with three replicas spread across different zones and automatic failover if a node goes down.
• A full daily backup, plus continuous archiving of the transaction log (WAL), which allows point-in-time recovery (PITR).
• 30-day retention for the database.
• A copy of the backups on object storage located on a different site from production, and an automated restore test every day: a backup only counts as valid if it actually restores.

Copying production to staging. The integrator often needs a recent copy of production to replay imports and data flows. The trap is a staging environment that sends real emails to customers or fires scheduled jobs. In the managed services offer, the copy goes through cleanup scripts that run before staging restarts: outgoing mail servers disabled, scheduled actions suspended, and whatever the integrator decides to anonymise.

Restoring production: only with the client's go-ahead. Restoring the wrong backup prolongs the outage and can wipe out valid entries. The integrator helps pick the restore point, the host runs it, but the client gives the explicit go-ahead. Nobody restores production on their own initiative.

Deploying a new Odoo release causes a brief interruption while the new version starts. Heavier operations (version upgrades, data migrations) are scheduled for evenings or weekends, in slots agreed in advance by all three parties.

Odoo can display a message to its users: use it to warn them before each intervention. It is simple, and it heads off most of the next morning's support calls.

An ERP holds everything: customers, invoices, payroll, contracts. At Bunker, the Odoo instance and its database run on servers located in France, operated by a French company. The platform's building blocks do not rely on any subcontractor subject to US law: PostgreSQL run by CloudNativePG on our own cluster, backups on our own object storage, outgoing email relayed by a German provider. No CLOUD Act, no access by foreign authorities.

And because Odoo Community is licensed under LGPLv3, nothing is locked in: a PostgreSQL export and your modules are enough to take the ERP back onto your own servers.

The standard managed Odoo plan deploys in a few minutes from the console. The model described here, with an integrator, CI, isolated staging and targeted actions, is part of the managed services offer: it is scoped case by case, on quote.

Are you an integrator preparing a hosting proposal for a client? Or the client, wanting your integrator and your host to speak the same language? Let's talk, with your integrator at the table. You can also read the managed Odoo page and our partner programme.