Skip to content
Guides

Hardening an Odoo server: a security checklist

An Odoo server holds your customers, invoices and stock, and it sits on the public internet. This checklist covers the server, the network, PostgreSQL and Odoo itself, for Odoo Community and Enterprise, in the order we would do it.

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_mode on.
  • Database manager off: each instance has list_db set 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.

Keep reading

PostgreSQL tuning for Odoo

PostgreSQL tuning for Odoo beyond memory: SSD and checkpoint settings, connection limits, finding slow queries, indexes and keeping autovacuum ahead of bloat.

Run Odoo on your own cloud

Deploy, back up and monitor Odoo on AWS, Google Cloud, Azure, Hetzner or any server. 14-day free trial.