Odoo hosting
Odoo.sh staging expires after 30 days: your options
Odoo.sh staging builds are only valid for 30 days. What that means for your test workflow, and three ways to deal with it.
On Odoo.sh, a staging branch is a copy of your production database where you can test changes before they reach your users. Odoo has been communicating that staging branches are now kept for 30 days; after that the staging build expires and is removed. Partners report that rebuilding a staging branch resets the clock, and that production databases and backups are not affected. Check Odoo's current Odoo.sh documentation for the exact rules that apply to your project, as they can change.
Why this hurts
A 30-day window is fine for a quick test. It is awkward for the things that make an Odoo project succeed: a long user-acceptance test, a migration rehearsal that runs for weeks, training on realistic data, or an integration (a webshop, a warehouse scanner, an EDI flow) that you keep developing against. Every time the build expires you lose your test setup, and you have to rebuild and repeat the configuration.
Option 1: rebuild before it expires
The simplest approach: note the expiry date, and rebuild the staging branch from production before it runs out. You get fresh data and a fresh 30 days. The catch is that a rebuild replaces your staging data, so anything you did only in staging (test records, manual configuration) is lost. Keep configuration in code or data files, not in clicks.
Option 2: download a production backup and restore it yourself
You can download a backup of your production database (with the filestore) and restore it on a server you control. Then nobody removes it after 30 days. Three things to watch:
- Neutralise the copy. A restored production database can still send real emails, run scheduled actions and talk to payment providers or other external services. Odoo has a neutralisation step for this; use it before anyone logs in.
- Mind the integrations. Some connections are tied to the original environment. For example, after a restore the Peppol registration on the Odoo access point can break (we describe how to repair it in this Dutch article), so do not register the copy as if it were production.
- Personal data. A full copy of production contains customer and employee data. Treat the test server with the same care as production, or anonymise it (see below).
Option 3: a custom staging environment, loaded from production
If you test regularly, a dedicated staging environment pays off. We build and host this on request:
- A staging environment next to your Odoo, refreshed from production data when you want (on demand or on a schedule), without the 30-day limit.
- Automatic neutralisation: outgoing mail, cron jobs and external integrations switched off or pointed at test endpoints.
- Optional anonymisation: names, email addresses, phone numbers, addresses and bank accounts replaced by realistic dummy values, so you can test and train on realistic data without exposing personal data.
- Tailored to your setup: Odoo.sh, your own server or a cloud of your choice, plus custom modules and integrations.
Frequently asked questions
Does the 30-day limit affect my production database or backups?
According to the information partners received from Odoo, no: it concerns staging builds. Verify this in your Odoo.sh project settings and Odoo's documentation.
Can I keep my staging data after the build expires?
Not on Odoo.sh itself. You can rebuild from production, or restore a production backup on your own environment. Data created only in staging needs to be exported or scripted before it expires.
Why anonymise a staging database?
A copy of production contains personal data. Anonymising it reduces the privacy risk of test and training environments and avoids real customers receiving test emails.