Odoo.sh vs. On-Premise: Picking the Hosting That Fits Your ERP

The Hosting Decision You Can’t Unmake Cheaply

The three Odoo hosting options — Odoo Online, Odoo.sh, and self-hosted — look similar on a vendor brochure. In practice they shape everything downstream: what you can customize, who owns backups, how fast you can ship changes, and where the platform stops being flexible.

This is a decision businesses usually make once. Switching later is possible but expensive: data migration, re-integration, re-training, re-compliance. Worth getting right the first time.

Odoo Online (SaaS): The Lowest-Friction Option

Odoo Online is Odoo’s multi-tenant SaaS. Point a browser, log in, start using it. No server, no DevOps, no deployment.

Who it fits: teams under 50 users, standard Odoo modules, no custom code, minimal integration needs. A classic mid-market professional services shop or a regional distributor replacing QuickBooks + CRM.

What you give up:

• Standard Odoo apps only. Odoo Online doesn’t run modules from the Apps Store or your own code. Both need Odoo.sh or your own server.
• Limited access to the underlying database. Integrations work through the external API only, which is part of Odoo’s Custom plan. No direct DB queries, no custom triggers.
• Upgrade timing isn’t fully yours. Odoo sets a deadline for each mandatory upgrade and runs it automatically if you haven’t started it by then.
• No staging environment in the sense developers expect. You can duplicate the database for testing, up to five copies that expire after 15 days.

For businesses that would otherwise run QuickBooks plus six tools, Odoo Online is often enough. The constraint is fine until the day it isn’t — and by then, you’re migrating anyway.

Odoo.sh: The Managed-Platform Middle Ground

Odoo.sh is Odoo’s PaaS. It’s still hosted by Odoo, but you get a real deployment pipeline: Git-based code deployments, staging environments, branch previews, automated backups, and the ability to ship custom modules.

Who it fits: teams that need custom modules or integrations, but don’t want to run a server themselves. This is the default recommendation for most mid-market Odoo deployments we implement.

What you get:

• Git-based deploys. Your custom modules live in a GitHub repo. Push to a branch, Odoo.sh builds a staging instance automatically. Merge to production when ready.
• Staging environments. Real staging, not a second demo database. Load production data, test upgrades, validate integrations. Matches how real dev teams work.
• Automated backups. Daily backups with a restore-in-place option. Still worth testing restores, but the infrastructure is there.
• Upgrade tooling. You start an upgrade from a branch’s Upgrade tab. Odoo.sh upgrades a copy of your latest production backup and rebuilds it with each commit, so you see what breaks before production does.
• Workers scale with plan size. Performance is predictable because you pick the worker count, not a shared-tenant lottery.

What you still give up:

• No control over the server itself. You get shell and SSH access to your containers, but you can’t install system packages or change the system configuration.
• The database stays inside the platform. You can run psql from the container shell, but PostgreSQL extensions aren’t supported, and outside tools get read-only access only on dedicated hosting.
• Pricing scales with workers and storage, on top of Custom plan licenses. Odoo.sh isn’t available on the Standard plan, so at high user counts it’s not the cheapest option.

For most mid-market deployments we see, Odoo.sh is the sensible default. You get a real deployment pipeline with no infrastructure team required.

Self-Hosted: The Full-Control Option

Self-hosted Odoo runs on your own servers or your own cloud account. AWS, Azure, Google Cloud, a VPS in a data center — anywhere you can run a Linux box and PostgreSQL, you can run Odoo.

Who it fits: regulated industries with data residency requirements, businesses with in-house DevOps capacity, deep custom-module builds that need raw system access, or operations at a scale where managed pricing gets prohibitive.

What you gain:

• Full server access. SSH, database, filesystem — all yours.
• Compliance posture is yours to design. HIPAA, SOC 2, FedRAMP-leaning — if your infrastructure holds the line, Odoo runs inside it.
• Any integration pattern. Direct DB access, pg_cron jobs, custom extensions, whatever your stack needs.
• Cost at scale. At 100+ users, self-hosted can be cheaper than Odoo.sh by a meaningful margin — if you already have infrastructure teams.
• Source is yours to modify. Odoo Community is open-source; even on Enterprise, you can fork and patch.

What it costs:

• Someone runs the server. OS patching, PostgreSQL tuning, backup verification, monitoring, log rotation — real work.
• Upgrades are on you. Odoo.sh’s automated upgrade tooling doesn’t exist here. You write the upgrade runbook.
• Backups are on you. Not just taking them — testing restores, verifying integrity, keeping off-site copies.
• Security is on you. Firewalls, intrusion detection, patch management, access controls. A real attack surface.

The mistake businesses make with self-hosted is underestimating the ops cost. A mid-market self-hosted Odoo probably needs 20–40 hours a month of sysadmin work to run safely. Below that, you’re accruing operational debt.

The Decision Framework

Five questions decide this:

1. How deep is your customization appetite? No custom code: Online works. Custom modules or custom workflows: Odoo.sh. Integrations that write to the database directly or need PostgreSQL extensions such as pg_cron: self-hosted.
2. Do you need regulated or sovereign hosting? If yes (healthcare, defense, some financial), self-hosted inside your compliant infrastructure. If no, check Odoo’s security documentation against what your auditor asks for before you settle on Odoo.sh.
3. Do you have in-house DevOps? If yes, self-hosted is viable. If no, Odoo.sh. Don’t let someone with no server background run your ERP in the basement.
4. What integrations need direct database access? Most don’t. Read-only access for a BI tool or a data warehouse works on Odoo.sh dedicated hosting. Trigger-based sync, or anything that writes to the database, forces self-hosted.
5. How do you want to handle upgrades? Odoo.sh automates the mechanics. Self-hosted makes them your problem. Odoo Online makes them someone else’s schedule.

Migration Paths Between the Three

These aren’t one-way doors. You can move between hosting models, but each path has a tax:

• Online to Odoo.sh: Cleanest path. Odoo supports the migration directly — you get a database dump and redeploy. Plan for a few days of work plus any custom modules you now want to add.
• Odoo.sh to self-hosted: Clean dump-and-restore. You keep all your code and configuration. The work is standing up the infrastructure, not moving the data.
• Online to self-hosted: Functional but messier. You’re adding infrastructure and possibly custom modules at the same time. Treat it as two projects, not one.
• Self-hosted to Odoo.sh: Works as long as your modules are Odoo-compliant. Forks or deep core patches make this painful — you’re either abandoning customizations or staying put.

Common Mistakes in the Hosting Decision

Picking Online when you’ll need custom code in year two. Happens constantly. Team sees the price, signs up, six months later hires a developer and discovers they can’t ship anything. Now they’re migrating to Odoo.sh during a product build — the worst possible time.

Picking self-hosted because “we have a guy.” The guy is already fully loaded with other work. ERP servers don’t maintain themselves. Within a year, the instance is running a 6-month-old Odoo version with unpatched dependencies, and nobody’s tested a backup since go-live. Backups that have never been tested are just optimism.

Picking Odoo.sh at 5 users. It works, but you’re paying for infrastructure you aren’t using. Odoo Online is cheaper and sufficient at that scale, with a clean upgrade path later.

Bottom Line

For most mid-market Odoo deployments, Odoo.sh is the right default. You get real deployment infrastructure, managed upgrades, and a team behind you without running a server yourself. Odoo Online is fine for simpler needs at smaller scale. Self-hosted is powerful but expensive in operational overhead — pick it for the reasons you pick self-hosted, not because it’s the cheapest sticker price.

The hosting decision isn’t about today’s feature list. It’s about where you want the system to be in three years — and how much friction you’re willing to carry to get there. If you’re weighing the three against a real deployment, the free Odoo fit assessment walks through exactly this question against your constraints.