Staging

A neutralized copy of production to test with real data, and exactly what neutralization turns off.

A staging branch runs your code on a copy of the production database, so you can test with real data before you deploy. The copy is neutralized : it can't email your customers, charge cards or run your scheduled jobs.

When the copy is made

The first build after a branch moves to staging copies production, neutralizes the copy, then updates the modules whose version was bumped.

Later pushes use Update previous build by default: the staging database is kept and updated the same way production will be. It's a rehearsal of the production deploy.

Click Rebuild to throw the staging data away and start from a fresh copy of production.

What neutralization disables

Outgoing mail servers : emails are caught and shown in the branch's Mails tab instead of being sent.

Incoming mail servers (fetchmail), so staging doesn't read the real mailbox.

Scheduled actions , apart from Odoo's own database cleanup.

Payment providers and shipping connectors are disabled or switched to test mode.

In-app purchase accounts (SMS, document digitization…) and calendar sync tokens are disconnected.

The Odoo Enterprise subscription code is removed, so the copy never counts as a second production database.

Website domains are cleared.

On Odoo 16 and later this is Odoo's own odoo neutralize , which each installed app extends. On Odoo 14 and 15, Odoo Cloud runs the equivalent SQL.

Your own integrations Neutralization only knows about Odoo's standard features. If a custom module calls an external API with credentials stored in the database, it may still call it from staging. Guard it, for example by checking the database.is_neutralized system parameter.

Development and staging builds don't live forever: development builds are removed 3 days after they were built, staging builds after 30 days. Rebuild brings them back.