Odoo.sh is not a plain cloud server with Odoo installed on top. It is a purpose built platform that connects your Odoo instance to a Git repository, gives you staging environments to test changes before they reach production, automates backups and takes on the infrastructure work you would otherwise carry yourself. This guide explains what Odoo.sh gives you and where it beats plain hosting.
📋 Key Takeaways
- Odoo.sh links your Odoo instance to a Git repository. Push code to a branch and it becomes a running environment, with production, staging and development branches at once.
- Staging lets you test custom modules, configuration and upgrades on a copy of production data before anything touches the live system, the biggest gain over plain hosting.
- Daily automated backups, downloadable exports and point in time recovery are included, with no scripts to write and no offsite storage to configure.
- Cost is per user per month on top of the Enterprise licence. Above 30 users a self managed server tends to be cheaper, while under 25 users Odoo.sh often works out lower.
- Odoo.sh is Enterprise only. Odoo Community cannot run on it.
📑 Table of Contents
- What Odoo.sh Actually Is
- How Git Branches Work in Odoo.sh
- Staging Environments for Safe Testing
- Automated Backups and Restore
- Built In Upgrade Tooling
- Deploying Modules and Custom Code
- Where Odoo.sh Beats Plain Cloud Hosting
- Limits and Cost Model
- Who Odoo.sh Fits and Who It Does Not
- Setting Up a First Odoo.sh Project
- FAQs
What Odoo.sh Actually Is
- A managed platform, not a raw server. Odoo.sh sits between Odoo Online, which is pure hosted software, and self managed hosting on a bare server, pairing the code freedom of self hosting with managed infrastructure.
- Enterprise edition only. Odoo.sh runs Enterprise and does not support Community. If you are still weighing them, our guide on choosing between Community and Enterprise walks through the trade offs.
- Built by Odoo SA. It is built by the same team that builds Odoo, so it is shaped around Odoo architecture and its upgrade lifecycle.
- Git at the centre. Every project links to a Git repository on GitHub or GitLab, where your codebase and custom modules live, and the platform builds running instances from your branches.
How Git Branches Work in Odoo.sh
The three branch types
- Production branch. Your live instance, one per project, where all real data and users run. You push here only after testing on staging.
- Staging branches. Copies of production carrying production data, used to test changes, new modules and configuration before merging. Several can run at once.
- Development branches. Lightweight spaces that start with demonstration data, used to build features without risk.
The deployment workflow
- A developer pushes code to a development branch and Odoo.sh builds a running instance to test in.
- When ready it merges into staging, which rebuilds on production data so testing happens on real records, then merges into production where Odoo.sh deploys it live.
- If something breaks, you revert the Git commit and production rebuilds from it. Rollback is as quick as a Git operation.
Staging Environments for Safe Testing
Why staging matters
- Test with real data. A report that behaves on demo data can fail on production data with unusual edge cases. Staging uses production data, so you catch these before users do.
- Configuration testing. New fiscal positions, updated pricelists and changed workflow rules can be checked against existing records before you apply them.
- Module compatibility. Installing a new outside module straight onto production can break existing workflows. Staging surfaces the conflict first.
- Upgrade testing. You run the upgrade on staging first and confirm custom modules work and data migrates cleanly.
- Creating a staging environment means cloning the database to a second server and keeping the two in sync, which is hours of setup and steady maintenance.
- Most self managed deployments skip staging because of the effort, so changes go straight to production and recovery happens under pressure.
- Odoo.sh removes that friction. Staging is a button click, and the cost of not testing is almost always higher than the branch.
Automated Backups and Restore
- Daily automated backups. Odoo.sh backs up the database and filestore every day with no setup and no silent script failures.
- Retention. Backups follow your plan policy, with recent copies kept daily, older ones weekly and then monthly.
- Downloadable and restorable. You can pull backups from the dashboard, restore a staging branch from a production backup in one click and spin up a testing environment on current data whenever you need it. Our database backup and restore guide covers handling exports properly.
- Point in time recovery. In a serious situation Odoo SA can help restore the database to a specific moment, which limits data loss after accidental deletion.
Built In Upgrade Tooling
- Upgrade tested on staging. Odoo.sh runs the upgrade on a staging branch first, executing the scripts, migrating data and building a running instance of the newer release with your data and modules.
- Compatibility reports. The process flags custom modules that need changes. Our guide to Odoo version upgrade planning explains how to budget for that work.
- Rollback safety. If the staging upgrade shows problems you discard the branch and keep production on the current release, so live data is never at risk.
- Odoo SA assistance. Enterprise customers get help during the base upgrade, while adapting custom modules stays with your team.
Deploying Modules and Custom Code
- Custom and outside modules. Any module that runs on Odoo Enterprise can run on Odoo.sh, including Community association, App Store and partner built modules. If you need that work done, our Odoo customization services cover the full build and review cycle.
- Dependencies and configuration. Python dependencies go in a requirements file that Odoo.sh installs during the build, while worker counts and job intervals adjust from the dashboard.
- Shell access. You get container access for debugging and logs, with restricted write access on production and full access elsewhere.
Where Odoo.sh Beats Plain Cloud Hosting
Advantages over a self managed server
- Staging in one click rather than hours of manual setup, which alone justifies the platform for teams that deploy custom code. Our overview of Odoo hosting options compares the main routes.
- Backups and security managed rather than writing backup scripts, arranging offsite storage and patching the operating system, database and Odoo server yourself.
- Git driven deployment rather than logging into a server and restarting workers by hand. A deployment is simply a Git push.
- Upgrade tooling and monitoring included rather than running migrations by hand and wiring up your own monitoring stack.
Limits and Cost Model
- No Community edition. If you run or plan to run Odoo Community, Odoo.sh is not an option.
- Limited infrastructure control. You cannot pick exact server specifications, tune the database far beyond defaults or select arbitrary locations.
- Some lock in. Your code stays portable in Git, but hosting, the build pipeline and backups sit on the platform, so moving off later means exporting and rebuilding elsewhere.
- Per user pricing. Above 30 users the per user cost becomes noticeably more expensive than a fixed cost server handling the same count.
Rough cost benchmarks
- Odoo.sh runs roughly 1,500 to 3,000 rupees per user per month, including hosting, backups, staging and monitoring.
- At 10 users that is about 1.8 to 3.6 lakh a year, and at 25 users about 4.5 to 9 lakh a year.
- At 50 users it reaches about 9 to 18 lakh a year.
- A self managed server for the same 50 users runs far lower on paper but carries hidden staffing and maintenance costs, which is where running it yourself starts to pay off.
Who Odoo.sh Fits and Who It Does Not
Odoo.sh is the right choice when
- You run custom modules and need staging to test them safely before they reach production.
- Your team already works in Git and wants a clean push to deploy workflow.
- Your user count is roughly 10 to 25 with no dedicated staff for server management.
- You value automated backups, monitoring and security without running them yourself.
Odoo.sh is not the right choice when
- You run Odoo Community, since the platform is Enterprise only.
- Your user count is well above 30 with internal server capability, where self managing is clearly cheaper.
- You need specific infrastructure such as particular locations, deep database tuning or specific operating system versions.
- You run standard Odoo with no custom modules, where hosted Odoo Online is simpler.
Setting Up a First Odoo.sh Project
A simple starting sequence
- Create a repository. Set up a GitHub or GitLab repository for your modules and configuration, then connect Odoo.sh to it.
- Sign up and pick a plan. Link your Enterprise subscription and choose a plan based on user count and resource needs.
- Connect and branch. Authorise access, and the platform creates the initial production, staging and development branches.
- Configure production. Set the release, list any submodules or dependencies and set the server parameters.
- Deploy and settle in. Push modules to development, test, merge to staging, test on production data, then merge to production. Every future change follows the same path.
Ready to Move Your Odoo Instance to a Managed Platform?
Tatvamasi Labs sets up Odoo.sh projects, migrates existing databases and configures Git driven deployment with staging, backups and monitoring from day one.
Set Up Odoo.shFrequently Asked Questions
📖 Related Reading
Pratik Akbari is an Odoo ERP expert and content writer specializing in Odoo implementation, customization, integration, and business automation solutions. He shares valuable insights, practical guides, and industry updates to help businesses optimize their operations with Odoo.
