Odoo Hosting: Self-Hosted vs Managed vs Odoo.sh (2026 Decision Guide)

Same ERP, two very different jobs: you either run the server, or someone runs it for you.

Picking where your ERP lives is one of those decisions that feels trivial on day one and very expensive three years later. If you're comparing Odoo hosting options right now, you're really choosing between two models: self-hosting Odoo on infrastructure you control — a VPS, a dedicated server, or a machine in your office — or handing the server work to a managed hosting provider (including Odoo's own cloud).

I'm Mostafa Amaan, a senior IT officer with more than 16 years of running Linux and Windows servers for large organizations. In my experience, the hosting model you pick affects far more than price: it decides who gets woken up when the database fills up, how fast you can deploy a custom module, and whether a failed disk becomes a routine restore or a business-critical incident.

In this guide, I'll walk you through both hosting models, show you how to host Odoo yourself with a complete step-by-step VPS setup (PostgreSQL, Nginx, HTTPS, SMTP relay, and automated off-site backups included), and finish with a clear decision framework and total cost comparison so you can match the right model to your team's skills and budget.

What Is Odoo Hosting and Which Option Should You Pick?

Before the deep dive, it helps to see that "hosting Odoo" actually splits into three layers: the application (Odoo itself), the database (PostgreSQL), and the infrastructure (the server, storage, and network around them). Every hosting model is simply a different answer to one question: who owns each layer?

What Are Your Odoo Hosting Options in 2026?

In practice, businesses choose between two hosting models. With self-hosted Odoo, you install and manage the application on infrastructure you control, such as a virtual private server (VPS), a dedicated server, a cloud virtual machine, or an on-premises machine. With managed Odoo hosting, a provider runs the infrastructure and handles routine maintenance, so your team focuses on using the ERP instead of babysitting it.

On top of those two models, Odoo's official pricing page (odoo.com/pricing) defines three official deployment channels, and it's worth knowing how they map to the self-hosted/managed split:

The three official channels differ mainly in who owns the infrastructure — and who gets the 2 a.m. phone call.

Self-Hosted Odoo: Maximum Control, Maximum Responsibility

Self-hosting Odoo means deploying and managing the application on infrastructure you control. Your organization owns every decision: the operating system, the database configuration, the backup schedule, the firewall rules, and the upgrade calendar. That ownership is exactly why some teams love it — and why others should stay away. Here's the honest breakdown of both sides.

Benefits of Self-Hosting Odoo

When I discuss infrastructure choices with business owners, these are the self-hosting advantages that actually move the needle:

• Complete control over the hosting environment — you decide the OS, PostgreSQL tuning, filesystem layout, and every parameter in between.
• Freedom to choose your provider and region — useful when data residency rules or internal policies require the database to stay in a specific country or datacenter.
• Full support for custom modules and integrations — third-party integrations, custom developments, and server-level tools work without plan restrictions.
• Performance tuning based on your workload — you can add workers, split the database onto its own server, or cache aggressively as your usage grows.
• Direct access to the database — reporting queries, external apps, and migrations are no longer gated behind a plan tier.

Challenges of Self-Hosting Odoo

Along with control comes responsibility. When you self-host Odoo, your team is accountable for:

• Installing software updates and security patches — for Odoo and for the operating system beneath it.
• Managing backups and disaster recovery — and, just as important, periodically testing that restores actually work.
• Monitoring server performance and application availability — disk usage, memory, load, log errors.
• Troubleshooting infrastructure and application issues — when the site is down at 9 a.m. on invoice day, there is no provider ticket queue; it's you.
• Planning capacity and upgrades — including Odoo major-version migrations, which are the most underestimated task on this list.

How to Host Odoo on a VPS: Complete 9-Step Production Setup

If you've decided self-hosting fits your team, here is the complete production deployment path I recommend: a single Ubuntu LTS server running Odoo Community Edition, backed by PostgreSQL, Nginx as a hardened reverse proxy, free Let's Encrypt HTTPS, an external SMTP relay for mission-critical customer emails, and automated daily off-site backups. Plan for at least 2 vCPUs and 4 GB of RAM for a small team, and check the official Odoo documentation for the current stable version number before you start — the commands below use the 19.0 branch as an example.

A note on architecture (Native APT vs Docker Compose): While containerizing Odoo with Docker Compose is increasingly common for complex microservice environments, a native APT installation directly on Ubuntu 24.04 LTS remains the most lightweight and reliable setup for a single-server small business deployment. It consumes less RAM overhead, integrates natively with the operating system's systemd manager, and makes PostgreSQL tuning straightforward.

Step 1: Provision the VPS and Create a Non-Root User

Spin up an Ubuntu 24.04 LTS instance from any reputable provider, then connect and stop using the root account for daily work:

ssh root@YOUR_SERVER_IP
adduser deploy
usermod -aG sudo deploy
# Log out and back in as "deploy" before continuing

A fresh Ubuntu 24.04 LTS instance — the foundation of a self-hosted Odoo deployment.

Step 2: Harden the Server Before Installing Anything

An ERP holds payroll, customer data, and accounting — don't expose a default server to the internet with it on board. Apply updates, install necessary utilities, enable the firewall so only SSH, HTTP, and HTTPS are reachable, and turn on fail2ban to slow down brute-force attempts. For a full walkthrough of the firewall layer, see my comprehensive firewall and network security guide, and for the rest of the post-install routine, this Linux first-steps checklist covers the essentials.

sudo apt update && sudo apt upgrade -y
sudo apt install ufw fail2ban wget gnupg -y
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo systemctl enable --now fail2ban

Step 3: Install PostgreSQL and Create the Database Role

Odoo stores everything — sales, invoices, inventory — in PostgreSQL. To understand why PostgreSQL is the industry standard for complex ERP relational schemas over other relational engines, see our MySQL vs PostgreSQL vs SQLite comparison. Install PostgreSQL, then create a database role matching the default odoo user from the Odoo configuration:

sudo apt install postgresql -y
sudo -u postgres createuser --createdb odoo

Step 4: Install Odoo from the Official Repository

The official nightly repository keeps Odoo updatable through the normal package manager. Add the signing key, point APT at the current stable branch, and install:

wget -O - https://nightly.odoo.com/odoo.key | \
  sudo gpg --dearmor -o /usr/share/keyrings/odoo-archive-keyring.gpg
echo 'deb [signed-by=/usr/share/keyrings/odoo-archive-keyring.gpg] https://nightly.odoo.com/19.0/nightly/deb/ ./' | \
  sudo tee /etc/apt/sources.list.d/odoo.list
sudo apt update && sudo apt install odoo -y

Step 5: Configure Odoo, Workers, and Set a Strong Master Password

Open /etc/odoo/odoo.conf and make four changes I consider non-negotiable on any internet-facing deployment: set a long random database master password (admin_passwd), bind the service strictly to localhost (http_interface = 127.0.0.1), enable proxy_mode = True since requests will arrive through Nginx, and configure your multi-processing worker allocation:

admin_passwd = USE-A-LONG-RANDOM-PHRASE-HERE
http_interface = 127.0.0.1
proxy_mode = True
workers = 2

How to calculate your worker count accurately: Odoo's official formula specifies Workers = (vCPUs * 2) + 1. However, each active worker requires approximately 1 GB to 1.5 GB of RAM. On our starter 2 vCPU / 4 GB RAM server, setting workers = 2 is the sweet spot: it reserves sufficient memory for the operating system, PostgreSQL buffer caches, and the separate WebSocket background process without risking Out-Of-Memory (OOM) crashes. Enable and start the service:

sudo systemctl restart odoo
sudo systemctl enable odoo
sudo systemctl status odoo   # should report "active (running)"

At this point Odoo answers on port 8069 (HTTP) and port 8072 (WebSockets) — but only on localhost, and that's exactly how we want it. The next steps put a hardened front door in front of it.

Step 6: Put Nginx in Front of Odoo as a Reverse Proxy

A reverse proxy gives you a clean domain name, proper WebSocket routing for real-time chat, upload buffer limits, and a natural place to terminate HTTPS. To dive deeper into reverse proxy architectures, see our comprehensive VPN vs proxy architectural guide. Install Nginx and create your site configuration:

Nginx listens on ports 80/443; Odoo stays private on localhost:8069 and localhost:8072.

server {
    listen 80;
    server_name erp.example.com;

    # Allow large document, image, and database uploads
    client_max_body_size 100M;

    proxy_read_timeout 720s;
    proxy_connect_timeout 720s;
    proxy_send_timeout 720s;

    # Real-time WebSocket traffic routed to Odoo gevent port
    location /websocket {
        proxy_pass http://127.0.0.1:8072;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # Standard web HTTP traffic
    location / {
        proxy_pass http://127.0.0.1:8069;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

sudo rm -f /etc/nginx/sites-enabled/default
sudo ln -s /etc/nginx/sites-available/odoo /etc/nginx/sites-enabled/
sudo nginx -t        # configuration test must pass
sudo systemctl reload nginx

Step 7: Enable HTTPS with a Free Let's Encrypt Certificate

Nobody should log into an ERP over plain HTTP. With a DNS record pointing erp.example.com at your server, Certbot upgrades the Nginx site to HTTPS in one command:

sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d erp.example.com
sudo certbot renew --dry-run   # verify automatic renewal works

Step 8: Configure an External SMTP Relay for Quotations and Invoices

An ERP is only half functional if your invoices, password resets, and purchase orders bounce. Here is the single biggest operational surprise for new self-hosters: almost every cloud VPS provider blocks outbound Port 25 by default to prevent spam. Attempting to send emails directly from your server will silently fail or land straight in your customers' spam folders.

External SMTP relays bypass port 25 cloud blocks and protect your company's domain reputation.

Step 9: Automate Daily Off-Site Backups (PostgreSQL + Filestore)

A local backup saved on the same VPS disk is useless if the server hardware fails or the hypervisor gets corrupted. A complete Odoo backup requires two components: the PostgreSQL database dump and the filestore directory (where user attachments, invoice PDFs, and product photos reside, typically at /var/lib/odoo/.local/share/Odoo/filestore/). Create an automated backup script at /usr/local/bin/odoo-backup.sh:

#!/bin/bash
BACKUP_DIR="/var/backups/odoo"
DATE=$(date +"%Y%m%d_%H%M%S")
DB_NAME="YOUR_DATABASE_NAME"

mkdir -p $BACKUP_DIR

# 1. Dump the PostgreSQL database
sudo -u postgres pg_dump -Fc $DB_NAME > "$BACKUP_DIR/db_${DB_NAME}_${DATE}.dump"

# 2. Archive the filestore attachments
tar -czf "$BACKUP_DIR/filestore_${DB_NAME}_${DATE}.tar.gz" -C /var/lib/odoo/.local/share/Odoo/filestore/ $DB_NAME

# 3. Keep only last 7 days of local backups
find $BACKUP_DIR -type f -mtime +7 -delete

# 4. Sync off-server to remote storage (e.g., via rclone to AWS S3, Wasabi, or Backblaze B2)
# rclone sync $BACKUP_DIR remote:your-secure-bucket/odoo-backups/

Make the script executable with sudo chmod +x /usr/local/bin/odoo-backup.sh and schedule it to run every night via root's crontab (0 2 * * * /usr/local/bin/odoo-backup.sh). Test your restore procedure quarterly on a staging instance — a backup you haven't restored from is a wish, not a recovery plan.

Open https://erp.example.com, create your first database with the master password you configured, and you have a hardened, production-ready self-hosted Odoo. Now, let's explore what the managed alternatives offer in comparison.

Managed Odoo Hosting: When to Hand Over the Server Keys

Managed hosting flips the responsibility model. A provider — Odoo itself through Odoo Online or Odoo.sh, or a third-party Odoo hosting specialist — owns the infrastructure and the routine maintenance: uptime, backups, security patching, and often the Odoo version upgrades. You manage users, apps, and business processes; the provider manages everything below that line. Here's what that trade looks like in practice.

Benefits of Managed Odoo Hosting

For teams that treat their ERP purely as a business productivity tool, managed hosting provides substantial advantages:

• No server administration required — deployment is measured in minutes, not days.
• Backups and high availability handled for you — Odoo's official cloud, for example, includes incremental daily backups stored on two continents, per its pricing page.
• Updates and patching are routine, not projects — security fixes land without your team scheduling a maintenance window.
• Predictable, per-user pricing — infrastructure cost scales with headcount instead of surprise hardware or consulting bills.
• Support covers the whole stack — when something breaks, there is a single point of accountability instead of finger-pointing between host and application vendor.

Limitations of Managed Odoo Hosting

However, handing over infrastructure management introduces specific operational boundaries:

• Customization is gated by the plan — Odoo's own FAQ states that custom developments and the external API require the Custom plan, not Standard.
• Little to no database or OS access — deep reporting queries and server-level tools may be off the table.
• Recurring fees grow with users — for large teams, per-user cloud pricing can eventually exceed the cost of well-run self-hosted infrastructure.
• Provider dependency — you inherit the provider's regions, upgrade schedule, and policies; verify export options (Odoo Online, for instance, lets you download a database backup from its control center) before committing.

Self-Hosted vs Managed Odoo Hosting: Side-by-Side Comparison

Now that both models are clear, here's the side-by-side breakdown across every operational factor. Start with the row that matches your biggest constraint — for most teams it's technical expertise or long-term cost profile:

The Real Math: Total Cost of Ownership for a 10-User Team (Annual Estimate)

When business owners evaluate hosting costs, they often compare a $20/month VPS bill against a $250/month SaaS invoice and conclude self-hosting is an automatic no-brainer. In IT management, that is called "ignoring the iceberg below the surface." Here is what a realistic 12-month Total Cost of Ownership (TCO) calculation looks like for a 10-user team:

Key Takeaway: For a small team with standard business processes, Odoo Online is often cheaper or equal in true cost once you account for sysadmin hours. But as your team scales to 30, 50, or 100 users, self-hosting flips into massive savings because your infrastructure cost grows linearly with cheap CPU/RAM rather than compounding on per-seat licenses.

How to Choose the Right Odoo Hosting Option

The comparison table tells you what differs; this section tells you which side you're on. Be honest about the two lists below — most hosting regrets I've seen come from teams picking the list they wished they belonged to, not the one they actually do.

Choose Self-Hosted Odoo If

Self-hosting is your winning strategy under these specific organizational conditions:

• You want full control over the hosting environment, database, and upgrade schedule.
• You need custom modules, third-party integrations, or specific server configurations without plan restrictions.
• Data residency, industry regulation, or internal policy requires infrastructure you physically control.
• You have IT or DevOps resources prepared to handle updates, backups, monitoring, and troubleshooting.
• You're optimizing for long-term cost at a large user count, and you can invest staff time instead of per-user fees.

Choose Managed Odoo Hosting If

Managed cloud hosting is the lower-risk and higher-ROI route when:

• You want to deploy Odoo without managing the underlying infrastructure.
• You don't have dedicated IT or DevOps resources — and you don't plan to hire them.
• You prefer a provider to handle routine maintenance and infrastructure management.
• You want to reduce the operational work involved in maintaining servers.
• You want a low-maintenance solution that lets the team focus entirely on business operations.

There is also a middle path worth mentioning: Odoo.sh gives you custom modules and branch-based development while Odoo still operates the infrastructure — the "customization of self-hosting with the convenience of managed hosting," at Custom-plan pricing. For many growing companies, that hybrid is the honest sweet spot.

Key Factors to Consider Before Choosing

Choosing the right hosting option involves more than comparing features or costs. Weigh these six factors together, not one at a time:

• Budget: consider both initial and ongoing costs. Self-hosting requires infrastructure and maintenance time; managed hosting involves recurring fees in exchange for less infrastructure work.
• Technical expertise: does your team have the skills to install, maintain, secure, and troubleshoot Odoo? Without dedicated IT or DevOps resources, managed hosting is usually the safer bet.
• Customization: if you need custom modules, third-party integrations, or specific server configurations, verify your hosting option supports them. Self-hosting provides the most control.
• Security and compliance: map your security policies, data protection requirements, and industry regulations — then decide explicitly which responsibilities belong to your team and which the provider covers.
• Scalability: pick an environment that supports growth in users, data, and workload, so you aren't forced into a migration during your busiest season.
• Maintenance and support: decide whether your team will manage updates, backups, monitoring, and troubleshooting — or whether you'd rather pay a provider to absorb that load.

5 Odoo Hosting Mistakes I See Again and Again

Whether you self-host or hand over the keys, these are the mistakes that turn a smooth ERP rollout into a painful one. Every one of them is cheap to prevent and expensive to fix:

1. Backups that were never tested. A backup you haven't restored from is a hope, not a plan. A proper Odoo backup includes both the PostgreSQL dump and the filestore directory — and a scheduled restore test at least quarterly.
2. Exposing Odoo or PostgreSQL ports directly. Port 8069 (and 8072 for WebSockets) should listen on localhost only, with Nginx handling public traffic; port 5432 should never be reachable from the internet. This is the single most common misconfiguration on freshly deployed Odoo servers.
3. Leaving the database master password weak or default. The admin_passwd in /etc/odoo/odoo.conf protects database creation and deletion. Anyone who guesses it can take over your entire installation.
4. Running behind a proxy with proxy_mode disabled. Without proxy_mode = True and correct forwarded headers, Odoo generates wrong URLs, breaks redirects, and can silently bypass HTTPS assumptions in its session handling.
5. Treating updates as "later" problems. Both the OS and Odoo need a patch rhythm. Odoo's own pricing FAQ expects on-premise users to stay on the latest stable version — falling several major versions behind turns the eventual upgrade into a risky migration project instead of a routine step.

Frequently Asked Questions

These are the questions I hear most often from teams weighing Odoo hosting options. If yours isn't here, leave it in the comments and I'll add it.

The Right Odoo Hosting Model Is a Team Decision, Not a Tech One

Choosing between self-hosted and managed Odoo hosting ultimately comes down to one honest question: does your team have the skills — and the willingness — to run the infrastructure? Self-hosting rewards you with full control, unlimited customization, and direct database access, but it bills you in responsibility: updates, backups, security, and upgrades are yours. Managed hosting trades some of that control for predictability, letting your team focus on the ERP instead of the server beneath it.

Whichever model you pick, decide deliberately: evaluate your budget, technical expertise, customization needs, security requirements, and growth plans together — and revisit that decision once a year, because the right answer at 10 users is often the wrong one at 100.

Your next step: if you're going self-hosted, block one afternoon and work through the nine setup steps above on a throwaway VPS first — it's the fastest way to learn whether you actually enjoy running the stack. If you'd rather not, start an Odoo Online trial and only move to Odoo.sh or self-hosting when a real customization need appears.