If you run staging branches on Odoo.sh, your testing databases just got an expiration date three times shorter than before. Staging databases are now automatically deleted after one month, down from the previous three-month window. And the language around it has changed too — from “can be blocked” to “automatically deleted.”
What Actually Changed
The old policy stated that staging databases were “intended to last up to three months” and could be “automatically blocked without prior notice.” That left room for interpretation — some teams treated staging branches as semi-permanent testing environments that persisted for months at a time.
The new policy removes that ambiguity entirely. Staging databases are now automatically deleted after one month, full stop. If you need the branch again, you rebuild it. There’s no blocking, no grace period, and no recovery — the data is gone.
Why This Matters for Development Teams
Staging branches on Odoo.sh serve a specific purpose: they create neutralized copies of the production database so teams can test new features against real data without risking the live system. Scheduled actions are disabled, outgoing emails get intercepted by a mail catcher, payment providers switch to test mode, and IAP services shut off.
Many teams had developed workflows around long-lived staging environments — keeping a branch running for weeks while iterating on custom modules, running QA cycles, or training end users on upcoming changes. A one-month ceiling changes that calculus significantly.
Teams That Will Feel This Most
- Custom module developers who use staging branches as integration testing environments during multi-sprint development cycles. If your sprint cadence runs longer than a month, your staging data disappears mid-cycle.
- QA teams that maintain staging environments with specific test data configurations. Rebuilding means re-importing test fixtures and re-running setup scripts every month.
- Training coordinators who set up staging instances for end-user training sessions. Any staging database prepared more than a month in advance will need to be rebuilt closer to the training date.
What You Can Do About It
The practical response is to treat staging databases as truly ephemeral. That means investing in automation that can rebuild a useful staging environment quickly:
- Script your test data setup so rebuilding a staging branch isn’t a manual, multi-hour process.
- Store configuration changes as XML data files in your branch modules rather than making manual adjustments through the UI.
- Use manual backups for any staging data you need to preserve — though be aware that staging backups are only accessible for three days.
- Coordinate your development and QA timelines around the one-month window instead of treating staging as an always-on environment.
The Broader Signal
This change aligns with how most cloud platforms handle non-production environments — as temporary, disposable resources rather than persistent infrastructure. AWS CodeBuild environments, Heroku review apps, and Vercel preview deployments all follow this pattern. Odoo.sh is catching up to the expectation that staging is a verb, not a noun.
For teams already running lean CI/CD workflows with automated deployment scripts, this changes nothing. For teams that have been treating staging branches as cheap production clones, it’s a wake-up call to modernize how they think about non-production environments.
The bottom line: build your staging environments to be rebuilt, not maintained.