Odoo Hosting & Infrastructure

DigitalOcean for Hosting Odoo ERP — What to Know Before You Deploy

DigitalOcean is a reliable VPS option for Odoo ERP hosting, but the right configuration matters: Droplet sizing, database tuning, SSL termination, automated backups, and firewall rules are the difference between a stable production system and a server that struggles under real workload. This guide covers what you need to know before you deploy Odoo on DigitalOcean.

iWesabe Editorial TeamMay 4, 201910 min read

DigitalOcean is one of the most widely used VPS platforms for self-managed Odoo ERP deployments. Its straightforward pricing, reliable infrastructure, and extensive documentation make it a solid choice for businesses that want to run Odoo Community Edition without a third-party hosting cost, or for Odoo Enterprise customers who prefer a self-managed environment over Odoo.sh. But 'run Odoo on DigitalOcean' is not a single configuration — Droplet size, operating system choice, PostgreSQL tuning, network setup, and backup strategy all affect whether your deployment stays stable under real business workload or becomes a maintenance burden.

Droplet Sizing: How Much CPU and RAM Does Odoo Actually Need?

Recommended DigitalOcean Droplet sizes for Odoo ERP by concurrent user count
Concurrent usersRecommended DropletvCPUs / RAMNotes
1–10 (dev / demo / micro SME)Basic — Regular Intel or AMD2 vCPU / 4 GB RAMSufficient for Odoo Community development, demos, or very small businesses with light daily use. Not recommended for payroll runs, inventory operations, or any job queue tasks under concurrent use. SSD: 80 GB minimum.
10–30 (SME production)General Purpose — Premium AMD4 vCPU / 8 GB RAMGood baseline for a Bahrain or KSA SME with 15–30 concurrent users across Accounting, HR, Inventory, and Sales. Run PostgreSQL on the same Droplet with careful shared_buffers tuning. SSD: 100–160 GB.
30–75 (mid-market production)General Purpose — Premium Intel or AMD8 vCPU / 16 GB RAMHandles multi-module operations (Accounting + Inventory + Manufacturing + HR + Sales) with concurrent users and background job queue workers. Consider a separate managed PostgreSQL Droplet at this scale. SSD: 200–400 GB depending on attachment volume.
75–150+ (larger deployments)CPU-Optimised or Memory-Optimised16+ vCPU / 32+ GB RAMAt this scale, a single-server architecture becomes a bottleneck. Separate the Odoo application server from the PostgreSQL database server. Consider load balancing across multiple Odoo app nodes with a shared file system (Spaces / NFS) for attachments. Managed PostgreSQL with connection pooling (pgBouncer) is strongly recommended.

PostgreSQL Configuration for Odoo on DigitalOcean

PostgreSQL is Odoo's only supported database. The default PostgreSQL configuration that ships with Ubuntu or Debian on a DigitalOcean Droplet is tuned for a generic small server — not for a multi-user ERP workload. The three settings that matter most for Odoo are shared_buffers, work_mem, and max_connections. A rough starting point for a 4 vCPU / 8 GB Droplet running Odoo + PostgreSQL on the same machine: set shared_buffers to 2 GB (25% of total RAM), work_mem to 64 MB, and max_connections to 100–200. Odoo's connection limit is controlled by the --db-maxconn parameter in the Odoo configuration file — set this below max_connections to leave headroom for administrative connections.

Key PostgreSQL configuration parameters for Odoo ERP on a shared Droplet
ParameterDefaultRecommended (4 vCPU / 8 GB)What it does
shared_buffers128 MB2 GBAmount of memory PostgreSQL uses for caching data pages. The single most impactful setting for Odoo read performance. Set to 25% of total RAM.
work_mem4 MB64 MBMemory allocated per sort or hash operation. Odoo generates complex queries with joins across many tables. Low work_mem causes disk-based sorts which are slow. Caution: this is per-operation, not per-session — multiply by max concurrent operations before increasing.
effective_cache_size4 GB6 GB (on 8 GB Droplet)Hint to the query planner about how much memory is available for caching (includes OS page cache, not just shared_buffers). Set to 75% of total RAM. Does not allocate memory — it is advisory only.
max_connections100150Maximum simultaneous database connections. Each Odoo worker maintains a pool of connections. For a 4-worker Odoo with --db-maxconn 64, keep max_connections above 100 to leave room for direct psql and monitoring connections.
checkpoint_completion_target0.90.9 (leave as default)Controls how much of the checkpoint interval PostgreSQL uses for writing dirty pages. The default 0.9 is good for Odoo — no change needed.

Firewall, SSL, and Security Configuration

Essential security configuration for a self-managed Odoo deployment on DigitalOcean
Security layerWhat to configureWhy it matters for Odoo
DigitalOcean Cloud FirewallInbound: allow 22 (SSH — restricted to your IP), 80 (HTTP), 443 (HTTPS). Block 5432 (PostgreSQL) from public internet. Block 8069 (Odoo direct port) from public — only Nginx should be public-facing.PostgreSQL exposed to the internet is a critical vulnerability — it is the most common attack vector on self-hosted Odoo. Never allow 5432 from 0.0.0.0/0. Odoo's built-in 8069 port should not be public — run Nginx as a reverse proxy.
Nginx reverse proxy with SSLInstall Nginx. Use Certbot (Let's Encrypt) for a free SSL certificate. Configure Nginx to proxy_pass to http://localhost:8069. Set proxy_read_timeout to 720s for Odoo long-polling. Add the recommended Odoo Nginx proxy headers (X-Forwarded-For, X-Real-IP, HOST).SSL is required for Odoo's session security, POS barcode scanner support, and browser security warnings. Without the correct proxy headers, Odoo reports wrong URLs in emails and PDF reports, and the session cookie security flag does not work correctly.
Odoo configuration file hardeningSet admin_passwd to a strong random password (not 'admin'). Set db_filter to restrict which database names are served. Disable the Odoo database manager interface (list_db = False) in production. Set logfile to a persistent path outside /tmp.The Odoo database manager at /web/database/manager is publicly accessible by default and allows anyone to create, drop, or restore databases if admin_passwd is weak. In production, set list_db = False and use a strong admin_passwd.
Automated backupsUse DigitalOcean Droplet Backups (weekly automated snapshot, 20% of Droplet cost). For more frequent backups, use DigitalOcean Spaces (object storage) with a cron job that runs pg_dump daily and uploads to Spaces. Keep 7-day rolling retention minimum.Odoo's database contains all transactional data — invoices, payroll records, inventory movements. A server failure without a recent backup means permanent data loss. Droplet Backups are a weekly snapshot — not sufficient for a production ERP. Daily pg_dump to Spaces provides point-in-time recovery.

DigitalOcean vs Odoo.sh — When to Use Each

Comparing self-managed DigitalOcean hosting vs. Odoo.sh for different business profiles
FactorDigitalOcean self-managedOdoo.sh (official Odoo cloud)
Monthly cost (20-user Odoo Enterprise)~$50–100/month (Droplet only). Odoo Enterprise licence is separate.~$192–360/month (includes 1 production + 1 staging + 1 dev instance, automated backups, deployment pipeline). Odoo Enterprise licence included for some plans.
Maintenance overheadHigh. You manage OS updates, PostgreSQL upgrades, Odoo version upgrades, SSL certificate renewal, backups, monitoring, and incident response.Low. Odoo SA manages infrastructure. You focus on Odoo configuration and customisation. SSL, backups, monitoring, and PostgreSQL are managed.
Custom module deploymentFull control. Deploy any module from any source. No code review gate.GitHub-integrated. Modules deployed via git push to the Odoo.sh repository. Custom modules go through a basic build validation.
Staging and development environmentsManual. You provision and manage additional Droplets for staging.Included. Odoo.sh provides separate staging and development branches that rebuild automatically on git push.
Best forTeams with dedicated Linux/DevOps resource. Odoo Community Edition deployments. Businesses with strict data residency requirements that Odoo.sh data centres do not meet. Cost-sensitive micro SME with technical staff.SME and mid-market using Odoo Enterprise who want focus on the ERP, not server management. Teams without a dedicated sysadmin. Businesses that need the production/staging/dev pipeline built in.
14+
Years deploying and supporting Odoo ERP across self-managed and cloud environments
200+
Odoo implementations across KSA, Bahrain, and UAE including self-hosted deployments
3
Odoo awards: Best Partner MENA 2023, Highest Revenue KSA 2022/2023, Top Revenue Achiever KSA 2023/2024
100%
Go-live delivery rate across all Gulf Odoo implementations

Need Help Choosing Between Self-Managed Hosting and Odoo.sh?

iWesabe deploys Odoo on both self-managed VPS environments and Odoo.sh depending on the client's technical resource, data residency requirements, and budget. We recommend the right hosting architecture at the start of every implementation — not after go-live when problems surface.

WhatsApp

Frequently Asked Questions

What is the minimum server spec to run Odoo ERP in production?
For a production Odoo deployment with 5–15 concurrent users, the minimum practical specification is 4 vCPUs and 8 GB RAM with a 100 GB SSD. Running Odoo on 2 vCPUs / 4 GB is possible for development or demo environments, but under real production workload — simultaneous payroll runs, inventory moves, and accounting operations — a 4 GB server will exhaust RAM and become unstable. On DigitalOcean, the General Purpose Premium AMD Droplet at 4 vCPU / 8 GB is the entry-level production configuration.
Should I run PostgreSQL on the same Droplet as Odoo or on a separate server?
For small to mid-sized deployments (up to 40–50 concurrent users), running PostgreSQL on the same Droplet as Odoo is acceptable if the Droplet is sized correctly (8 GB+ RAM). The advantage is lower cost and simpler administration. At 50+ concurrent users or with high-volume operations (batch invoicing, large imports, manufacturing job orders), separating the database to a dedicated PostgreSQL Droplet or using DigitalOcean Managed PostgreSQL improves stability. Managed PostgreSQL adds automated backups, failover, and connection pooling (pgBouncer) at a cost premium — worthwhile for businesses where Odoo downtime has a direct financial impact.
How do I set up automated backups for Odoo on DigitalOcean?
The most reliable backup strategy for Odoo on DigitalOcean combines two layers: enable DigitalOcean Droplet Backups (weekly automated Droplet snapshot, 20% of Droplet cost) as a base-level disaster recovery option; and add a daily pg_dump cron job that exports the Odoo PostgreSQL database to a .dump file and uploads it to DigitalOcean Spaces (object storage). A complete backup script runs pg_dump, compresses the output with gzip, uploads to a Spaces bucket with a date-stamped filename, and deletes files older than 14 days. The Odoo filestore (attachments, stored at /var/lib/odoo or ~/odoo-server/data) must also be backed up separately — pg_dump only covers the database, not the filestore.
How many Odoo worker processes should I configure for my Droplet?
Odoo's recommended formula for worker count is: (number of vCPUs × 2) + 1. For a 4 vCPU Droplet, that is 9 workers — but this is a maximum, not a target. On an 8 GB Droplet where PostgreSQL is co-located, running 4–6 workers is more conservative and leaves enough RAM for both Odoo and PostgreSQL. Each worker consumes 200–400 MB RAM under load. Also configure 2 cron workers (--max-cron-threads 2) separately from the HTTP worker count. Monitor actual RAM usage with `htop` or `free -h` after go-live and adjust worker count downward if the server is memory-pressured.
Is DigitalOcean suitable for Odoo in Gulf countries — Bahrain, Saudi Arabia, UAE?
DigitalOcean has data centres in the Netherlands (AMS3), Germany (FRA1), the United Kingdom (LON1), Singapore (SGP1), and New York/San Francisco (US regions) — but no data centre in the GCC as of 2024. For Gulf businesses, this means your Odoo data will be hosted outside the region, which may conflict with data residency requirements under Bahrain PDPL, Saudi PDPL, or UAE PDPL for personal data. For businesses where data residency is required (HR data, payroll records, customer personal data), consider AWS Bahrain (me-south-1), AWS UAE (me-central-1), or Odoo.sh (Google Cloud — nearest is Belgium, not GCC). For businesses where data residency is not a compliance requirement, DigitalOcean FRA1 or AMS3 provides good latency to Gulf users (100–150ms) and is a legitimate production hosting choice.
What is the difference between Odoo Community and Odoo Enterprise for hosting purposes?
For hosting purposes, both Odoo Community and Odoo Enterprise run on the same infrastructure stack (Python, PostgreSQL, Nginx). The key differences are: Odoo Community is open-source and free — there is no licence fee, and you are free to host it anywhere including DigitalOcean; Odoo Enterprise requires a licence subscription from Odoo SA and includes additional modules (Accounting, HR, Payroll, Manufacturing, eSign, and others) not in Community; Odoo Enterprise can be self-hosted on DigitalOcean (the licence is per-user, not per-server), or hosted on Odoo.sh; Odoo Enterprise hosted on Odoo.sh includes the platform cost in the subscription. For Gulf businesses, Odoo Enterprise is almost always the right choice because it includes the accounting, payroll, and localisation modules needed for NBR/ZATCA VAT, GOSI/SIO, and WPS compliance — these modules are not available in Community.
iWesabe Editorial Team

iWesabe Editorial Team

Practitioner insights on Odoo ERP, ZATCA compliance, and Saudi enterprise digital operations — written by iWesabe's consulting, finance, and engineering teams.

About iWesabe

Related Articles