Most Odoo deployment guides show you how to install the software. This guide covers everything else: security hardening, backup strategy, monitoring, and post-deploy verification. The stuff that separates a “it works on my machine” setup from a production system your business can depend on.
Work through each section in order. Skip nothing. Every item on this list exists because we've seen what happens when it's missing.
Before You Deploy: Pre-Flight Checks
Get these decisions right before you touch a server. Changing them after deployment means starting over.
Server sizing
Match CPU, RAM, and disk to your expected user count and module complexity. Undersized servers cause slow response times and worker starvation under load.
Use the server calculator →Cloud provider selection
Pick a provider with a data center close to your users. Hetzner and OVH for Europe, DigitalOcean and Vultr for global coverage, AWS for compliance-heavy environments.
Compare VPS providers for Odoo →Odoo version decision
Odoo 18 LTS for stability and broad module support. Odoo 19 if you want the latest features. Odoo 17 LTS only if a critical module has not been ported yet. Do not mix versions across modules.
Module inventory
List every module you plan to install: Community base, OCA additions, and custom modules. Test all of them together in a staging environment before production. Incompatible modules are the number one cause of failed go-lives.
Server Setup Checklist
Start with a clean Ubuntu 22.04 or 24.04 LTS server. These are the foundation steps that every production Odoo server needs.
OS updated to latest packages
Run apt update && apt upgrade (Ubuntu/Debian) or dnf update (RHEL/Fedora). Stale packages have known vulnerabilities.
PostgreSQL 14+ installed
Odoo 17+ requires PostgreSQL 12 minimum, but 14+ gives you better performance and parallel query support. PostgreSQL 16 is recommended for new deployments.
Python 3.10+ installed
Odoo 17/18/19 require Python 3.10+. Use the system Python or pyenv. Avoid mixing Python versions on the same server.
wkhtmltopdf 0.12.6+ installed
Required for PDF report generation (invoices, sales orders, delivery slips). The version matters because older versions produce broken layouts. Install from the official wkhtmltopdf releases, not the distro package.
Dedicated Odoo system user created
Run Odoo under its own non-root user (e.g., 'odoo'). Never run Odoo as root. The user should own the Odoo source directory and filestore.
Firewall configured (ufw or iptables)
Allow only ports 22 (SSH), 80 (HTTP), and 443 (HTTPS). Block port 8069 from external access. Nginx should proxy to Odoo, not expose it directly.
fail2ban installed and active
Protects against brute-force SSH and login attempts. Configure jails for sshd at minimum. Add an Odoo jail if you expose the login page directly.
Odoo Configuration Checklist
The default odoo.conf is built for development, not production. These settings prevent the most common production failures.
Admin password changed from default
The admin_passwd in odoo.conf controls access to the database manager. Change it to a strong, unique password immediately. This is not the Odoo user password; it is the master password for creating and dropping databases.
Database manager disabled
Set list_db = False in odoo.conf. The database manager lets anyone create or drop databases if they know the admin password. In production, there's no reason to expose it.
Workers configured correctly
Formula: workers = (CPU cores x 2) + 1. A 4-core server should run 9 workers. Too few workers and requests queue up. Too many and you run out of memory. Each worker uses 150-300MB RAM.
Memory limits set
Set limit_memory_soft = 2147483648 (2GB) and limit_memory_hard = 2684354560 (2.5GB). Workers that exceed the soft limit get recycled after the current request. Workers that hit the hard limit are killed immediately.
proxy_mode = True
Required when running behind Nginx or any reverse proxy. Without this, Odoo cannot read the real client IP from X-Forwarded-For headers, which breaks rate limiting, geolocation, and access logs.
list_db = False
Prevents the database selector from appearing on the login page. Users go directly to your database. Also prevents information leakage about what databases exist on the server.
Longpolling port configured
Set longpolling_port = 8072 and configure Nginx to proxy /longpolling to this port. Without this, live chat, real-time notifications, and discuss channels won't work.
Security Checklist
A public-facing Odoo instance gets scanned by bots within hours of going live. These items aren't optional.
SSL/TLS certificate installed (Let's Encrypt)
Every production Odoo instance needs HTTPS. Use Certbot with auto-renewal. There is no excuse for HTTP in 2026. Browsers flag it as insecure and search engines penalize it.
Security headers configured in Nginx
Add X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, Strict-Transport-Security (HSTS), and Content-Security-Policy. These prevent clickjacking, MIME sniffing, protocol downgrade attacks, and other common exploits.
Database access restricted to localhost
In pg_hba.conf, make sure PostgreSQL only accepts connections from 127.0.0.1 (or Unix socket). Never expose PostgreSQL port 5432 to the network. If you need remote database access, route it through an SSH tunnel.
SSH key-only authentication enabled
Disable password authentication in sshd_config (PasswordAuthentication no). Use SSH keys exclusively. This eliminates brute-force SSH attacks entirely.
Automatic security updates enabled
Configure unattended-upgrades (Ubuntu/Debian) or dnf-automatic (RHEL/Fedora) for security patches. Kernel and OpenSSL vulnerabilities get patched weekly, and your server should apply them automatically.
Odoo admin password is not 'admin'
The first thing attackers try on any Odoo instance is admin/admin. Change the default admin user password before going live. You should also consider renaming the admin user login.
Backup Checklist
Backups are the difference between a bad day and a catastrophe. Your Odoo data includes two parts: the PostgreSQL database and the filestore. You need both to do a complete restore.
Database backup automated (pg_dump)
Schedule pg_dump --format=custom to run daily at minimum. Custom format compresses well and supports selective restore. Store the output with a timestamp in the filename.
Filestore backup automated
The filestore directory (~/.local/share/Odoo/filestore/) contains attachments, images, and binary data that's not in PostgreSQL. Back it up alongside the database or your restores will have missing files.
Off-site backup storage configured
Keep backup copies outside your server: S3, R2, Backblaze B2, or another cloud storage bucket. If the server disk fails, local backups are gone too. Use rclone or s3cmd for automated transfers.
Backup restoration tested
A backup you have never restored is a backup you do not have. Test a full restore to a separate environment at least once before go-live, then quarterly after that. Time the restore so you know your recovery window.
Retention policy defined
Keep 7 daily backups, 4 weekly backups, and 3 monthly backups. Delete older backups automatically. Without a retention policy, storage costs grow unbounded and finding the right backup becomes a needle-in-a-haystack problem.
Monitoring Checklist
Without monitoring, your users discover problems before you do. Good monitoring catches issues early and gives you the data to diagnose them when they happen.
Server metrics tracked (CPU, RAM, disk)
Monitor these continuously. CPU above 80% sustained means workers are maxed. RAM above 90% risks OOM kills. Disk above 85% means you are running out of space for the filestore and database.
Odoo worker status monitored
Check how many workers are busy versus idle. If all workers are consistently busy, requests start queuing and response times spike. Either add workers or optimize slow endpoints.
PostgreSQL connections tracked
Compare active connections to max_connections. Running out of database connections means Odoo stops serving requests immediately. Alert at 80% of max.
Response time measured
Track p95 response time, not averages. Averages hide tail latency problems. If your p95 exceeds 3 seconds, users are noticing it.
Error logs aggregated
Centralize Odoo and Nginx error logs. Watch for HTTP 500 rate, Python tracebacks, and PostgreSQL connection errors. A spike in errors usually precedes a full outage.
Uptime monitoring configured
An external service (UptimeRobot, Better Stack, or similar) should ping your Odoo URL every 60 seconds. You need to know about downtime before your users tell you.
Post-Deploy Checklist
The server is configured and Odoo is running. These final steps make sure the system is actually usable by your team.
DNS configured and propagated
Point your domain (A record or CNAME) to the server IP. Verify propagation with dig or nslookup. DNS changes can technically take up to 48 hours, but usually propagate within an hour.
Email delivery working (SMTP)
Configure outgoing SMTP in Odoo settings. Send a test email to verify delivery. Check SPF, DKIM, and DMARC records for your domain. Without them, emails land in spam folders.
Cron jobs running
Verify that scheduled actions are executing in Odoo (Settings > Technical > Automation > Scheduled Actions). Check that email sending, currency rate updates, and stock synchronization are running on schedule.
User access configured
Create all user accounts, assign security groups, and verify permissions. Test access for each role (admin, manager, regular user). Remove or deactivate the default demo data if present.
Staging environment ready
Clone your production setup to a staging server. Every future update, module installation, or configuration change gets tested in staging first. Do not experiment on production.
Go-live communication sent
Notify your team about the new system URL, their login credentials, and who to contact for support. Include a brief getting-started guide for first-time Odoo users.
What OEC.sh Automates
That's a lot of manual work. Every checklist section above represents hours of SSH sessions, config file editing, and cron script writing. OEC.sh is a deployment platform that automates all of it, on your own cloud account, your own servers, and with your own data.
| Checklist Section | Manual Effort | With OEC.sh |
|---|---|---|
| Server Setup | 1-3 hours of SSH, apt, and config editing | Automated in 2 minutes. Server provisioned on your cloud account with OS hardened, PostgreSQL installed, and firewall configured. |
| Odoo Configuration | 30-60 minutes editing odoo.conf and tuning workers | Auto-configured based on server resources. Workers, memory limits, and proxy mode set correctly from the start. |
| Security | 1-2 hours for SSL, headers, SSH hardening | SSL via Let's Encrypt with auto-renewal, security headers pre-configured, SSH keys set up during provisioning. |
| Backups | 1-2 hours writing cron scripts and configuring storage | Daily automated backups to your own cloud storage (S3/R2). One-click restore. Retention policy built in. |
| Monitoring | 2-4 hours setting up Prometheus, Grafana, or similar | Built-in dashboards for CPU, RAM, disk, workers, and PostgreSQL. Alerts via email and webhook. |
| Post-Deploy | 30-60 minutes for DNS, email, and verification | DNS guidance in dashboard, email configuration wizard, and staging clone with one click. |
OEC.sh isn't a hosting provider. You keep full ownership of your cloud accounts, servers, and data. The platform handles the DevOps so you can focus on running your business.
Frequently Asked Questions
How long does it take to deploy Odoo to production?
A manual deployment following this checklist takes 4-8 hours for an experienced sysadmin, including server hardening, PostgreSQL tuning, and monitoring setup. With OEC.sh, the entire process takes under 5 minutes because the platform automates every step in this checklist.
What server size do I need for production Odoo?
For most small-to-medium businesses (1-50 users), a server with 4 vCPUs, 8GB RAM, and 80GB SSD is a solid starting point. Odoo is CPU- and RAM-intensive, so prioritize those over disk space. Use OEC.sh's server calculator for a recommendation based on your user count and module list.
Should I use Odoo 17, 18, or 19 for a new production deployment?
For new deployments in 2026, Odoo 18 LTS is the safest choice: long-term support, stable codebase, and wide module compatibility. Odoo 19 has more features but a smaller ecosystem. Odoo 17 LTS is still supported but missing two years of improvements.
Do I need a separate staging environment?
Yes. Never test updates, module installations, or configuration changes directly on production. A staging environment should mirror your production setup: same Odoo version, same modules, same PostgreSQL version. Test every change in staging first.
What does OEC.sh automate in the production deployment process?
OEC.sh automates every step in this checklist: server provisioning, OS hardening, PostgreSQL installation and tuning, Odoo installation, worker configuration, SSL/TLS setup, firewall rules, automated backups, monitoring, and DNS configuration. Connect your own cloud account and deploy production Odoo in under 5 minutes.
Deploy Production Odoo in 5 Minutes
Skip the 4-8 hours of manual setup. Connect your cloud account, pick your Odoo version, and deploy. Every item on this checklist, handled automatically. Free plan available.