Odoo.sh Hosting: How Branching, Builds and CI/CD Actually Work

What Odoo.sh Actually Is

Odoo.sh is the cloud platform Odoo built to host Odoo-based solutions and to deliver them through a Git-driven continuous-integration workflow. It is not a module and it is not a feature you switch on inside a database — it is the infrastructure layer that runs your Odoo server, your Postgres database, your filestore, and a build farm that turns every commit into a tested, deployable build. Official Odoo documentation defines an Odoo.sh build as a database loaded by an Odoo server (the odoo/odoo and odoo/enterprise codebases) running on a specific revision of your project repository inside a containerized environment.

The licence gate is non-negotiable. Official Odoo.sh hosts Odoo Enterprise only: Odoo Community cannot use the official platform. On the Enterprise side, the Odoo pricing page is explicit that the cost for Odoo.sh hosting is not included in the Custom plan — the plan merely unlocks the right to host on Odoo.sh or on-premise rather than on Odoo Online. Standard plan customers stay on Odoo Online only. So the hosting decision is a genuine net-new choice on top of the per-user licence, with its own per-worker, per-gigabyte and per-environment costs.

Operationally, Odoo.sh gives you three things pure Online SaaS does not: a Git-native deployment pipeline, isolated staging copies of live production data, and a managed safety net that automatically reverts a broken production release. If your implementation involves any custom code, third-party modules, or frequent configuration changes you want to test before they touch real business data, Odoo.sh is the only Odoo-managed option that supports it — Odoo Online refuses custom modules and Odoo Apps Store modules. Industry verticals still feel that split in 2026: many hotel and similar modules still require Odoo.sh (or self-host) rather than pure Online SaaS, even as some SaaS-native apps appear.

Online vs Odoo.sh vs On-Premise vs Partner PaaS

Before drilling into branching and builds, frame the hosting destinations Odoo and the partner ecosystem offer — the first, and often most expensive, operational decision in a customized rollout. Odoo’s own documentation splits official hosting into Odoo Online, Odoo.sh, and on-premise. The pricing page ties them to licence plans: Standard is Odoo Online only; Custom unlocks Odoo.sh and on-premise as well as Online. A fourth practical category is partner-managed PaaS (for example Cloudpepper, Skysize, or similar BYO-cloud control panels): Git-style deploy and staging workflows without Odoo’s own shared workers bill, often supporting Community as well as Enterprise.

Odoo Online is the fully managed, turnkey cloud. Hosting is included with unmetered storage up to 100 GB, but it is deliberately locked down: no custom modules and no Apps Store modules. That is ideal for standard apps only, and a poor fit the moment you need bespoke code. Odoo.sh is the official middle ground: still managed by Odoo, built for custom code and continuous delivery, with GitHub-linked pipelines and neutralized staging. On-premise means you run Enterprise (or Community) on infrastructure you own, with full control and full operational burden. Partner PaaS sits between self-host and .sh: you (or the partner) bring a VPS or cloud account; the panel handles staging, backups, and deploy, often with flat platform fees instead of per-worker metering — useful when worker or storage costs on .sh would dominate, or when Community is required.

The practical rule of thumb: no custom code → Odoo Online. Custom modules plus you want Odoo’s own CI/CD and auto-revert → Odoo.sh (Custom plan + hosting). Community edition, GitLab/Bitbucket-first workflows, multi-client partner fleets, or hard cloud-provider choice → partner PaaS or self-host. Air-gap or exotic compliance that forbids multi-tenant cloud → on-premise only. Price every option as licence + hosting + ops time; the cheapest sticker is not always the cheapest three-year total.

Branches and Stages: Production, Staging, Development

The branching model is the heart of how Odoo.sh works, and it is the concept most teams underestimate when they first move from a manually-administered Odoo server. The Odoo.sh Branches view organizes your repository's Git branches into three stages — Production, Staging, and Development — and you change a branch's stage by dragging and dropping it under the desired heading. The stage a branch sits in determines what Odoo.sh does when you push a commit to it, which database it runs against, and how safe that deployment is.

There can be only one Production branch, and it contains the code that runs your live production database. Pushing a new commit to it updates and restarts the production server; if a change requires a module update (say, a modified form view), you bump the module's version number in its __manifest__.py manifest and the platform performs the update automatically, holding the instance briefly unavailable for maintenance. Staging branches are designed to test new features against real production data without contaminating the live database — they create neutralized duplicates of production (scheduled actions and outgoing mail are disarmed; payment and shipping connectors go to test mode). Development branches are the lightest: fast, disposable environments built with demo data so unit tests have a known starting point.

The stage transitions are deliberately constrained to protect production. A development branch can be promoted to Staging, but moving one directly to Production triggers a warning explaining you can have only one production branch. A staging branch can be demoted to Development but cannot be moved under Production; the production branch itself can only be demoted to Development, and any move toward Staging is handled as a merge rather than a direct stage change. Merging staging into production merges source code only — configuration changes made in the staging database do not travel with the merge unless you encode them in XML data files (and bump the module version) or re-apply them manually in production.

Staging Database Lifecycle: Auto-Deleted After One Month

The staging model is only half useful if you treat staging databases like long-lived UAT servers. Official Odoo 19 documentation is explicit: databases created for staging branches are automatically deleted after one month; to use the branch again, you must rebuild it. Staging databases are not automatically backed up (you can still take manual backups and restore a production backup into staging for testing). Development databases are even more disposable — intended to last roughly three days before garbage collection, with no automatic or manual backups.

This is not a misconfiguration. Forum answers from May–June 2026 confirm the platform began surfacing warnings such as “This database is a temporary Odoo.sh staging environment. It will be automatically deleted on [date]. Staging databases are not backed up, do not store important data here.” Ray Carnes and documentation PRs describe the policy as all staging branches expiring in 30 days unless rebuilt; prior practice had longer lifetimes for some teams, which is why long-time partners noticed the change. Rebuild recreates the environment from the branch code and (for staging) production data rules — any ad-hoc records you only created in that staging DB are gone unless you exported them.

Design the QA process around disposability. Encode configuration and demo scenarios in modules and tests, not only in sticky staging data. Before a month-end expiry, either rebuild on purpose (fresh neutralized prod copy) or download a manual dump if you need to keep a specific test dataset offline. Never store the only copy of customer UAT sign-off evidence inside staging alone. If a build shows “Dropped” or a database is blocked after long expiry, use Rebuild for staging/dev; production has a separate recovery path and should never be treated as disposable.

How Builds Work: Every Commit Becomes a Tested Build

In Odoo.sh, a build is a database loaded by an Odoo server running on a specific revision of your repository, inside its own container. The Builds view renders this as a grid: a row is a branch, and each cell within the row is a build of that branch. Most builds are created automatically when you push to a GitHub branch, but they can also be produced by importing a database onto Odoo.sh or by requesting a rebuild. Each build ends in one of three statuses — successful (green, no errors or warnings), almost successful (yellow, warnings but no errors), or failed (red, errors during creation).

The way the three stages consume builds is what makes the pipeline safe. For a Production branch, the first build creates the production database from scratch; subsequent pushes create builds that attempt to load the current production database with the new revision. If that build succeeds (or is almost successful), production runs on the new revision; if it fails to load or update, Odoo.sh reuses the previous successful build, so the database keeps running on the last known-good revision. The build powering production is always pinned to the top of the list, and a failed build is placed after it rather than replacing it.

Staging and development commit behaviour is configurable per branch. By default, a development branch creates a new build on each commit, while a staging branch updates the previous build — useful when a feature needs sticky configuration you do not want to re-enter after every push. Select New build on a staging branch when you want every commit to spin a fresh neutralized copy of production instead. That distinction matters for QA planning: “always fresh prod data” is an explicit setting, not an invisible constant. Either way, the Git-driven pipeline is still a sharper guarantee than the manual duplicate-and-hope workflow most self-hosted teams live with.

The Automatic-Revert Safety Net

The feature that most often decides whether a team trusts Odoo.sh is automatic rollback on the production branch. When you push a commit that prevents the server from restarting, or a module update fails, the platform does not leave your business running on broken code: it automatically reverts to the previous successful code revision and rolls the database back to its previous state, and it exposes the failed update's log so you can troubleshoot. The net effect is that a bad push cannot take production offline for longer than the brief maintenance window of the attempted update.

Two important nuances follow from the documentation. First, demo data is never loaded on production, because it is not intended for a live database. Second, unit tests are deliberately not executed on the production branch during an update, because running them would extend the unavailability window — testing is the job of the staging and development branches, where a failed test surfaces before code ever reaches the main branch. This split keeps production deployments fast while still catching regressions upstream.

For teams accustomed to on-premise Odoo, where a botched module upgrade can mean a frantic restore-from-backup and hours of downtime, this safety net is transformative. It shifts the failure mode from 'catastrophic, manual recovery' to 'automatic, logged, near-instant revert', which in turn changes how aggressively a team can ship. The cultural payoff is that developers push smaller, more frequent changes because the blast radius of any single push is contained — the exact behaviour a healthy CI/CD practice is meant to encourage.

Containers, Shell Access, and Managed-Platform Constraints

Each build runs inside its own isolated, Linux-namespaced container built on an Ubuntu base, with all of Odoo's required dependencies and a set of common packages pre-installed. If your project needs extra Python dependencies, you declare them in a requirements.txt file at the root of your branch (the platform also picks up requirements.txt files from submodule folders that contain Odoo modules), and Odoo.sh installs them into the container automatically. You can reach a container through the in-browser shell or over SSH, drop into the database with psql, browse the directory tree under /home/odoo (where src/odoo, enterprise, themes and your user repository live alongside data/filestore and logs), and read install, update and pip logs directly.

That access is real but bounded, and the boundaries are what distinguish a managed platform from a virtual machine you control. Odoo.sh is dedicated solely to hosting Odoo-based solutions, so additional daemonized or long-living processes and connections are not supported. Staging and development builds are restricted to a single worker and are further restrained in how often they can be used per day, PostgreSQL extensions cannot be installed, and the only supported source-control system is GitHub (GitLab and Bitbucket are on the wishlist but low priority). Builds are also garbage-collected over time to make room for new development builds — production instances are naturally excluded from that collection.

Two platform behaviours catch teams off guard and are worth designing around. Scheduled actions (crons) run on a best-effort basis because multiple customers share hardware and each must get a fair share, so Odoo.sh cannot guarantee an exact run time and warns that no scheduled action will run more often than every five minutes. The platform also caps execution time per cron, which means well-engineered scheduled actions should process small batches, commit after each batch, and be idempotent. The second behaviour is that, in the staging environment, all outgoing emails are captured automatically and custom outgoing mail servers are deactivated — so a staging test never accidentally emails a real customer.

Backups, Custom Domains, SSL, and Email

Odoo.sh bundles the operational services that, on-premise, you would have to assemble yourself. The platform automatically backs up the production database and retains seven daily, four weekly, and three monthly backups; each backup includes the database dump, the filestore (attachments and binary fields), the logs, and the sessions. Those backups are replicated across three backup servers in different locations, and storage is live-replicated as well — a level of geographic redundancy most SMEs never achieve on self-hosted infrastructure. You can also import a database dump on production or staging branches through the Backups tab.

Custom domains are configured in your project's settings, and HTTPS certificates are issued and renewed automatically through Let's Encrypt, so you do not need to procure or rotate SSL certificates manually. Email deliverability is handled through automatically configured DNS and email, though production senders still need SPF and DKIM compliance configured in their DNS records to land reliably in inboxes. The combination — managed SSL, managed backups, managed DNS and email plumbing — is a large part of what you are paying for versus on-premise, and it is the reason a small IT team can run a serious Odoo deployment without a dedicated platform engineer.

One operational quirk worth flagging: when the IP address of a production instance changes, Odoo.sh notifies project administrators and also fires an HTTP GET request to the path /_odoo.sh/ip-change on your instance, passing the new and old IPs as query parameters. That internal-only route lets your custom code react automatically — updating a firewall API, rewriting an integration allowlist, or flipping a configuration parameter — without manual intervention. It is the kind of webhook you only discover once you need it, and it is worth knowing about before you wire integrations to a fixed production IP.

Pricing: Workers, Storage, Staging Envs, and Trials

Odoo.sh pricing is usage-based, driven by the calculator on odoo.sh/pricing rather than a fixed per-seat hosting fee. On annual billing (USD), the public calculator shows about $57.60 per worker per month and $0.20 per GB of storage per month, so a minimal one-worker, one-gigabyte configuration lands near $57.80 per month before add-ons. Staging environments list at $14.40 per environment per month. Dedicated hosting type is $480 per month and is required once you need more than eight workers or more than 512 GB of storage. The page states clearly that hosting price does not include the Enterprise licence. The calculator also exposes a Monthly billing toggle; monthly rates are higher than the annual figures — secondary 2026 breakdowns commonly quote roughly $72 per worker, $0.25 per GB, and $18 per staging environment on monthly-style math — so always re-check the live toggle before you budget.

Workers are the capacity lever: each production worker handles concurrent request load. Small teams often start at one or two workers; heavier concurrency, eCommerce peaks, or chatty integrations push the count up. Staging and development builds are restricted to a single worker with tighter resource and concurrent-request limits, and their scheduled actions fire only a couple of times a day — do not size production workers based on staging behaviour. Storage covers database plus filestore; attachment-heavy businesses (documents, product images, EDI payloads) should model growth early, because crossing the shared-tier ceiling forces the dedicated hosting add-on.

The licence side determines whether you can use Odoo.sh at all. Odoo’s three commercial plans: One App Free (one app, unlimited users, Online only), Standard (all apps, Online only), and Custom (all apps, choice of Online at no extra hosting cost, Odoo.sh, or on-premise, plus Studio, multi-company, and external API). Only Custom unlocks Odoo.sh; Community cannot use the official platform. Per-user Custom licence rates are region- and period-specific on odoo.com/pricing (and often discounted for the first twelve months on initial users), so model steady-state after year one. Hosting and licence are separate line items — a ten-user team’s worker bill can look small next to the per-user Custom licence.

Partners and prospects can validate on a trial project activated with a partnership subscription code. Official FAQ limits: one worker, two staging environments, 1 GB of storage per database build; thirty days before termination; backups not guaranteed like a paid project. Trial production and staging stages are forced back to development after thirty days. Never store the only copy of valuable data on a trial. Paid Enterprise customers must have Odoo.sh on the subscription (activation code on Settings) before a production project can run outside trial limits.

When to Choose Odoo.sh Over the Alternatives

The decision distills to a few sharp questions. If your implementation is out-of-the-box Odoo apps with no custom code and no third-party modules, Odoo Online is the rational choice: hosting is included up to 100 GB unmetered storage and removes every operational task. If you have even one custom module, a server-side integration, or a need to test changes against real data before they ship, Odoo.sh pays for itself the first time automatic revert saves a release — one avoided outage often exceeds a year of worker fees.

Choose partner PaaS or self-host when Community is required, when GitHub-only SCM is a deal-breaker, when per-worker and multi-staging storage costs would dominate your bill, or when you need a specific cloud region or account you control (GDPR placement, existing AWS/GCP commit). Odoo.sh still wins when you want Odoo’s own GitHub CI/CD, production auto-revert, and support path without running the farm yourself. On-premise remains for air-gap, hard residency, or stack choices the multi-tenant cloud cannot satisfy — with full ownership of backups, upgrades, and neutralization.

A common error is treating hosting as separate from methodology. Odoo.sh’s three-stage branching enforces test-before-production only if you use it: protected production merges, staging rebuilds that respect the thirty-day database life, and development branches for unit tests. If a partner proposes custom code but cannot explain worker sizing, staging rebuild cadence, and how configuration changes promote without sticky staging data, pressure-test the plan before go-live. Also budget queue time: practitioners occasionally report multi-minute staging build queues during busy platform periods — still usually cheaper than owning CI, but not zero latency.

How Fletic Approaches Odoo.sh Hosting Decisions

As a partner that implements both Odoo and Dynamics 365 for SMEs across Canada, the UK, and the US, Flectic treats the Odoo.sh hosting decision as part of the rollout design, not an afterthought. We start by mapping which of your requirements genuinely need custom code versus configuration, because that single answer usually determines whether Odoo Online is viable or whether Odoo.sh is mandatory — and it prevents over-buying infrastructure for processes that standard apps and Odoo Studio can handle.

When Odoo.sh is the right fit, we structure the repository around the three branch stages from day one: a protected production branch that only receives reviewed merges, staging branches used as disposable neutralized copies of production (with rebuild cadence that respects the one-month database life), and short-lived development branches built with demo data for fast iteration. We configure custom domains and Let's Encrypt SSL, set SPF and DKIM for deliverability, tune scheduled actions to be batched and idempotent so they survive the platform's cron time-limits, size workers against real concurrency rather than staging limits, and rehearse the production auto-revert before go-live so the team trusts it under pressure.

The goal is to make the platform's safety net part of your team's muscle memory before launch, not after the first incident. If you are weighing Odoo.sh against Odoo Online, partner PaaS, or an on-premise build — or planning a rollout that involves custom modules — our Odoo implementation team can map your branch strategy, staging rebuild plan, and hosting budget before any code is written, and our ongoing support keeps the pipeline healthy as your business scales.

Frequently asked questions