This document outlines the fundamental steps required to set up Odoo in a production environment or on a server exposed to the internet. It complements the installation guide and is generally not necessary for development systems that are not publicly accessible.

Warning: If you are deploying a public server, please thoroughly review our Security recommendations to safeguard your system.

dbfilter

Odoo operates as a multi-tenant system, meaning a single Odoo instance can host and manage multiple database instances. Its highly customizable nature implies that customizations, including the loaded modules, are specific to the "current database."

For logged-in users accessing the web client, this poses no issue; the database can be selected during login, and relevant customizations are subsequently loaded. However, for non-logged-in users (e.g., portal or website visitors) who are not associated with a specific database, Odoo needs a mechanism to determine which database should be used to render a website page or execute an operation. While not a concern if multi-tenancy is not utilized (as there is only one database), a rule becomes essential when multiple databases are accessible.

This is where --db-filter proves invaluable. It defines how the database should be selected based on the requested hostname (domain). The value supplied is a regular expression, which can dynamically incorporate the hostname (%h) or the first subdomain (%d) through which the system is being accessed.

For production servers hosting multiple databases, especially those utilizing the website module, it is imperative to set dbfilter. Failure to do so will result in a number of features malfunctioning.

Configuration Samples

• Show only databases with names beginning with ‘mycompany’

  In your configuration file, set:

  [options]
  dbfilter = ^mycompany.*$

• Show only databases matching the first subdomain after www: For instance, the database “mycompany” will be displayed if the incoming request was directed to www.mycompany.com or mycompany.co.uk, but not for www2.mycompany.com or helpdesk.mycompany.com.

  In your configuration file, set:

  [options]
  dbfilter = ^%d$

Note: Proper configuration of --db-filter is a crucial aspect of securing your deployment. Once it is correctly functioning and uniquely matching a single database per hostname, it is highly recommended to restrict access to the database manager screens. This can be achieved by using the --no-database-list startup parameter, which prevents listing your databases and blocks access to management interfaces. Refer to the security section for further details.

PostgreSQL

By default, PostgreSQL permits connections exclusively over UNIX sockets and loopback connections (from "localhost," the same machine where the PostgreSQL server is installed). This setup is suitable if Odoo and PostgreSQL reside on the same machine, and it is the default when no host is specified. However, if Odoo and PostgreSQL are to operate on different machines, PostgreSQL must be configured to listen to network interfaces. This is often desired to allow multiple Odoo installations to share a single PostgreSQL database or to allocate more computing resources to each software component.

You have a couple of options for configuring network access:

• Accept only loopback connections and establish an SSH tunnel between the Odoo machine and the PostgreSQL machine. Odoo would then be configured to connect to its end of the tunnel.
• Accept connections to the machine where Odoo is installed, potentially over SSL (refer to PostgreSQL connection settings for more information). Odoo would then be configured to connect directly over the network. While technically, a tool like socat can proxy UNIX sockets across networks, it is primarily used for software that can only operate over UNIX sockets.

Configuration Sample

• Allow TCP connection on localhost
• Allow TCP connection from the 192.168.1.x network

In /etc/postgresql/<YOUR POSTGRESQL VERSION>/main/pg_hba.conf, set:

# IPv4 local connections:
host    all             all             127.0.0.1/32            md5
host    all             all             192.168.1.0/24          md5

In /etc/postgresql/<YOUR POSTGRESQL VERSION>/main/postgresql.conf, set:

listen_addresses = 'localhost,192.168.1.2'
port = 5432
max_connections = 80

Configuring Odoo

By default, Odoo connects to a local PostgreSQL instance via a UNIX socket on port 5432. This behavior can be modified using the database options if your PostgreSQL deployment is not local or does not adhere to the default installation settings.

The packaged installers for Odoo will automatically create a new user (odoo) and assign it as the database user.

• The database management screens are secured by the admin_passwd setting. This setting can only be configured via configuration files and is checked before any database modifications are permitted. It should be set to a randomly generated value to prevent unauthorized third parties from using this interface.
• All database operations, including those performed through the database management screen, utilize the database options. For the database management screen to function correctly, the PostgreSQL user must possess `createdb` rights.
• Users are always able to drop databases they own. For the database management screen to be entirely non-functional, the PostgreSQL user needs to be created with no-createdb privileges, and the database must be owned by a different PostgreSQL user.

Warning: The PostgreSQL user must not be a superuser.

Configuration Sample

• Connect to a PostgreSQL server at 192.168.1.2
• Utilize port 5432
• Use an ‘odoo’ user account
• With ‘pwd’ as the password
• Filter only databases with names beginning with ‘mycompany’

In your configuration file, set:

[options]
admin_passwd = mysupersecretpassword
db_host = 192.168.1.2
db_port = 5432
db_user = odoo
db_password = pwd
dbfilter = ^mycompany.*$

SSL Between Odoo and PostgreSQL

Since Odoo 11.0, you can enforce an SSL connection between Odoo and PostgreSQL. In Odoo, the db_sslmode parameter controls the SSL security level for the connection, with values selectable from ‘disable’, ‘allow’, ‘prefer’, ‘require’, ‘verify-ca’, or ‘verify-full’.

For more detailed information, consult the PostgreSQL documentation.

Builtin Server

Odoo incorporates built-in HTTP, cron, and live-chat servers, which can operate using either multi-threading or multi-processing.

The multi-threaded server is a simpler server primarily suited for development, demonstrations, and its compatibility across various operating systems, including Windows. A new thread is initiated for every incoming HTTP request, even for long-lived connections such as websockets. Additional daemonic cron threads are also spawned. However, due to a Python limitation (the Global Interpreter Lock - GIL), it does not optimally utilize hardware resources.

This multi-threaded server is the default for Odoo, including Docker containers. It is activated by either omitting the --workers option or setting it to 0.

The multi-processing server is a robust server primarily intended for production environments. It overcomes the Python GIL limitation on resource usage, thereby making optimal use of the hardware. A pool of workers is established upon server startup. New HTTP requests are queued by the operating system until workers become available to process them. An additional event-driven HTTP worker for the live chat feature is spawned on an alternative port. Extra cron workers are also created. A configurable process reaper monitors resource usage and can terminate or restart failed workers as needed.

The multi-processing server is an opt-in feature, enabled by setting the --workers option to a non-zero integer.

Note: Due to its extensive customization for Linux servers, the multi-processing server is not available on Windows.

Worker Number Calculation

• A common guideline is: (#CPU * 2) + 1
• Dedicated cron workers will consume CPU resources.
• Approximately 1 worker can handle around 6 concurrent users.

Memory Size Calculation

• We estimate that 20% of requests are "heavy" requests, while the remaining 80% are "simpler" ones.
• A heavy worker, assuming well-designed computed fields and optimized SQL queries, is estimated to consume approximately 1GB of RAM.
• A lighter worker, under similar optimal conditions, is estimated to consume around 150MB of RAM.

The required RAM can be calculated as: Needed RAM = #worker * ( (light_worker_ratio * light_worker_ram_estimation) + (heavy_worker_ratio * heavy_worker_ram_estimation) )

LiveChat

In a multi-processing setup, a dedicated LiveChat worker automatically starts and listens on the --gevent-port. By default, HTTP requests will continue to be handled by the normal HTTP workers rather than the LiveChat worker. Therefore, you must deploy a proxy in front of Odoo and redirect incoming requests with paths starting with /websocket/ to the LiveChat worker. Additionally, Odoo must be started in --proxy-mode to ensure it uses the actual client headers (such as hostname, scheme, and IP) instead of those provided by the proxy.

Configuration Sample

• Server with 4 CPUs, 8 Threads
• 60 concurrent users
• 60 users / 6 = 10 (theoretical number of workers needed)
• (4 * 2) + 1 = 9 (theoretical maximum number of workers)
• We will utilize 8 workers + 1 for cron. A monitoring system will be employed to measure CPU load, aiming for it to remain between 7 and 7.5.
• Estimated RAM for Odoo = 9 * ((0.8 * 150) + (0.2 * 1024)) ≈ 3GB RAM

In your configuration file:

[options]
limit_memory_hard = 1677721600
limit_memory_soft = 629145600
limit_request = 8192
limit_time_cpu = 600
limit_time_real = 1200
max_cron_threads = 1
workers = 8

HTTPS

Whether Odoo is accessed via the website, web client, or web service, it transmits authentication information in cleartext. Consequently, a secure Odoo deployment necessitates the use of HTTPS. SSL termination can be implemented using virtually any SSL termination proxy, but it requires the following configuration:

• Enable Odoo’s proxy mode. This setting should only be active when Odoo is operating behind a reverse proxy.
• Set up the SSL termination proxy. A practical guide can be found in the Nginx SSL termination example.
• Configure the proxying itself. Refer to the Nginx proxying example for guidance.
• Your SSL termination proxy should also be configured to automatically redirect non-secure connections to the secure HTTPS port.

While Odoo can be accessible solely over an internal packet-switched network, this would require secured switches, protections against ARP spoofing, and would preclude the use of WiFi. Even within secure packet-switched networks, deploying over HTTPS is recommended, and the costs are lower as "self-signed" certificates are easier to deploy in a controlled environment compared to the internet.

Configuration Sample

• Redirect HTTP requests to HTTPS
• Proxy requests to Odoo

In your configuration file, set the following. And in /etc/nginx/sites-enabled/odoo.conf, set:

#odoo server
upstream odoo {
  server 127.0.0.1:8069;
}
upstream odoochat {
  server 127.0.0.1:8072;
}
map $http_upgrade $connection_upgrade {
  default upgrade;
  ''      close;
}

# http -> https
server {
  listen 80;
  server_name odoo.mycompany.com;
  rewrite ^(.*) https://$host$1 permanent;
}

server {
  listen 443 ssl;
  server_name odoo.mycompany.com;
  proxy_read_timeout 720s;
  proxy_connect_timeout 720s;
  proxy_send_timeout 720s;

  # SSL parameters
  ssl_certificate /etc/ssl/nginx/server.crt;
  ssl_certificate_key /etc/ssl/nginx/server.key;
  ssl_session_timeout 30m;
  ssl_protocols TLSv1.2;
  ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
  ssl_prefer_server_ciphers off;

  # log
  access_log /var/log/nginx/odoo.access.log;
  error_log /var/log/nginx/odoo.error.log;

  # Redirect websocket requests to odoo gevent port
  location /websocket {
    proxy_pass http://odoochat;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_set_header X-Forwarded-Host $http_host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
    proxy_cookie_flags session_id samesite=lax secure;  # requires nginx 1.19.8
  }

  # Redirect requests to odoo backend server
  location / {
    # Add Headers for odoo proxy mode
    proxy_set_header X-Forwarded-Host $http_host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_redirect off;
    proxy_pass http://odoo;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
    proxy_cookie_flags session_id samesite=lax secure;  # requires nginx 1.19.8
  }

  # common gzip
  gzip_types text/css text/scss text/plain text/xml application/xml application/json application/javascript;
  gzip on;
}

HTTPS Hardening

To enhance security, it's recommended to add the Strict-Transport-Security header to all requests. This header prevents browsers from ever sending a plain HTTP request to your domain. Be aware that you will need to consistently maintain a functional HTTPS service with a valid certificate on this domain; otherwise, users may encounter security alerts or be completely unable to access your site.

You can force HTTPS connections for a year for every visitor in NGINX by adding the following line:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

Additional configuration options are available for the session_id cookie. The Secure flag can be included to ensure it is never transmitted over HTTP, and SameSite=Lax can be used to prevent authenticated Cross-Site Request Forgery (CSRF) attacks.

# requires nginx 1.19.8
proxy_cookie_flags session_id samesite=lax secure;

Odoo as a WSGI Application

It is also possible to deploy Odoo as a standard WSGI application. Odoo provides a basic WSGI launcher script named odoo-wsgi.example.py. This script should be customized (potentially after copying it from the setup directory) to correctly configure Odoo by directly setting parameters in odoo.tools.config, rather than relying on command-line arguments or a configuration file.

However, when Odoo is mounted as a WSGI application, the WSGI server will only expose the main HTTP endpoint for the web client, website, and webservice API. Since Odoo no longer directly controls worker creation in this scenario, it cannot automatically set up cron or live-chat workers.

Cron Workers

To ensure cron jobs are processed, it is necessary to start one of Odoo's built-in servers alongside the WSGI server. This additional server must be configured to exclusively handle cron tasks and *not* process HTTP requests. This can be achieved using the --no-http CLI option or by setting http_enable = False in the configuration file.

On Linux-like operating systems, using the multi-processing server over the multi-threading one is recommended for better hardware utilization and increased stability. This involves using the --workers=-1 and --max-cron-threads=n CLI options.

LiveChat

For the Live Chat feature to operate correctly, a gevent-compatible WSGI server is required. This server should be capable of handling numerous simultaneous long-lived connections but does not demand significant processing power. All requests with paths starting with /websocket/ should be directed to this server. A regular (thread/process-based) WSGI server should be used for all other requests.

Alternatively, the Odoo cron server can also be configured to serve Live Chat requests. Simply remove the --no-http CLI option from the cron server configuration. Then, ensure that requests whose paths begin with /websocket/ are directed to this server, either on the --http-port (for a multi-threading server) or on the --gevent-port (for a multi-processing server).

Serving Static Files and Attachments

For convenience during development, Odoo directly serves all static files and attachments embedded within its modules. However, for optimal performance in production, it is generally preferable for static files to be served by a dedicated static HTTP server.

Serving Static Files

Odoo static files are located within each module’s static/ folder. Therefore, static files can be served by intercepting all requests to /_MODULE_/static/_FILE_ and correctly locating the module and file across the various addons paths.

It is good practice, though not strictly necessary (as users cannot modify or inject content into modules’ static/ folders and existing images are final), to set the Content-Security-Policy: default-src 'none' header on all images delivered by the web server.

Using the NGINX (HTTPS) configuration provided earlier, the following map and location blocks should be added to enable NGINX to serve static files:

map $sent_http_content_type $content_type_csp {
    default "";
    ~image/ "default-src 'none'";
}

server {
    # the rest of the configuration

    location @odoo {
        # copy-paste the content of the / location block
    }

    # Serve static files right away
    location ~ ^/[^/]+/static/.+$ {
        # root and try_files both depend on your addons paths
        root ...;
        try_files ... @odoo;
        expires 24h;
        add_header Content-Security-Policy $content_type_csp;
    }
}

The specific root and try_files directives will vary depending on your Odoo installation, particularly your --addons-path.

Example

Suppose Odoo has been installed via Debian packages for both Community and Enterprise versions, and the --addons-path is set to '/usr/lib/python3/dist-packages/odoo/addons'.

In this scenario, the root and try_files directives should be:

root /usr/lib/python3/dist-packages/odoo/addons;
try_files $uri @odoo;

Serving Attachments

Attachments are files stored in the filestore whose access is managed and regulated by Odoo. They cannot be directly accessed through a static web server because retrieving them requires multiple database lookups to determine their storage location and verify the current user's access rights.

Nevertheless, once Odoo has successfully located the file and confirmed the access rights, it is advantageous to delegate the serving of the file to the static web server rather than Odoo itself. To enable Odoo to offload file serving to the static web server, the X-Sendfile (Apache) or X-Accel (Nginx) extensions must be enabled and properly configured on the static web server. Once configured, start Odoo with the --x-sendfile CLI flag (this single flag applies to both X-Sendfile and X-Accel).

Note:

• The X-Sendfile extension for Apache (and compatible web servers) typically does not require any additional configuration.
• The X-Accel extension for NGINX, however, does require the following additional configuration:

location /web/filestore {
    internal;
    alias /path/to/odoo/data-dir/filestore;
}

If you are unsure of the path to your filestore, start Odoo with the --x-sendfile option and navigate directly to the /web/filestore URL via Odoo (do not access the URL through NGINX). This action will log a warning message that includes the necessary configuration information.

Security

It is crucial to remember that securing an information system is an ongoing process, not a one-time task. At any given moment, your system's security is only as strong as its weakest link.

Therefore, please do not consider this section an exhaustive list of measures that will prevent all security issues. It is intended merely as a summary of the initial, vital steps you should incorporate into your security action plan. Further security enhancements will stem from best practices for your operating system and distribution, as well as robust user, password, and access control management strategies.

When deploying an internet-facing server, please carefully consider the following security-related topics:

• Always establish a robust super-admin password and restrict access to the database management pages as soon as the system is initially set up. For more details, refer to the Database Manager Security section.
• Select unique login credentials and strong passwords for all administrator accounts across all databases. Avoid using 'admin' as a login. These administrator accounts should be reserved for controlling and managing the installation and not used for daily operations. Never use any default passwords, such as admin/admin, even for test or staging databases.
• Do not install demo data on internet-facing servers. Databases with demo data often contain default logins and passwords that could be exploited to compromise your systems and cause significant problems, even on staging or development environments.
• Implement appropriate database filters (--db-filter) to limit the visibility of your databases based on the hostname. See the dbfilter section for more information. You can also use -d to provide your own comma-separated list of available databases to filter from, instead of allowing the system to fetch all of them from the database backend.
• Once your db_name and dbfilter are configured to match only a single database per hostname, you should set the list_db configuration option to False. This action completely prevents the listing of databases and blocks access to the database management screens (this is also exposed as the --no-database-list command-line option).
• Ensure that the PostgreSQL user (--db_user) is not a super-user, and that your databases are owned by a different user. For instance, they could be owned by the `postgres` super-user if you are using a dedicated non-privileged db_user. Refer to the Configuring Odoo section for additional details.
• Keep your installations updated by regularly applying the latest builds, either through GitHub or by downloading the newest versions from https://www.odoo.com/page/download or http://nightly.odoo.com/.
• Configure your server in multi-process mode with appropriate limits that align with your typical usage patterns (memory, CPU, timeouts). See the Builtin server section for more information.
• Run Odoo behind a web server that provides HTTPS termination with a valid SSL certificate. This measure is essential to prevent eavesdropping on cleartext communications. SSL certificates are readily available and many free options exist. Configure the web proxy to limit the size of requests, set suitable timeouts, and then enable the proxy mode option. Refer to the HTTPS section for further guidance.
• If remote SSH access to your servers is necessary, ensure that a strong password is set for all accounts, not just `root`. It is strongly recommended to completely disable password-based authentication and permit only public key authentication. Additionally, consider restricting access via a VPN, allowing only trusted IP addresses in your firewall, and/or deploying a brute-force detection system such as `fail2ban` or an equivalent solution.
• Consider implementing appropriate rate-limiting on your proxy or firewall to mitigate brute-force attacks and denial-of-service (DoS) attacks. See Blocking Brute Force Attacks for specific preventative measures. Many network providers offer automatic mitigation for Distributed Denial of Service (DDoS) attacks, but this is often an optional service, so it's advisable to consult with them.
• Whenever feasible, host your public-facing demo, test, or staging instances on machines separate from your production environments. Apply the same rigorous security precautions to these non-production instances as you would to your production systems.
• If your public-facing Odoo server has access to sensitive internal network resources or services (eperhaps via a private VLAN), implement robust firewall rules to protect those internal resources. This will ensure that the Odoo server cannot be accidentally or maliciously used to access or disrupt internal systems. Typically, this can be achieved by applying an outbound default DENY rule on the firewall, and then explicitly authorizing access only to the internal resources that the Odoo server genuinely requires. Systemd IP traffic access control can also be beneficial for implementing per-process network access control.
• If your public-facing Odoo server operates behind a Web Application Firewall (WAF), a load-balancer, a transparent DDoS protection service (such as CloudFlare), or a similar network-level device, you may wish to prevent direct access to the Odoo system. It is generally challenging to keep the endpoint IP addresses of your Odoo servers secret, as they can appear in web server logs when querying public systems or in the headers of emails sent from Odoo. In such scenarios, you might configure your firewall so that the Odoo endpoints are not publicly accessible except from the specific IP addresses of your WAF, load-balancer, or proxy service. Service providers like CloudFlare typically maintain a public list of their IP address ranges for this purpose.
• If you are hosting multiple customers, ensure that customer data and files are isolated from each other by utilizing containers or appropriate "jail" techniques.
• Establish daily backups of your databases and filestore data, and then copy them to a remote archiving server that is not directly accessible from the Odoo server itself.
• Deploying Odoo on Linux is strongly recommended over Windows. Should you choose to deploy on a Windows platform, a thorough security hardening review of the server should be conducted, which falls outside the scope of this guide.

Blocking Brute Force Attacks

For internet-facing deployments, brute force attacks targeting user passwords are a prevalent threat that should not be overlooked for Odoo servers. Odoo generates a log entry for every login attempt, indicating whether it was successful or failed, along with the target login and the source IP address.

Log entries will typically appear in the following format:

Failed login:

2018-07-05 14:56:31,506 24849 INFO db_name odoo.addons.base.res.res_users: Login failed for db:db_name login:admin from 127.0.0.1

Successful login:

2018-07-05 14:56:31,506 24849 INFO db_name odoo.addons.base.res.res_users: Login successful for db:db_name login:admin from 127.0.0.1

These logs can be efficiently analyzed by an intrusion prevention system like fail2ban.

For example, the following fail2ban filter definition should effectively match a failed login attempt:

[Definition]
failregex = ^ \d+ INFO \S+ \S+ Login failed for db:\S+ login:\S+ from <HOST>
ignoreregex =

This filter could then be used with a jail definition to block the attacking IP address on HTTP(S).

Here’s an example of how it might look to block an IP for 15 minutes if 10 failed login attempts are detected from the same IP within a 1-minute window:

[odoo-login]
enabled = true
port = http,https
bantime = 900  ; 15 min ban
maxretry = 10  ; if 10 attempts
findtime = 60  ; within 1 min  /!\ Should be adjusted with the TZ offset
logpath = /var/log/odoo.log  ;  set the actual odoo log path here

Database Manager Security

The Configuring Odoo section briefly mentioned admin_passwd. This setting is crucial as it secures all database management screens, which are used to create, delete, dump, or restore databases.

If the management screens should not be accessible at all, you must set the list_db configuration option to False. This will completely block access to all database selection and management interfaces.

Warning: It is strongly recommended to disable the Database Manager for any internet-facing system! It is designed as a development/demo tool to facilitate quick creation and management of databases. It is not intended for production use and may expose dangerous features to potential attackers. Furthermore, it is not optimized to handle large databases and could trigger memory limits.

On production systems, database management operations should always be performed by the system administrator, including the provisioning of new databases and automated backups.

Ensure you set an appropriate db_name parameter (and optionally, dbfilter) so that the system can determine the target database for each request. Otherwise, users will be blocked as they will not be permitted to choose the database themselves.

If the database management screens must only be accessible from a specific set of machines, utilize your proxy server's features to block access to all routes beginning with /web/database, with the possible exception of /web/database/selector, which displays the database selection screen.

If the database management screen needs to remain accessible, the admin_passwd setting must be changed from its default value of admin. This password is checked before any database alteration operations are permitted. It should be stored securely and ideally generated randomly, for example, using a Python command:

$ python3 -c 'import base64, os; print(base64.b64encode(os.urandom(24)))'

This command generates a 32-character pseudorandom printable string.

Reset the Master Password

There may be situations where the master password is misplaced or compromised, necessitating a reset. The following process is designed for system administrators of an Odoo on-premise database, detailing how to manually reset and re-encrypt the master password.

When an on-premise database is initially created, a random master password is generated. Odoo strongly advises using this password to secure the database. This password is implemented by default, ensuring a secure master password for any new Odoo on-premise deployment.

Warning: When an Odoo on-premise database is first installed, it is accessible to anyone on the internet until this master password is set to secure it.

The master password is specified in the Odoo configuration file (odoo.conf or the hidden file odoorc). This password is required to modify, create, or delete a database via the graphical user interface (GUI).

Locate Configuration File

First, open the Odoo configuration file (odoo.conf or the hidden file odoorc). The configuration file is typically located at: c:\ProgramFiles\Odoo{VERSION}\server\odoo.conf.

Change Old Password

Once the appropriate file has been opened, proceed to modify the existing password in the configuration file to a temporary password.

After locating the configuration file, open it using a graphical user interface (GUI) text editor. This can usually be accomplished by simply double-clicking the file, which should open it with your device's default GUI application.

Next, modify the master password line from admin_passwd = $pbkdf2-sha… to, for example, admin_passwd = newpassword1234. This temporary password can be any value, as long as it is saved. Ensure that all characters after the = sign are modified.

Example

The line might initially appear like this:

admin_passwd = $pbkdf2-sh39dji295.59mptrfW.9z6HkA$w9j9AMVmKAP17OosCqDxDv2hjsvzlLpF8Rra8I7p/b573hji540mk/.3ek0lg%kvkol6k983mkf/40fjki79m

The modified line should then appear like this:

admin_passwd = newpassword1234

Important: It is crucial to change the password to something else, rather than merely commenting out the line (e.g., by adding a semicolon ; at the beginning). This ensures the database remains secure throughout the entire password reset process.

Restart Odoo Server

After setting the temporary password, a restart of the Odoo server is mandatory.

To restart the Odoo server on Windows, first, type services into the Windows Search bar. Then, select the Services application and scroll down to locate the Odoo service. Next, right-click on the Odoo service and choose either "Start" or "Restart." This action will manually restart the Odoo server.

Use Web Interface to Re-encrypt Password

First, navigate to /web/database/manager or http://server_ip:port/web/database/manager in your web browser.

Note: Remember to replace server_ip with the actual IP address of your database server and port with the numeric port from which the database is accessible.

Next, click the "Set Master Password" button. Enter the previously selected temporary password into the "Master Password" field. Following this, type your desired new master password into the "New Master Password" field. Once the "Continue" button is clicked, the new master password will be hashed (or encrypted).

At this point, the password has been successfully reset, and a hashed version of your new password will now be visible in the configuration file.

For additional information on Odoo database security, please refer to this documentation: Database Manager Security.

Supported Browsers

Odoo officially supports the latest versions of the following web browsers:

• Google Chrome
• Mozilla Firefox
• Microsoft Edge
• Apple Safari