Odoo high availability

A high availability design is only proven when each failure has been induced on purpose and the result written down. For a self-hosted Odoo deployment, the test plan should cover six behaviours: a web node stopped mid-session, the load balancer removing an unhealthy node, a PostgreSQL switchover, filestore reads from every node, scheduled actions running once, and a restore to a clean host. Each test needs a defined starting state, a single action, an expected result and a recorded outcome. Run the tests in a staging environment built from the same templates as production, and only after the team has confirmed which replication and backup tooling is in use, since the switchover steps depend on it.

Start with the web tier. While a test user is midway through a form with unsaved changes, stop one Odoo worker process or node. Odoo writes records through database transactions, so a record that was saved before the stop should still be present afterwards, and the user should be able to continue after the session is redirected to a surviving node. Record the time of the stop, the user's session behaviour, the exact fields that were saved and reloaded, and any error text shown in the browser. Repeat the test with a long-polling connection open, because the bus and presence features depend on it and failures there are easy to miss in a basic login check. Also confirm that the load balancer marks the stopped node as unhealthy using the health check configured for it, and that traffic stops reaching the node within the interval you have set.

The database test is the one most likely to expose gaps. Trigger a planned switchover from the primary to the standby, or simulate loss of the primary in staging, while a script posts a known set of transactions such as sales orders and journal entries and records each commit it receives. After the switchover, compare the committed list against the database. Every acknowledged transaction must exist, and any transaction that was not acknowledged must be absent or clearly reported as failed. Then confirm that Odoo reconnects to the new primary without a manual restart of the application. Ask your database team to state the replication mode in writing, because asynchronous replication can lose the last transactions before a failure, and that loss is a business decision, not a test pass or fail.

Two checks cover shared state. First, read attachments and generated reports from every web node and confirm that each returns the same file, using a file that was uploaded through a different node. This verifies that the shared filestore is mounted identically everywhere, and it catches stale caches. Second, check scheduled actions. Confirm that each scheduled action runs once per interval across the cluster, by looking at the logged execution history and at the side effects, such as one invoice reminder email per customer rather than one per node. If duplicates appear, the team must decide how cron workers are assigned before go-live. Record the action names, the expected run count, the observed run count and the node that ran each one.

The restore test proves the backup, not the replication. Restore the most recent backup to a clean host that has no access to production networks, apply neutralization so that outbound email and payment integrations cannot reach live systems, and then sign in with a named test user. Run a small set of key transactions, such as creating a quotation, confirming it and posting an invoice, and compare the results with the source. Record the backup timestamp, the restore duration, the Odoo and PostgreSQL versions, and the list of checks passed. Sign-off should come from the business process owner for the transaction checks and from the infrastructure owner for the restore. Repeat the full plan at least after each Odoo version upgrade, after any change to a custom module that touches models, scheduled actions or the filestore, and after changes to the load balancer or database topology. Schedule a shorter subset on a regular cadence agreed with the operations team, and ask your implementation partner to confirm how the plan maps to the support retainer, if one is in place.

After go-live, high availability depends on the checks your team runs every day. Start with PostgreSQL replication lag between the primary and each standby, because a lagging standby is the most likely reason a failover would lose recent orders or stock moves. Track free disk space on the database volume and on the shared filestore separately, since attachments and generated reports fill the filestore while the database grows through transactions. Watch each Odoo worker's health and the length of the scheduled actions queue, since a backlog of stalled cron jobs often shows up as slow invoicing or stuck imports before anyone reports an outage. Confirm that the load balancer health checks report the correct state for every Odoo node, and track certificate expiry on the reverse proxy and any internal endpoints. Set alert thresholds with your operations team and confirm the metric names in your own monitoring tool.

Backups carry several decisions that only the client can make. Choose the frequency of full database backups and of continuous WAL archiving, the retention period for each, and whether copies live off the primary site and in a separate account or data center. Back up the filestore on the same schedule as the database so that attachments match the records that reference them. Decide who may trigger a restore, how backups are encrypted and where the keys are held, and how long each backup set can be kept before deletion, taking into account your own legal and audit requirements. Restore tests should run at a cadence you set, into an isolated environment, with the results recorded in a test log. A backup that has never been restored is an assumption, and the test log is the evidence that the procedure works.

Patching has a fixed boundary. Odoo standard support covers the first three years after a major release on Odoo Online, Odoo.sh and on-premise, and security patches are provided only during that window. Odoo 19.0 is covered by standard support until September 2028, while Odoo 17.0 standard support ended in September 2026, so a deployment still on 17.0 no longer receives security patches from Odoo. Apply Odoo minor and security updates first to a staging copy of the database and filestore, then to the nodes in a rolling order so the cluster keeps serving requests. Patching also covers the operating system, PostgreSQL, the reverse proxy and the load balancer, and these follow their own vendor schedules, so assign an owner to each in the runbook.

Major upgrades differ by hosting model. On Odoo Online and Odoo.sh, major version upgrades are mandatory every two years, so those customers should plan the next upgrade into their budget and change calendar in advance. On-premise deployments do not face that mandate, but the support dates still set the practical limit: plan each major upgrade before the current version leaves standard support, because extended support for on-premise is paid, limited, and not a substitute for planned work. Odoo's upgrade service requires an Enterprise subscription for on-premise use. Finally, hand the system over with documentation that someone other than the original builders can use: the topology diagram, configuration files with secrets removed and held in your vault, failover and restore runbooks, the restore test log, and a list of every node with its role.