Which Odoo hosting model fits your team
If your team has standard Odoo apps and no custom modules, Odoo Online is the simplest place to run them. If you need custom modules with managed development, staging and production branches, Odoo.sh is the managed route. If you need control over the servers, data location or network, self-hosted Odoo is the answer. The decision starts with the plan, not preference: according to Odoo's pricing page, only the Custom plan can be hosted on Odoo.sh or on-premise, and only Custom includes custom modules, multi-company, Odoo Studio and external API access. The One App Free and Standard plans are limited to Odoo Online.
Odoo Online has real advantages for standard use. Hosting is free with unmetered storage up to 100 GB, according to the pricing page, and databases are backed up daily under the Odoo Cloud Hosting SLA, with backups downloadable from the database manager. The trade-off is that Odoo Online cannot run custom modules or Apps Store modules, and SaaS versions are released every two to three months with no extended support. Before committing, confirm with Odoo which SLA terms, backup retention and data residency apply to your region and your regulator's expectations, since those details sit in Odoo's contract documents rather than the pricing page. Odoo's hosting documentation describes the moves between hosting types.
Odoo.sh and self-hosting both cost more to run, and the cost structure differs. Odoo.sh charges per worker, per GB of storage and per staging environment, and its pricing page states that the hosting price does not include the Enterprise license, so the license is a separate line item on top of the Custom plan. Self-hosting shifts the work to your team or to an implementation partner: patching, backups, monitoring and the upgrade path. Ask any quote to separate the Custom plan subscription, Odoo.sh or infrastructure charges, and the labor for custom module maintenance. Regulated teams should also check whether Odoo.sh's data location and access controls meet their obligations before choosing it over their own servers.
How Odoo Online, Odoo.sh and self-hosted Odoo compare
This table compares the three places to run Odoo on plan eligibility, custom modules, cost structure, support, backups, environments and upgrade duties. Read the rows marked as plan or infrastructure dependent first, because they decide which column is open to you. The main takeaway is that custom code rules out Odoo Online, and that Odoo.sh and on-premise both require the Custom plan.
| Factor | Odoo Online | Odoo.sh | Self-hosted Odoo |
|---|---|---|---|
| Plan eligibility | Standard plan or One App Free, or Custom plan | Custom plan only | Custom plan only, with an Enterprise subscription for Enterprise apps |
| Custom modules | No | Yes | Yes |
| Hosting cost structure | Hosting free with unmetered storage up to 100 GB, subscription per user | Hosting priced per worker, per GB of storage and per staging environment, Enterprise license extra | Your servers, staff and licenses, plus Enterprise subscription if used |
| Data location | Odoo cloud infrastructure | Odoo.sh infrastructure, backups on 3 servers in different locations | Infrastructure you control, including air-gapped networks |
| Standard support | Three years after major release, releases every two to three months | Three years after major release | Three years after major release |
| Extended support | Not eligible | Paid, for select versions only | Paid, for any version |
| Backups | Daily under the Odoo Cloud Hosting SLA, downloadable from database manager | Live storage replication and backups on 3 servers in different locations | Your backup design, to confirm with your own team or DeployOpen scope |
| Environments | Production database managed by Odoo | Development, staging and production branches | As many environments as you build and operate |
| Major upgrade obligation | Mandatory every two years | Mandatory every two years | Set by your support and upgrade plan, confirm the policy for your version |
| Moving between models | Move to on-premise right after a stable release is the suggested timing | Move from Odoo.sh requires a database export and migration plan | Move to Odoo Online requires removing non-standard apps and a support ticket |
What control and data location change for compliance
The three options differ less in features than in who runs the servers, who can reach the database, and where backups live. Each card below is a decision or check that follows from those differences, and DeployOpen prepares the controls and evidence for your assessment without issuing any audit report or certification.
Data location on Odoo Online
On Odoo Online, the database sits on Odoo's cloud infrastructure, and you do not choose the server or the physical site. Odoo's documentation says databases are backed up daily under the Odoo Cloud Hosting SLA, and backups can be downloaded from the database manager. Before you commit, confirm the hosting region, the data residency commitments and the SLA terms in writing with Odoo, since these are vendor terms, not something this page can state for you.
Odoo.sh backup locations
Odoo.sh plans include live storage replication and backups on 3 servers in different locations, which is a concrete resilience fact but not a residency statement. Your data still lives on Odoo-managed infrastructure, so ask Odoo which regions the three servers occupy and whether any copy leaves your required jurisdiction. Map that answer to your own retention and deletion obligations before you accept it as sufficient.
Administrative access and SSH
Odoo.sh gives developers shell and SSH access, a GitHub integration and an online editor, so access control is partly yours to configure. On Odoo Online, Odoo staff operate the platform and you manage users and applications inside the database. On self-hosted Odoo, your team holds root access to the host, the PostgreSQL server and the filestore. Write down who holds each level of access under each option and review it against your privileged access policy.
Self-hosted data stays in your estate
Self-hosting keeps the database, filestore and backups inside your cloud accounts, data centers or air-gapped network. That gives you direct control over location, encryption and retention, but it also moves responsibility for backup testing, patching and monitoring to your team or to a provider such as DeployOpen. Confirm that your backup design, restore tests and log retention can be evidenced for the control owner who will review them.
Authentication and directory integration
Odoo documents LDAP authentication, which lets you tie Odoo logins to a central directory. Whether that connection is possible depends on the option: confirm with Odoo which hosting models allow the LDAP settings you need, and test the identity path in a staging environment. Centralized authentication supports access reviews and joiner and leaver controls, but only if the directory remains the source of truth.
Evidence and regulator requirements
DeployOpen can prepare configurations, access records, backup evidence and runbooks for a compliance assessment, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Before choosing a hosting model, confirm with your regulator or assessor which location, access and retention rules apply to your data, and who will be asked to produce the evidence.
How standard and extended support differ by hosting model
Your hosting model decides how long a given Odoo version stays patched, so pick the version and the host together. Odoo provides standard support, with security updates and bug fixes, for three years after a major release. Per Odoo's support documentation, that window applies on Odoo Online, Odoo.sh and on-premise alike. The supplied timeline shows the clock: Odoo 20.0 was released in September 2026 with standard support planned until September 2029, Odoo 19.0 (September 2025) runs until September 2028, Odoo 18.0 (October 2024) until September 2027, and Odoo 17.0 standard support ended in September 2026. A version that is out of standard support receives no security patches on any host unless you pay for extended support, so the first question is always where the version sits on that timeline.
The hosting models diverge after standard support ends. SaaS versions on Odoo Online are released every two to three months and cannot use extended support, so an Odoo Online tenant moves forward on Odoo's schedule and must accept the upgrade cadence. Paid extended support exists only for on-premise deployments, for any version, and for a limited set of Odoo.sh versions. An on-premise or Odoo.sh team that wants to hold a version longer than standard support can therefore buy time, while an Odoo Online customer cannot. Before committing, ask Odoo which Odoo.sh versions are currently eligible for extended support, how long that coverage lasts, and what it costs in your written quote, because those details are not part of the standard window.
Treat the support end date as a planning deadline for custom code. Security updates stop when standard support ends, so a custom module that depends on a version without extended coverage carries unpatched exposure from that date onward. Build your upgrade rehearsal, using a test database as Odoo's upgrade documentation describes, into the project calendar well before the end of standard support, and confirm with your partner and Odoo which environment will be used for the rehearsal. If you are on Odoo Online and cannot hold a version, confirm that your apps and any third-party modules are compatible with the next release before the cadence forces the move.
What your team runs in each Odoo hosting model
Odoo Online is Odoo's own cloud hosting for databases that use only standard apps. Odoo runs the infrastructure, so your team does not patch servers, manage PostgreSQL or set up monitoring. Custom code is the constraint: the Odoo Online documentation states it is incompatible with custom modules and modules from the Odoo Apps Store, so any development work has to fit within standard configuration.
- Custom development: Your team configures standard apps. Custom modules are not an option on this model, so requirements that need code must be met some other way or move the deployment elsewhere.
- Backups and restores: Odoo Online databases are backed up daily under the Odoo Cloud Hosting SLA, and backups can be downloaded from the database manager. Confirm the restore process and retention terms in the SLA before relying on them for your recovery plan.
- Monitoring and patching: Odoo handles OS, PostgreSQL and platform patching. Your team monitors business processes, not infrastructure.
- Upgrades: SaaS versions are released every two to three months, and major upgrades are mandatory every two years on Odoo Online, so your team plans testing around Odoo's release schedule.
Confirm with Odoo which plan includes Odoo Online hosting for your user count and apps, and what the SLA covers in writing.
Odoo.sh is Odoo's managed platform for custom modules. It provides development, staging and production branches, so your team can build and test custom code against the same platform that serves production. It requires the Custom plan, and the hosting price does not include the Enterprise license.
- Continuous integration and testing: Every plan includes continuous integration and testing, GitHub integration, and an online editor, so code changes move through branches before production.
- SSH access and shell: Every plan includes shell and SSH access, so your developers can inspect logs, run commands and debug inside the environment. This access is a responsibility: define who holds it and how it is audited.
- Monitoring and backups: All plans include 24/7 monitoring, live storage replication and backups on 3 servers in different locations. Your team still owns restore testing and the business decision about data retention.
- Module deployment: Your team writes, reviews and deploys custom modules. Odoo runs the platform, but code quality, dependency choices and regression testing stay with you or your implementation partner.
- Upgrades: Major upgrades are mandatory every two years, and your team must test custom modules against each new version on a staging branch before promoting it.
Confirm worker and storage sizing with Odoo, and ask how staging environments are billed for your planned branch count.
Self-hosted Odoo runs in your own data center or cloud accounts. You get full control over the operating system, network, database and modules, and you carry the full operating load. Odoo's on-premise documentation covers packaged installers and source installation, and Enterprise databases are activated with a subscription code.
- Operating system and PostgreSQL: Your team patches the OS, PostgreSQL and Python runtime. Odoo 19 requires Python 3.10 or later and PostgreSQL 13 or later, so check these versions against your platform roadmap.
- Backups and restores: You design, run and test backups, including the database and filestore. Restore drills must be part of operations, because no vendor-side backup covers your environment.
- Monitoring and logging: You build and run monitoring, alerting and log retention. Odoo.sh's 24/7 monitoring has no equivalent unless you provide it.
- Upgrades: The upgrade service requires an Enterprise subscription for on-premise use, and the Community edition has no access to it. Without that subscription, your team or partner plans and executes each major version move.
- Custom modules and access: You control deployment of custom modules and can connect services such as LDAP authentication directly.
Confirm your Enterprise subscription terms and whether they cover the upgrade service for each version you plan to run.
How to move Odoo between Online, Odoo.sh and your own servers
This sequence shows how a database can change hosting homes without losing data, and what each stage must prove before the cutover. Each move depends on the database running a supported version and on a tested copy running first.
Confirm the target plan and version support
Before any data moves, confirm with Odoo which plan covers the destination. Odoo's pricing page states that only the Custom plan can be hosted on Odoo.sh or on-premise, so a Standard subscription will not carry a move to either of those. Confirm that the database's current version is still under support, because the Odoo hosting documentation requires a supported version for a move to Odoo Online. You know this step is done when the plan and version are written down and agreed with Odoo, and the destination is named in the project scope.
Prepare a duplicate and remove non-standard apps
Make a duplicate of the production database for the move. Odoo Online is incompatible with custom modules and modules from the Odoo Apps Store, so the duplicate must have every non-standard app uninstalled. The work is done by the client's administrator or the implementation partner in the duplicate, never in production. The check is that the duplicate loads, its installed-module list contains only standard apps, and the business owners have signed off on any functions that stop working once the custom code is removed.
Export the dump and filestore
Export a database dump together with the filestore, which holds attachments and documents that the database alone does not contain. Odoo's hosting documentation names both pieces as part of the move. Store the export in an encrypted location with restricted access, and record its checksum. The output is a dump file and a matching filestore archive that the team can restore into a separate test instance to confirm that counts of records, attachments and users match the source.
Submit the migration support ticket
Submit a support ticket to Odoo requesting the move of the database to Odoo Online, and attach the export details as Odoo's hosting documentation describes. The request should state the source version, the target plan, the apps installed and the cutover window the business has chosen. Expect Odoo to confirm the database meets its requirements before it is accepted. The step is complete when Odoo has acknowledged the ticket in writing and has confirmed the accepted database and environment.
Time the move after a stable release
Odoo's pricing FAQ states that the best time to switch from Odoo Online to on-premise is right after the release of the newest stable version. The same reasoning applies to a move in either direction, because a database that starts on the newest version has the longest standard support window ahead of it. Ask Odoo which version is current and whether a move timed for the next release fits the project plan. The check is a dated decision record that links the chosen version to the expected support end date in Odoo's support documentation.
Test the migrated copy before production
Run the migrated copy in a test environment and confirm that users can log in, that reports and accounting entries match the source, and that integrations reconnect. Odoo's upgrade documentation says a test database should be tested before production, and the same discipline applies to hosting moves. Use neutralized duplicates for repeated test runs, because Odoo documents database duplication with neutralization for test copies, which keeps live email and payment connections from firing. The check is a signed test report that lists each function tested and any open defects.
Cut over and confirm the Odoo.sh or on-premise path
For a move to Odoo.sh, the Custom plan must be active and the database is placed on the development, staging and production branches. Odoo.sh hosting is priced separately from the Enterprise license, so confirm both cost lines with Odoo before the cutover. For a move to your own servers, activate the Enterprise database with its subscription code and keep the Odoo Community source or packaged installer aligned with the same version. Confirm the target's backup schedule, because Odoo Online backs up daily under its SLA, while self-hosted backups are the client's responsibility to design and test.
Confirm open points with Odoo
Before closing the project, confirm with Odoo in writing the points this page cannot settle: current migration fees and timelines, whether a given custom module can be supported on the destination, how long the ticket review takes, and the support terms that apply after cutover. Keep the answers with the scope document. The move is complete when every open point has a written answer and the business has accepted the production sign-off.
Questions buyers ask before choosing an Odoo hosting model
What drives the cost of each Odoo hosting model?
Odoo Online has no hosting fee for up to 100 GB of unmetered storage, but the subscription is priced per user per month, and only the Custom plan allows Odoo.sh or on-premise hosting. Odoo.sh adds hosting charges per worker per month (1 to 16 workers), per GB of storage per month (1 to 512 GB) and per staging environment, and its price does not include the Enterprise license. Self-hosting moves cost into your own infrastructure, staff time and support contracts. Ask every quote to split license, hosting, storage, staging, implementation and recurring support into separate lines, and to state the plan and user count it assumes. Odoo publishes plan prices, but a total for your environment needs a written quote.
Can we move from Odoo Online to self-hosted Odoo later?
Yes, because Odoo Online and Enterprise on-premise run the same software with different hosting. Odoo's pricing FAQ says the best time to switch from Odoo Online to on-premise is right after the newest stable version is released. Moving a database the other way requires uninstalling non-standard apps from a duplicate, exporting a dump with the filestore, submitting a support ticket and running a supported version. Confirm the export steps, version rules and Enterprise subscription terms with Odoo before you set a cutover date. The effort depends on database size, custom code and integrations, so ask for that estimate in writing.
Can an internal IT team run self-hosted Odoo without a partner?
It can, if the team already runs PostgreSQL, Linux services, backups and a formal change process, and has an owner for upgrades. Odoo 19 requires Python 3.10 or later and PostgreSQL 13 or later, and Enterprise databases are activated with a subscription code. Ongoing duties include applying patches, planning major upgrades, testing duplicated databases, monitoring, backups and restore tests. Standard support covers three years after a major release and includes security updates, and those updates stop when standard support ends. Ask whether your team can staff these duties for the full support window, and who covers absences and incidents.
What do custom modules add to the effort of running Odoo?
Custom modules add a code lifecycle on top of the platform lifecycle. Odoo Online is incompatible with custom modules and Apps Store modules, so custom code points you to Odoo.sh or self-hosting. Odoo.sh provides development, staging and production branches, continuous integration and testing, GitHub integration and SSH access, which helps teams that deploy code often. Each major version requires your modules to be ported and tested, and on Odoo Online and Odoo.sh major upgrades are mandatory every two years. Budget for testing and rework at each upgrade, and ask any partner to size that work from your module inventory.
What should a partner scope before an Odoo hosting project starts?
A partner should start with a written inventory covering the Odoo version, edition, user count, installed apps, non-standard modules, integrations, data volume and the target hosting model. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Scope should also cover environments, backup and restore testing, identity integration such as Odoo LDAP authentication, cutover and handover documents. Odoo Online is run by Odoo, so confirm which parts of the work fall to each party. Ongoing support, upgrades and continuous testing are available as retainers.
How do Odoo support windows affect a long-term hosting choice?
They matter most when you plan to stay on one version for several years. Odoo standard support covers three years after a major release on Odoo Online, Odoo.sh and on-premise, including security updates and bug fixes. Odoo 20.0 was released in September 2026 with standard support planned until September 2029, and Odoo 17.0 standard support ended in September 2026. Odoo Online SaaS versions are released every two to three months and cannot use extended support. Paid extended support is available for on-premise on any version and on Odoo.sh for a limited number of versions. Security patches stop when standard support ends, so get the extended support terms in writing before you commit to a version.
Is Odoo Online enough for a company with no custom code?
Often yes, if the standard apps cover your processes and you need no modules from the Apps Store. The One App Free plan covers one app with unlimited users on Odoo Online only, and the Standard plan covers all apps on Odoo Online only. Odoo Online hosting is free with unmetered storage up to 100 GB, and databases are backed up daily under the Odoo Cloud Hosting SLA, with backups downloadable from the database manager. Multi-company, Odoo Studio, external API access and custom modules are included only in the Custom plan, so check those needs before you choose. Confirm the current plan contents on the Odoo pricing page.
What to confirm with Odoo and your own environment before you commit
Before you commit to a hosting route, confirm the current plan terms directly with Odoo, because the answer to whether you need the Custom plan decides every other cost. Only the Custom plan can run on Odoo.sh or on-premise, and only Custom includes multi-company, Odoo Studio, external API access and custom modules. Ask Odoo in writing which plan covers each hosting option you are considering, whether Custom Online hosting carries any conditions, and how the per-user pricing and yearly discount apply to your user count. Then ask for the Odoo.sh price for your actual worker count and storage in gigabytes, plus the cost of any staging environments you need, since the Odoo.sh pricing page states that hosting does not include the Enterprise license and that dedicated hosting is required beyond the published limits.
If you plan to self-host, confirm the Enterprise license scope in writing before installation. The Enterprise license is a separate subscription that must match your user count, and it is required for on-premise use of Enterprise apps and for the upgrade service. Check which apps your business needs (for example Studio, Documents, Payroll or Quality) and confirm that each one is covered at the subscription level you buy. Ask who maintains the server, the backup jobs and the PostgreSQL and Python versions, because on-premise responsibility sits with your team or your implementation partner, not with Odoo's cloud.
Ask for the backup and restore terms in the Odoo Cloud Hosting SLA in writing. The Odoo Online documentation states that databases are backed up daily and that backups can be downloaded from the database manager, but it does not give you a retention period in the material we reviewed, so request the retention window, the restore process and the expected restore time for your database size. Confirm the same for Odoo.sh, where backups are stored on 3 servers in different locations, and test a restore into a non-production branch. Finally, map the upgrade calendar to your plan: standard support for each major version and the mandatory two-year major upgrade cycle on Odoo Online and Odoo.sh both affect your budget and testing windows, so check the current dates on Odoo's support documentation before you choose a version.
How DeployOpen scopes, delivers and supports self-hosted Odoo
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Odoo, that means helping you decide where the database should run, then building and handing over the environment you choose, whether that is your own servers, an Odoo.sh project or a plan that stays on Odoo Online.
How we scope
- We confirm which apps, custom modules and integrations you need before choosing a hosting route.
- We check the Odoo plan and edition each hosting option requires, and record the result in the written scope.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We set up the chosen environment, including staging and production copies, backups and access controls.
- We build and test custom modules and integrations against the supported Odoo version you intend to run.
- We harden the deployment and test restores, so backup and recovery steps are proven before go-live.
How we hand over
- We document the hosting design, upgrade steps, backup routines and any custom code you own.
- We walk your administrators through routine tasks such as duplicating databases and planning version upgrades.
- We provide a written record of what was delivered against the agreed scope, so your team can audit it.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover the move to a newer supported Odoo version before standard support ends for your release.
- Ask any provider to confirm support windows and paid extended support terms in writing before you commit.
