The Three Odoo Hosting Options — What You Are Actually Choosing Between
When teams ask "where should we run Odoo?" they are usually comparing three very different products. They share a name, a codebase, and a purchase flow on odoo.com, but the operational reality of each is distinct. Before comparing cost, security, or performance, you need a clear mental model of what each deployment actually is — and where the line of responsibility sits between you and Odoo S.A.
Odoo Online — The SaaS Tier
Odoo Online is pure SaaS. You sign up, pick apps, and you are running Odoo in under ten minutes. Pricing in 2026 is a flat $24.90/user/month on the Standard plan (all apps included, monthly billing, no custom modules) and roughly $37.40/user/month on the Custom plan (adds Studio, external API access, multi-company). Infrastructure, backups, security patches, and version upgrades are all Odoo's responsibility. You get zero shell access, zero PostgreSQL access, and zero ability to install custom Python modules. If your process requires a line of custom code that is not achievable via Studio, Odoo Online is not the right fit — full stop.
Odoo.sh — The Platform-as-a-Service Tier
Odoo.sh is a managed PaaS layered on top of the same Odoo Enterprise codebase. You get a GitHub repository wired to automatic staging branches, per-branch databases, a web terminal, container-level monit, daily backups stored in three regions, and native CI that runs your test suite on every push. You can deploy any custom Odoo module in the repository, but you cannot install arbitrary Debian packages, run your own systemd units, or touch the PostgreSQL postgresql.conf file. Pricing is worker-based: roughly $60/month per additional worker on the Standard plan, scaling to $500+/month for Production-grade setups with multiple workers, staging branches, and storage. A typical 10-user deployment runs 2 workers and lands near $160/month of infrastructure on top of your user licenses.
Self-Hosted — The IaaS / On-Premise Tier
Self-hosted Odoo (sometimes called on-premise, even when it runs on a cloud VPS) means you rent or own the hardware, install PostgreSQL and Odoo yourself, and take responsibility for everything: kernel patches, backups, TLS, reverse proxy, monitoring, upgrades, disaster recovery. You can use Odoo Community (free, AGPLv3) or Odoo Enterprise (paid per user) — both run the same way. Infrastructure cost depends on scale: a single-tenant VPS for a 10-user shop is $40-$120/month, while a production-grade HA cluster with read replicas and object storage for a 100-user enterprise lands at $600-$800/month. The trade-off is operational labor. You are the DBA, the SRE, and the on-call engineer.
| Dimension | Odoo Online | Odoo.sh | Self-Hosted |
|---|---|---|---|
| Custom Python modules | No | Yes (via Git) | Yes (full) |
| Shell / PostgreSQL access | No | Web shell only | Full root |
| Backup & DR | Odoo managed | Odoo managed (3-region) | Your responsibility |
| Upgrade cadence | Forced annual | Staged (your click) | You choose |
| Typical infra cost / 10 users | $0 (bundled) | $120–$200/mo | $40–$120/mo |
If you cannot answer "who runs sudo apt upgrade on the server?" in under five seconds, you are not ready for self-hosting. If the answer is "Odoo does, automatically, overnight," you are looking at Odoo Online or Odoo.sh. If the answer is "we do, on a Tuesday maintenance window, after testing," you are looking at self-hosted.
5-Year Total Cost of Ownership — Where the Numbers Actually Land
The "which hosting is cheaper?" question is almost always answered wrong because people compare the monthly sticker price of three tiers without accounting for user licenses, sysadmin labor, storage growth, and upgrade cycles. A proper 5-year TCO model includes every recurring and amortized cost across the full lifecycle. The results are counter-intuitive: at small scale, self-hosting is more expensive than Odoo Online, not less. The break-even point sits around 25-30 users, and beyond 50 users self-hosting becomes meaningfully cheaper — but only if your team can absorb the sysadmin workload without hiring.
Scenario A — 10-User Deployment Over 5 Years
This is the typical early-stage SMB: a 10-person operations team running Sales, CRM, Inventory, Accounting, and Purchase. We assume Enterprise licensing (required for Odoo.sh and recommended for self-hosted) at $31.10/user/month on the Custom plan, billed annually. All numbers are USD, 5-year horizon, no price inflation assumed (licenses typically rise 3-5%/year — add roughly 15% on top of the license column for realism).
| Cost Component | Odoo Online | Odoo.sh | Self-Hosted |
|---|---|---|---|
| Per-user licenses (10 users × 60 mo) | $22,440 | $22,440 | $22,440 |
| Infrastructure hosting | $0 (bundled) | $12,000 | $6,000 |
| Implementation / migration | $15,000 | $25,000 | $30,000 |
| Custom development | $0 (not possible) | $40,000 | $40,000 |
| Annual upgrades (5 × labor) | $0 (forced, Odoo) | $20,000 | $30,000 |
| Sysadmin / ops labor (80 hr/yr @ $100) | $0 | $10,000 | $40,000 |
| Backup, monitoring, TLS tooling | $0 | $0 | $2,500 |
| 5-Year TCO | ~$150,000 | ~$162,000 | ~$170,000 |
Read this table carefully. At 10 users, Odoo Online is the cheapest option by a meaningful margin — but only if your workflows fit the product without customization. The moment you need a custom Python module, Online drops out and the real contest is Odoo.sh vs. self-hosted. At that size, Odoo.sh wins by $8,000 over 5 years, primarily because the 80 hours/year of sysadmin labor and the harder upgrade cycle push self-hosted up.
Scenario B — 50-User Deployment Over 5 Years
Now scale the same organization 5x. User licenses scale linearly. Infrastructure scales sub-linearly (a single well-tuned PostgreSQL instance handles 50 users almost as comfortably as it handles 10). Critically, sysadmin labor stays roughly flat at 80-120 hours/year — the same systems, patched on the same cadence, regardless of whether 10 or 50 people use them. This is where self-hosting starts to pay off.
| Cost Component | Odoo Online | Odoo.sh | Self-Hosted |
|---|---|---|---|
| Per-user licenses (50 users × 60 mo) | $112,200 | $112,200 | $112,200 |
| Infrastructure hosting (5yr) | Bundled | $36,000 | $24,000 |
| Implementation / migration | $35,000 | $60,000 | $70,000 |
| Custom development | $0 (capped) | $120,000 | $120,000 |
| Annual upgrades (5 × labor) | $0 | $40,000 | $55,000 |
| Sysadmin / ops labor (120 hr/yr @ $100) | $0 | $15,000 | $60,000 |
| Training & change mgmt | $20,000 | $25,000 | $25,000 |
| Backup, monitoring, TLS tooling | $0 | $0 | $4,000 |
| 5-Year TCO (approx) | ~$750,000* | ~$760,000 | ~$700,000 |
*Scenario B assumes the 50-user team needs the Custom plan and some paid third-party Odoo Online add-ons to partially replace custom code. In practice, most 50-user deployments outgrow Odoo Online and force the choice between Odoo.sh and self-hosted.
Why the Numbers Shift Around 25-30 Users
The break-even is driven by fixed vs. variable costs. License cost is variable: it scales linearly with user count. Sysadmin labor, backup infrastructure, monitoring tooling, and a baseline VPS are fixed: they cost roughly the same whether you have 10 or 50 users. Once the variable license cost dwarfs the fixed ops cost, the cheapest infrastructure wins — and that is always a well-tuned self-hosted deployment.
The single line item most teams under-budget is annual upgrade labor. Upgrading an Odoo major version with 10 custom modules takes 40-80 hours of developer time even on Odoo.sh (where the infrastructure upgrade is free). On self-hosted, add another 20-30 hours for the infrastructure migration itself. Over 5 years, that is $30,000-$55,000 you must plan for — not the $0 line item you see in the Odoo.sh pricing page.
Getting TCO right up front matters because switching hosting tiers mid-implementation is expensive. For a deeper look at per-user and per-module pricing assumptions, see our Odoo Pricing 2026 breakdown.
Security & Compliance — Who Is Actually Responsible For What
Security posture across the three options is not "better or worse." It is a shared-responsibility matrix. The amount of security Odoo provides is inversely proportional to the amount you control. Pick the tier where the boundary of responsibility matches your compliance obligations — not the tier with the longest certification list.
Odoo Online — Odoo Owns the Stack
Odoo Online runs on Google Cloud and AWS infrastructure. Odoo S.A. maintains SOC 2 Type II attestation and ISO/IEC 27001:2022 certification covering the Online and Odoo.sh platforms. Data is encrypted at rest (AES-256) and in transit (TLS 1.2+). Backups run every 24 hours and are retained for 3 months, replicated to at least one additional region. Odoo manages patching, intrusion detection, and incident response. You get an audit report on request and a data processing agreement that is GDPR-aligned out of the box. What you cannot do: pin a specific version, install a custom WAF, run a third-party DLP agent, or get raw server logs.
Odoo.sh — Same SOC 2, You Own the Code
Odoo.sh inherits the same SOC 2 Type II + ISO 27001 certifications as Online for the platform layer. The critical difference: the code running on that platform is yours. If you install a third-party module from the Odoo App Store that has a SQL injection flaw, Odoo's SOC 2 does not cover that. Your GitHub repository is the attack surface for supply-chain issues. Odoo.sh gives you sandboxed staging branches for security testing, automated dependency scanning via GitHub's native tooling, and per-branch database isolation — but your code review process is what determines whether vulnerabilities ever hit production.
Self-Hosted — You Are the SOC 2
Self-hosting gives you absolute control and absolute responsibility. The operational benefit is real: full network isolation (Odoo inside a private VPC with no public internet egress, if you want), custom WAF rules, your own TLS certificate rotation policy, database-level audit logging, and the ability to achieve compliance certifications tailored to your industry (HIPAA, PCI-DSS Level 1, FedRAMP, Canadian PIPEDA regional residency). The cost: every control in your SOC 2 report is now your team's job. You run the patching, the pentests, the vulnerability scans, the backup validation, and the incident response drills. You also need to prove all of that to auditors.
Data Residency — Where Is Your Data Actually Stored?
Odoo Online and Odoo.sh let you choose from US, EU (Germany / Belgium), and Canada as your primary data region at signup. Once chosen, data is pinned to that region, but metadata (account info, billing) may cross borders. For strict data sovereignty (Canadian PIPEDA, German BDSG, healthcare data that cannot leave a jurisdiction), self-hosted in a domestic cloud or on-premise is often the only defensible answer. If you are serving Canadian regulated customers, our Octura hosting team deploys in Canadian AWS (ca-central-1) and Montreal-based OVHcloud regions with signed data residency agreements.
A SOC 2 report tells you Odoo has controls. It does not tell you those controls cover your risk. Read the scope section. Odoo's SOC 2 covers the platform — not your custom modules, not your user provisioning hygiene, not your admin password policy. Treat the certificate as a floor, not a ceiling.
Performance — Throughput, Latency, and What Actually Slows Down
Performance across the three options is not a straight ranking. Each has a different bottleneck, and the right question is not "which is fastest?" but "which will be fast enough for my workload, and where does it break?"
Odoo Online — Shared Workers, Known Ceilings
Odoo Online runs on shared multi-tenant infrastructure. Each database gets a fair slice of worker processes — typically 2 HTTP workers and 1 cron worker for a Custom-plan instance — but you share underlying CPU, memory, and PostgreSQL with other tenants. For 90% of Odoo Online customers this is invisible: typical Sales, CRM, and Inventory workloads rarely hit the ceiling. Where it shows: bulk invoice imports of 10,000+ rows, heavy BI reports that join 1M+ account move lines, or peak-hour login storms. You cannot tune around it — no index tuning, no worker scaling, no read replicas.
Odoo.sh — Dedicated Workers, Predictable Scaling
Odoo.sh gives you dedicated workers per branch. The Production plan starts at 1 worker, scales linearly to 16+ workers, and each worker is a genuine isolated process with pinned memory and CPU. PostgreSQL is dedicated per project (not shared). Adding workers is a slider in the Odoo.sh UI — it takes 2 minutes and a $60/month cost bump. You cannot, however, change PostgreSQL parameters (shared_buffers, work_mem, effective_cache_size), install pgBouncer, or add a Redis cache layer. The envelope is real but fixed.
Self-Hosted — Tunable, Can Outperform Both
Self-hosted Odoo with a properly tuned stack routinely outperforms both Online and Odoo.sh by 2-5x at scale. The stack we deploy: Odoo with --workers set to (2 × vCPU) + 1, PostgreSQL 16 with shared_buffers = 25% of RAM, effective_cache_size = 75% of RAM, and work_mem tuned per connection. Add pgBouncer in transaction mode to multiplex database connections, Redis for session storage, and Nginx in front for TLS, HTTP/2, gzip, and aggressive static-asset caching. The combination cuts P95 latency for list views from 800ms (default) to 180ms on a well-provisioned 8-core machine.
The catch is that you have to build and maintain this. Misconfigure shared_buffers and you slow the instance down. Forget to size max_connections for the number of workers and you lock up PostgreSQL under load. For the production configuration we use across our deployments, see our Production-Ready Odoo 19 Installation Guide and the Nginx Reverse Proxy configuration.
Maintenance & Upgrade Cadence — Who Pushes the Button
Maintenance is where the cost model of each tier diverges most sharply from the sticker price. The minute-to-minute running cost of an Odoo deployment is almost all labor, and that labor is concentrated around upgrades, backup verification, and incident response.
Odoo Online — Zero Maintenance, Forced Upgrades
Odoo Online upgrades automatically. You get a heads-up email roughly 30-60 days before your database is moved to the next major version. You cannot skip it, defer it, or stay on an older version to wait for a critical third-party module to catch up. The upside: zero ops labor. The downside: your workflow can change overnight, and any Studio customizations that relied on deprecated fields can break without warning. The Odoo upgrade service (free for Online customers) handles data migration, but UX changes and report layout differences are yours to discover.
Odoo.sh — Forced Upgrade, Staged Testing
Odoo.sh also follows a forced annual upgrade cycle but gives you a staging branch to test against before you click the button. You clone production to a staging branch, trigger the upgrade, run your test suite, fix any custom module breakage, and then promote to production during a maintenance window. This is the best of both worlds for most teams — the infrastructure work is Odoo's, the testing work is yours, and you control the cutover time.
Self-Hosted — You Control the Cadence, You Carry the Labor
Self-hosting is the only option where you can stay on Odoo 17 for three years if that is what your risk posture demands. You also carry the full upgrade labor: OS migration, PostgreSQL major version bump, Odoo binary upgrade, module migration scripts, staging validation, and cutover. A 10-module Odoo 18 → 19 upgrade on self-hosted is a 60-80 hour project. Done right, it is boring. Done wrong, it is a data loss event. Teams that self-host successfully run a quarterly cadence: security patches monthly, minor versions quarterly, major versions annually with a 2-week test window.
Decision Matrix — When Each Option Is Clearly Right
After running deployments across all three tiers for SMBs and mid-market customers, the selection criteria have stabilized. Use this as a starting point; every real decision has additional constraints, but these are the defaults we recommend.
| Situation | Recommended Hosting | Why |
|---|---|---|
| <10 users, standard workflows, no in-house IT | Odoo Online | Fastest time-to-value, bundled ops, lowest 5yr TCO at this size |
| 10-50 users, need 2-5 custom modules, want managed infra | Odoo.sh | Git-native workflow, staging branches, Odoo handles security ops |
| >50 users, heavy customization, in-house DevOps | Self-hosted | Cost advantage kicks in, control over performance tuning |
| Data residency / sovereignty requirements | Self-hosted (domestic cloud) | Only option with signed residency guarantees for regulated jurisdictions |
| HIPAA / PCI-DSS Level 1 / FedRAMP workloads | Self-hosted | Required controls exceed Online / Odoo.sh scope |
| Rapid PoC or Odoo evaluation | Odoo Online (free trial) | Zero setup, kill it in a month if it doesn't fit |
When To Pick Odoo Online
Pick Online if you have fewer than 10 users, your processes match Odoo's out-of-the-box flows (or are achievable in Studio), you have no dedicated IT team, and you want to be operational in days rather than weeks. It is also the right pick for pilots and proofs-of-concept where the goal is to validate the product before committing to a larger implementation.
When To Pick Odoo.sh
Pick Odoo.sh if you need custom Python modules, want Odoo to manage the infrastructure security perimeter, value GitHub-native workflows and staging branches, and are comfortable paying a 20-30% premium over raw self-hosted for Odoo to handle backups and DR. This is the sweet spot for most mid-market Odoo customers with an in-house or partner dev team but no dedicated SRE function.
When To Pick Self-Hosted
Pick self-hosted if you have more than 50 users, meaningful customization, a team capable of running PostgreSQL and Linux in production, or compliance requirements that force data residency. Cost becomes a net positive at scale, and the ability to tune the full stack (PostgreSQL, Redis, Nginx, storage backend) removes the performance ceiling Odoo.sh imposes. The prerequisite is honest self-assessment: if nobody on your team has run a production PostgreSQL instance before, self-hosting is a liability, not a saving.
Frequently Asked Questions
Odoo.sh is a platform-as-a-service that runs Odoo Enterprise on Odoo-managed infrastructure, with a GitHub repository wired to automatic staging branches and per-branch databases, so you can deploy custom modules without running the servers yourself.
Yes. Odoo supports a one-click migration from Online to Odoo.sh that preserves your data, user accounts, and configuration. Once on Odoo.sh you gain a Git repo and can start deploying custom modules. The reverse migration (Odoo.sh back to Online) is not supported if you have installed any custom Python code.
Not always. Below 25-30 users, Odoo.sh is usually cheaper once you price in sysadmin labor. Above 50 users, self-hosted starts winning because sysadmin cost stays roughly flat while Odoo.sh scales per worker. The real variable is whether your team can absorb the ops work without hiring.
No. Odoo Online runs a locked SaaS environment with no shell access and no ability to add Python code. The Custom plan includes Studio for no-code customization, which covers simple field additions, automated actions, and basic report changes. Anything more complex requires Odoo.sh or self-hosted.
Community is AGPLv3 and free. Enterprise is paid per user and adds modules that are not in Community: full Accounting (Community has invoicing only), Studio, mobile apps, advanced reporting, and official migration support. Both run on the same self-hosted stack. Odoo Online and Odoo.sh run Enterprise only.
Odoo Online and Odoo.sh both run automatic daily backups retained for 3 months, replicated to multiple regions. Restore is self-service via the customer portal. Self-hosted requires you to build backups: we run pg_dump nightly, push to S3-compatible object storage with 30-day retention, and test a restore into a staging environment every quarter.
Technically, no — all three are available directly through odoo.com. In practice, implementations above 10 users that involve custom modules, data migration from legacy ERPs, or multi-entity accounting almost always benefit from a partner. A Ready Partner brings implementation playbooks, migration tooling, and the ability to deploy correctly on the first try rather than iterating in production.
Requests queue against available workers. Users see slower page loads but no errors. The Odoo.sh dashboard shows worker saturation in real time and suggests adding workers. Upgrading is a single click and takes effect within minutes; the $60-per-additional-worker price appears on the next billing cycle.
Yes, in self-hosted deployments. We run Odoo on EKS and GKE for clients who need HA across multiple availability zones. The pattern: stateless Odoo pods behind an ingress, StatefulSet PostgreSQL with EBS/PersistentVolume storage (or Aurora/Cloud SQL for managed Postgres), Redis for sessions, and S3 for attachments via the filestore-S3 module. It is not a beginner deployment.
Online → Odoo.sh is usually 1-2 days. Online → self-hosted is 3-7 days because you must set up the infrastructure first. Odoo.sh → self-hosted takes 1-2 weeks including staging, testing, and DNS cutover. Self-hosted → Odoo.sh requires code review to confirm all modules pass Odoo.sh's security constraints; budget 2-4 weeks for a mature production deployment.
Optimization Metadata
5-year TCO, security, performance, and maintenance compared across Odoo Online, Odoo.sh, and self-hosted. Free architecture review.
1. "The Three Odoo Hosting Options — What You Are Actually Choosing Between"
2. "5-Year Total Cost of Ownership — Where the Numbers Actually Land"
3. "Security & Compliance — Who Is Actually Responsible For What"
4. "Decision Matrix — When Each Option Is Clearly Right"