Odoo SaaS & Hosting
Hosting is judged on the worst day, not the average one. The questions that matter are the restore, the patch and the exit.
Run your own Odoo SaaS platform or consume ours: multi-tenant, auto-scaling, automated backups, Cloudflare-proxied, 99.9% uptime SLA.
Two different jobs share this name. One is running your own Odoo instance properly: sized correctly, backed up in a way that has been tested, patched on a schedule and watched by something that wakes a human. The other is running a platform where you sell Odoo to your own customers, which adds tenant provisioning, isolation, per-tenant backup and a support model.
We do both, and the discipline is the same. Backups are only real once restored. Isolation is only real once someone has tried to cross it. Capacity is only known once measured under your actual load rather than a benchmark.
The exit path is part of the service, not a concession. You get a full database and filestore export whenever you ask, in a form another provider can take. A hosting arrangement you cannot leave is not a service, it is a hold.
What is included
- โ Multi-tenant or single-tenant deployments
- โ Auto-scaling infrastructure
- โ Automated encrypted backups
- โ Cloudflare DNS & DDoS protection
- โ SSL auto-renewal (Let's Encrypt)
- โ Disk/CPU/uptime monitoring
- โ 99.9% uptime SLA
- โ Disaster recovery & geo-redundancy
How the engagement runs
- 1
Sizing and design
Fit the platform to your real load rather than to a package name.
- Measure or estimate concurrent users, transaction volume, attachment growth and reporting peaks
- Decide single-tenant or multi-tenant, and where the isolation boundary sits
- Choose the region, which is driven by where your users are and by your data policy
- Plan the environments: production, staging and a place to test restores
You end up with: A written architecture with sizing, environments and the growth assumptions behind them.
- 2
Provisioning and hardening
Stand it up so it is defensible from day one.
- Build the servers, database and application layer with access restricted to what is needed
- Certificates automated so expiry is not an outage waiting to happen
- A proxy layer for filtering and traffic protection, with sensible rate limits
- Least-privilege accounts, no shared logins, and key-based administrative access
You end up with: A running environment with an access map showing who can reach what.
- 3
Backup and recovery
Be able to prove recovery, not describe it.
- Scheduled encrypted backups of database and filestore, held off the host
- Retention set against how far back you might genuinely need to reach
- Restore drills on a schedule, timed, with the result recorded
- Recovery objectives written down and matched by the design, not asserted in a brochure
You end up with: A tested restore with a measured duration, repeated on a schedule.
- 4
Operations
Keep it healthy without waiting for a user to notice.
- Monitoring on uptime, disk, memory, CPU, database size and error rates
- Alerts that reach a person with an escalation path behind them
- Patching through staging on a schedule, in small steps
- Log rotation, attachment growth and database maintenance handled before they bite
- Capacity review as your numbers move, ahead of the problem rather than after it
You end up with: A monthly operations report covering uptime, incidents, patches and restore tests.
- 5
Tenant lifecycle
For platform operators: make onboarding and offboarding routine.
- Repeatable provisioning of a new tenant with its own database, domain and certificate
- Per-tenant backup and restore that does not involve the others
- Version policy per tenant, so one customer cannot block everybody else
- Suspension, reactivation and deletion handled as defined operations with an audit trail
You end up with: A provisioning and offboarding runbook that someone other than its author can follow.
What you need to provide
The schedule slips on these more often than on anything technical.
- โ Domain control, or the ability to make the DNS changes we specify
- โ Your data residency requirements, and any restriction on where backups may be held
- โ Expected user count and growth, honestly, since undersizing is usually built on optimism
- โ A named technical contact for change approvals and incidents
- โ Your maintenance window and what an acceptable planned outage looks like
- โ The list of integrations that must keep working, so firewall and access rules cover them
Decisions you will be asked to make
Single-tenant or multi-tenant
Single-tenant is simpler to reason about, easier to isolate and to move. Multi-tenant is cheaper per customer and only makes sense if you are running a platform. Choosing multi-tenant for one business buys complexity with no return.
Where the data sits
Region affects latency for your users and may be constrained by your own policy or your customers' contracts. It is easier to choose than to change, because moving a database means a maintenance window.
How much recovery you are buying
How much data you can afford to lose and how long you can be down are two separate numbers, and they drive cost more than anything else in the design. Naming them turns hosting from a package into a specification.
Who holds the upgrade decision
For a platform, a version policy per tenant keeps one slow customer from freezing the fleet. For a single instance, it is about aligning upgrades with your own calendar rather than ours.
Where this goes wrong
The failure modes we plan around, and what the plan does about each one.
Backups nobody has restored
A green tick proves the job ran. It says nothing about whether the file opens. Restores are drilled on a schedule and the duration recorded, because that duration is your real recovery time.
Sizing based on a package name
Plans are sold by tier rather than by load, and the mismatch surfaces at your busiest hour. Sizing follows measurement, and capacity is reviewed as your numbers move.
Certificates and domains expiring
Entirely avoidable, and still one of the most common causes of a day of downtime. Renewal is automated and expiry is monitored anyway.
Shared administrative credentials
When everyone uses the same login, nobody can be held to a change and revoking access means changing it for all. Named accounts with least privilege, from the start.
Isolation assumed rather than tested
On a multi-tenant platform, the boundary between customers has to be verified rather than trusted, including in backups, in logs and in scheduled jobs.
No exit path
A hosting arrangement you cannot leave is a commercial trap, and everyone knows it by the time it matters. Full export on request, in a portable form, is written into the agreement.
Patching left because it is risky
Deferred patching accumulates until the upgrade is genuinely dangerous, which then justifies deferring it further. Small steps on a schedule through staging is the only way out.
Not included
Stated up front so the proposal has no soft edges.
- ร Odoo subscription fees and third-party module licences
- ร Application-level defects and custom code fixes, which belong to support or development
- ร Data entry, cleanup and user error recovery
- ร Compliance certification of your business: we operate the platform, we do not certify your organisation
- ร Domain registration fees and third-party service subscriptions
- ร Network problems on your side, between your office and the internet
How this is priced
Hosting is a monthly fee by environment size, with backup retention and the response tier stated. Platform operators are priced on the fleet rather than per tenant. Migration onto the platform from an existing host is a one-off piece of work, quoted after we have seen what is there.
See the published bands โModules that come up on this work
Ready-built modules from our own catalogue. Where one of these covers the requirement, installing it beats writing it.
Cloud Backup Pro - Multi-Destination Encrypted Database & Filestore Backup
Encrypted, scheduled Odoo database + filestore backup to S3, SFTP, Local NAS, Google Drive, Dropbox and OneDrive. GFS retention, integrity verification, one-click restore, health dashboard, email/webhook alerts.
Why here: Scheduled encrypted backups held somewhere other than the host, with restores that have actually been run.
ToolsOdoo Debranding / White Label
White-label Odoo completely - replace the Odoo name, logo, favicon and "Powered by Odoo" everywhere with your own brand, driven from the Company form.
Why here: Platform operators selling under their own name need the branding replaced everywhere, not just on the login page.
ToolsWT Theme SaaS Startup
SaaS / startup theme: product-focused hero, features, pricing tiers, integrations, customer logos, testimonials, FAQ, contact. Built for SaaS companies, software products, tech startups and B2B tools.
Why here: A platform needs a front door: pricing, plans and sign-up, without a separate website build.
Theme/ServicesAudit Log & Access Tracking
Track who created, changed or deleted records - full audit trail with field-level history and access-rights tracking.
Why here: Multi-tenant operations need a record of who changed what, particularly where your support staff can enter customer databases.
ProductivityPWA Mobile App + Real-Time Push Notifications
Install Odoo as a mobile app (PWA) and send real-time web push notifications to phones & desktops - branded app icon, one-click setup, reusable push API. No Enterprise, no app store.
Why here: Where tenants expect a mobile app experience, this avoids a separate mobile build per customer.
ProductivityOdoo cloud hosting, on premise on your own servers, or self hosted in your data centre. Backups, monitoring and patching either way.
Where we deliver this
Data residency and hosting region are often decided locally. The country pages carry what applies in each market.
Odoo SaaS & Hosting: common questions
What does the uptime commitment actually cover?
The platform we operate: servers, database, application service and network. It does not cover your internet connection, a third-party API being down, or an outage caused by custom code deployed against our advice. Planned maintenance inside the agreed window is excluded and announced ahead of time.
How often are backups taken and tested?
Encrypted backups run on a schedule and are held off the host with a retention period you choose. Restore drills are scheduled separately, timed and recorded, because an untested backup tells you nothing. The measured restore time is your real recovery time and it appears in the monthly report.
Can we get our data out?
Yes, on request, as a full database and filestore export in a form another provider can take. That is in the agreement rather than at our discretion.
Do you host Odoo Community and Enterprise?
Both. The hosting work is the same. The difference is licensing and which apps are available, and that is a decision worth taking with the consultancy service rather than at the hosting stage.
What do I need to run my own Odoo SaaS platform?
Repeatable tenant provisioning, per-tenant backup and restore, a version policy so one customer cannot block the rest, monitoring across the fleet rather than per box, and a support model with defined response times. The technical part is the smaller half. The operating discipline is what decides whether it scales.
Can you take over hosting we already have?
Yes. It starts with a review of what is there, a tested restore before anything is moved, and a migration into a maintenance window. Where the current provider will not cooperate, it takes longer, because we reconstruct the picture ourselves rather than guess at it.
Read next
Odoo Support & Maintenance
24/7 monitoring, bug fixes, performance tuning.
Odoo Consultancy
Expert advice on architecture, licensing, and strategy.
Odoo Migration & Upgrade
Upgrade safely from older Odoo versions.
Odoo Health Audit
Deep technical + functional audit of your instance.
Odoo Implementation
End-to-end Odoo deployment, from discovery to go-live.
Tell us what you are trying to fix
A 30-minute call is usually enough to tell you whether this is a small piece of work or a project, and to say so before anyone writes a proposal.