Key takeaways
- Expose only HTTP and HTTPS to the world. Odoo and PostgreSQL should never be reachable directly.
-
Turn off the database manager with
list_db = False, and set a long, random master password anyway. - Use SSH keys, block brute-force attempts and install security updates automatically.
- Turn on two-factor authentication for Odoo users, and keep tested backups away from the server.
Why Odoo server hardening matters
A new server on a public IP address starts receiving login attempts and scans within minutes. Most are automated, and most look for easy wins: a password login over SSH, an open database port, an exposed admin page or software that has not been patched. Hardening means removing those easy wins, so the server is not worth an attacker's time.
None of the steps below is difficult. The risk is forgetting one, so treat this as a checklist and go through it for every new server.
Server and SSH hardening
Use SSH keys, not passwords
Log in with SSH keys and turn off password authentication in the SSH configuration. A strong key cannot be guessed, so brute-force attempts stop being a risk. Give each person their own key, and remove it when they leave.
Block brute-force attempts
A tool such as fail2ban watches the logs and temporarily blocks addresses that fail to log in again and again. It reduces noise in the logs and slows down anyone trying their luck.
Install security updates automatically
On Ubuntu and Debian, unattended-upgrades installs security patches on its own. Limit it to security updates, so a routine package change does not surprise you, and plan a reboot from time to time for kernel updates.
Keep separate users
Run Odoo as its own unprivileged system user, never as root. If you host several Odoo instances on one server, give each one its own user, so a problem in one cannot read the others' files.
Network: what to expose
A production Odoo server needs only three ports open to the internet:
- 80, for HTTP, redirecting to HTTPS and for certificate checks;
- 443, for HTTPS;
- 22, for SSH, ideally limited to known addresses.
Everything else should be closed. Use your cloud provider's firewall or security groups, a host firewall, or both. In particular:
- Odoo's own ports (8069 and the websocket port) should listen on localhost only, with Nginx in front.
- PostgreSQL's port 5432 should never be open to the internet. If the database runs on another server, use a private network.
Put HTTPS in front of everything, with modern TLS and automatic certificate renewal. Our guide to Odoo HTTPS setup with your own domain covers the details.
Odoo configuration hardening
Turn off the database manager
Odoo's database manager, under /web/database, can create, copy, back up
and delete whole databases. On a production server, nobody should reach it from the
internet. Odoo's documentation recommends setting a dbfilter so each
hostname sees only its database, and then setting list_db = False, which
blocks the database selection and management screens.
Set a strong master password
The master password (admin_passwd) protects those database operations.
Odoo's documentation says it should be a randomly generated value. Set one even if the
database manager is off, and store it in your password manager.
No demo data on production
Demo data comes with known logins and fake records. Odoo's documentation advises against installing it on internet-facing servers.
Turn on proxy mode, and set limits
Behind Nginx, set proxy_mode = True so Odoo logs the real visitor
address. Keep the worker limits (limit_time_cpu,
limit_time_real, limit_memory_hard) in place, so one heavy
request cannot take the whole server down.
PostgreSQL security for Odoo
- Use a dedicated database role for Odoo that is not a superuser. Odoo's documentation recommends this, so a flaw in Odoo cannot take over the whole PostgreSQL server.
- Listen locally, or on a private network address, never on a public one.
- Keep passwords out of version control. The database password lives in the Odoo configuration file, so restrict who can read it.
For performance settings, see our article on PostgreSQL tuning for Odoo.
Odoo user accounts and two-factor authentication
- Change the admin login. Don't keep "admin" as both username and password, and give each person their own account.
- Turn on two-factor authentication. Odoo has built-in two-factor authentication with an authenticator app. In Odoo 19, an administrator can enforce it for employees or all users from the Settings app, according to Odoo's two-factor authentication documentation.
- Review access rights regularly, and archive users who have left.
- Treat API keys like passwords. Give integrations their own users with only the rights they need.
Modules, updates and backups
- Install modules from sources you trust. A module runs with full access to your database. Read the code of anything unfamiliar, and prefer maintained OCA or well-known vendor modules.
- Keep Odoo updated within your version, and plan major upgrades before your version stops receiving fixes.
- Keep backups off the server. If the server is compromised, a backup on the same disk may be lost too. Store copies elsewhere and test restores. Our Odoo backup strategy guide covers how.
The full list of Odoo's own recommendations is in the security section of its system configuration documentation.
Odoo security in CloudPilot
Servers CloudPilot creates, and instances it deploys, start with most of this checklist done:
- Locked-down SSH: password logins are turned off and fail2ban is installed from the first boot.
- Automatic security updates with unattended-upgrades, limited to security patches.
-
Odoo behind Nginx: Odoo listens on localhost only, with HTTPS, HSTS
and
proxy_modeon. -
Database manager off: each instance has
list_dbset to false, a database filter for its own database and a master password set in its configuration. - Separate users per instance: each instance runs as its own system user with its own PostgreSQL role, which is not a superuser and cannot create databases.
- No open agent ports: the CloudPilot agent connects out, so the control plane needs no inbound access, and cloud tokens, SSH keys and backup credentials are stored encrypted.
A few items stay with you: two-factor authentication and access rights inside Odoo, the modules you install, and limiting SSH to known addresses in your cloud firewall. See managed Odoo hosting for what CloudPilot looks after, and pricing for each plan.
Odoo server hardening questions
How do I disable the Odoo database manager?
Set a dbfilter so each hostname sees only its own database, then set list_db = False in the Odoo configuration file and restart Odoo. This blocks the database selection and management screens.
Which ports should be open on an Odoo server?
Only 80 and 443 for the web, and 22 for SSH, ideally limited to known addresses. Odoo's own ports should listen on localhost behind a reverse proxy, and PostgreSQL's port should never be open to the internet.
Does Odoo support two-factor authentication?
Yes. Users can enable two-factor authentication with an authenticator app from their preferences, and in Odoo 19 an administrator can enforce it for employees or all users in the Settings app.