Odoo.sh alternatives: hosting Odoo with the same GitHub workflow
The realistic ways to host Odoo when you want branches, staging copies of production and push-to-deploy, how they compare with Odoo.sh, and the questions to ask before you choose.
By Odoo Cloud · Published · 7 min read · Odoo.sh, Odoo hosting, Comparison
Odoo.sh set the standard for how many teams work on Odoo: every GitHub branch becomes a running environment, a staging branch runs on a copy of production, and a push to the production branch deploys. Once you have worked that way, going back to copying files onto a server by hand feels like a step backwards.
There are good reasons to look at other options anyway. You may run Odoo Community, which Odoo.sh doesn't host. You may want a different provider to operate your infrastructure, or a partner who is closer to your business. This article walks through the realistic alternatives, what each one gives up or adds, and what to check before you move.
Odoo and Odoo.sh are trademarks of Odoo S.A. Odoo Cloud is an independent service, not affiliated with or endorsed by Odoo S.A.
What Odoo.sh does well
It is worth being clear about what you would be replacing. Odoo.sh is Odoo S.A.'s own platform for Odoo Enterprise, and its workflow is well designed:
- Branches are environments. Each branch of your repository builds into its own Odoo with a URL, logs and a shell.
- Three stages. Development builds start from a fresh database with demo data and run your tests. Staging builds use a neutralized copy of production, so emails are caught and scheduled actions are off. Production keeps its database and is updated on each push.
- Tools in the browser. A web shell, an online editor, logs and monitoring, without installing anything.
- Backups and upgrades. Daily backups kept for several months, and a path to newer Odoo versions through Odoo's upgrade service.
- One vendor. The software, the hosting and the support come from the same company.
If that last point matters most to you, Odoo.sh is the natural choice, and there is no reason to move. The alternatives below make sense when something else matters more.
The options, side by side
Broadly, there are four ways to run Odoo with custom modules.
Odoo Online
Odoo's SaaS offer is the simplest to run: nothing to host, upgrades handled for you. It is built for standard Odoo, so custom Python modules from your own repository can't be installed. If you have (or plan to have) custom code, it isn't an alternative to Odoo.sh; it is a different product.
Your own server, managed by hand
You can install Odoo on a virtual server and run it yourself. You get full control and the lowest hosting bill. You also take on everything Odoo.sh did for you: reverse proxy and certificates, PostgreSQL, backups and restore tests, monitoring, staging copies and their neutralization, log access for developers, and security updates. Teams often underestimate the last three. It works well when you have an experienced system administrator, and poorly when "the server" is a side task for a developer.
Generic managed hosting
Many providers will run Odoo on a server for you. The quality varies widely. Some give you a server and little else; others offer backups and monitoring but no branch workflow, so testing a release on production data still means asking someone to copy a database. Ask to see the deploy process, not just the price list.
GitHub-workflow platforms, such as Odoo Cloud
The fourth option keeps the Odoo.sh way of working and changes who operates it. Odoo Cloud is one example: you connect a GitHub repository and every branch becomes an Odoo environment, with the same development, staging and production stages. It hosts Odoo 14.0 to 20.0, in Community or Enterprise edition.
How Odoo Cloud compares with Odoo.sh
The comparison below is based on Odoo's public documentation at the time of writing. Check the current Odoo.sh documentation for anything that matters to your decision.
| Capability | Odoo.sh | Odoo Cloud |
|---|---|---|
| Branches pushed from GitHub become environments | Yes | Yes |
| Development, staging and production stages | Yes | Yes |
| Staging on a neutralized copy of production | Yes | Yes |
| Web shell, SSH, online editor, logs | Yes | Yes |
| Daily backups, custom domains with HTTPS | Yes | Yes |
| Odoo Enterprise | Yes | Yes, licence bought from Odoo |
| Odoo Community | No, Enterprise only | Yes |
| Operated by | Odoo S.A. | Odoo Cloud |
A few differences are worth spelling out.
Community projects are welcome. Odoo.sh requires an Enterprise subscription. On Odoo Cloud you choose the edition per project, and the hosting price doesn't change with it.
Enterprise licences stay with Odoo. For Enterprise projects, the Enterprise apps are provided by the platform, but the subscription is yours: you buy it from Odoo S.A. and register the code inside Odoo, the same way you would on your own server. You never share the code with us. The details are in Odoo Community vs Enterprise hosting.
Backups are tested by restoring them. Production is backed up every day, keeping 7 daily, 4 weekly and 3 monthly backups. Once a week the newest backup is restored into a temporary database and checked. When the platform's offsite storage is configured, every backup is also encrypted and copied to a second location. See Odoo backups done right.
Idle environments sleep. Development and staging builds that nobody visits are stopped after a while and wake on the next visit, in about 10 to 30 seconds. Production never sleeps.
The same habits carry over. The shell has the commands Odoo.sh users know (odoo-update, odoosh-restart), the repository is at ~/src/user, and you can SSH into a build with the keys from your GitHub account.
Questions to ask any provider
Whichever alternative you look at, these questions separate a platform from a server with Odoo on it.
- How do I test a release on real data? You want a staging copy of production that can't email your customers or charge cards. Ask what is neutralized, and whether it works on your Odoo version.
- What happens when an update fails? A good answer is: production is backed up before the update and put back automatically if it fails.
- When was a backup last restored? A backup that has never been restored is a hope, not a backup. Ask how restores are tested and how you download a copy.
- Can I leave? You should be able to download a standard Odoo backup at any time and restore it elsewhere.
- Who can reach production? Look for per-stage access, audit logs of shell sessions and deploys, and isolation between customers.
- How are upgrades handled? Moving to a new major version should be rehearsed on a copy before production is touched.
- Where is the data? If data location matters to you, ask for the hosting region in writing.
Moving without drama
If you decide to move, the path is straightforward because the workflow doesn't change. You connect the same repository, create a project on the same Odoo version, import a backup of your database into staging to rehearse, then into production, and point your domain at the new address. The steps, including the Enterprise registration, are in How to migrate from Odoo.sh to Odoo Cloud.
Summary
- Odoo.sh is a strong platform, and the right choice if you want Odoo S.A. to run everything.
- Odoo Online doesn't run custom modules, and a hand-managed server moves all the operations work onto your team.
- A GitHub-workflow platform keeps the branch-per-environment workflow while letting you choose the operator and the edition.
- Judge any option by staging, rollback, tested backups, a clean exit and upgrades, not by the price of a server alone.
Want to see the workflow on your own repository? Compare the plans on the pricing page, or read the Odoo.sh alternative overview.