If you’ve ever renamed an Odoo.sh project and then spent twenty minutes wondering why your staging URL still shows the old name, you weren’t doing anything wrong. The platform just handles production and non-production branches differently when it comes to name changes — and until now, the documentation didn’t make that distinction clear.
What the Documentation Used to Say
The previous wording was simple and, as it turns out, incomplete: “If you change the project name, only future builds will use the new name.” That single sentence implied a uniform behavior across all branches. It suggested that after renaming, you’d need to trigger new builds everywhere before the change would propagate. Production, staging, development — all treated the same.
That’s not how it works.
How It Actually Works
When you change an Odoo.sh project name and save, the production branch picks up the new name immediately. The production database URL updates on the spot — no rebuild required. Your live site, your API endpoints, your custom domain mappings that reference the Odoo.sh subdomain: they all reflect the new name as soon as you hit save.
Staging and development branches, on the other hand, keep running under the old name until they’re rebuilt. This means a staging branch you spun up last week will continue usingbranch.old-name.odoo.com until you manually trigger a rebuild or push a new commit that triggers one automatically.
Why the Difference Exists
The split behavior makes sense once you think about how Odoo.sh manages its infrastructure. Production branches have persistent infrastructure that the platform can update in place — DNS records, reverse proxy configurations, database URL mappings. These can be repointed without disrupting the running application.
Staging and development branches are more ephemeral by design. Their infrastructure is provisioned at build time and torn down when the branch is deleted or the database expires. Updating their URLs outside of the build process would mean reaching into a container that was configured with the old name and modifying it live — possible, but fragile and inconsistent with the build-based deployment model that makes Odoo.sh reliable in the first place.
The Practical Impact
For most teams, this distinction won’t come up often. Project renames are rare events, usually triggered by a company rebrand, a pivot in product naming, or the realization that the name chosen during initial setup no longer makes sense.
When it does happen, the key thing to know is that your production environment transitions cleanly and immediately, which is the part that matters for customers and external integrations. Staging and development environments will catch up on their own the next time they rebuild, which for active development branches happens frequently enough that it’s rarely a concern.
The edge case to watch for: if you have automated scripts, CI/CD pipelines, or integration tests that reference staging URLs by their full Odoo.sh subdomain, those will break after a rename until the staging branch rebuilds. Hardcoding staging URLs has always been fragile practice, but a project rename is the moment it actually bites.
A Documentation Fix, Not a Feature Change
It’s worth emphasizing that this isn’t a behavioral change in Odoo.sh itself. The platform has always worked this way. What changed is that the documentation now accurately describes the split behavior instead of implying a uniform “future builds only” rule that was never quite true for production.
These kinds of documentation corrections are easy to dismiss as trivia. But for the operations engineer who renames a project at 2 PM and then spends an hour trying to figure out why production is fine but the QA team’s staging environment is still showing the old domain — knowing that a rebuild is all that’s needed saves real time and real frustration.