Odoo sells three ways to run Enterprise: Odoo Online, where Odoo hosts a standard database; on-premise, where you run the servers; and Odoo.sh, which sits between them. Odoo runs the infrastructure, and you bring a Git repository full of your own modules. If your company needs code that isn’t in the standard apps, it’s the hosted option that accepts it.
Three kinds of branch
Every branch in the connected GitHub repository shows up in the Odoo.sh project, and you drag it into a stage.
Production holds the code your live database runs. A project has exactly one. When you push to it, the server picks up the new revision and restarts. Changes that need a module update, like a new view or data file, only get applied automatically if you raise the version in the module’s manifest. If the update fails, Odoo.sh goes back to the last good revision and rolls the database back with it. Tests don’t run here.
Staging branches get a fresh copy of the production database on every push, neutralized so it can’t do real damage. Scheduled actions are disabled, outgoing email goes to a mail catcher, and payment and shipping connectors switch to test mode. That’s why an ir.cron job that works on production appears to do nothing on staging.
Development branches build a brand new database with demo data and run the unit tests. A failing test marks the build as failed. With a full set of modules to test, one of these builds can take up to an hour.
Builds are coloured by outcome: green when clean, yellow when there were warnings but no errors, red when something failed.
Getting custom addons onto it
You commit your addons to a branch. Odoo.sh finds module folders wherever they sit in the repository, so the layout is up to you. Public community modules can come in as Git submodules, and Python packages your code imports go in a requirements.txt file in the branch.
The flow we’d recommend: push to a development branch and let the tests run, merge into staging to try the change against real data, then merge staging into production. You can merge by dragging branches onto each other in the Odoo.sh interface or with plain git merge.
erpfly fits into that flow directly. Generated addons for Odoo 17, 18 and 19 arrive as a branch on your repository, so on Odoo.sh they get a development build and a test run before anyone merges them. Odoo module development explains what’s in the branch.
Things that catch teams out
Configuration done in staging stays in staging. Merging moves code, not database changes. Anything configured by hand in a staging database, including Studio customizations, has to be redone in production or written into a module as XML data.
Staging and development databases are temporary. Staging databases are deleted after a month, and development databases are meant to last about three days.
Forgetting the version bump. Without it, production restarts on the new code but the module isn’t updated, so new views, data records and fields never reach the live database.
It needs the right subscription. Creating a project asks for an Odoo Enterprise subscription code that includes Odoo.sh. Only major Odoo versions are supported, so a database on an Odoo Online intermediate release has to reach the next major version before it can move.
If you’re weighing hosting as part of a bigger decision about the platform, our Odoo overview is a good place to start.