-
Notifications
You must be signed in to change notification settings - Fork 0
Env file reference
The keys recognised in the configuration file passed with
--config <FILE>. Unknown keys produce a warning and are ignored — that is not an error.
The file is read line by line as KEY=VALUE: comments (#) and blank lines are ignored, and quotes
around the value are stripped. No code execution: a value like $(rm -rf /) stays a literal
string and is never run. That is the key difference from the old Bash version, which sourced the
file — a code-execution vector running as root.
| Key | CLI equivalent | Default |
|---|---|---|
ODOO_VERSION |
--version |
18.0 |
ODOO_INSTANCE |
--instance |
absent → the historical, unnamed instance |
ODOO_USER |
--odoo-user |
odoo, or odoo-<instance>
|
DB_USER |
--db-user |
= ODOO_USER
|
DB_PASSWORD |
--db-password |
empty → peer auth |
ODOO_PORT |
--port |
8069 |
ODOO_GEVENT_PORT |
--gevent-port |
ODOO_PORT + 3 (so 8072) |
DB_NAME |
--db-name |
odoo, or odoo-<instance>
|
ODOO_INSTALL_DIR |
--install-dir |
/opt/odoo/odoo<N>, or /opt/odoo/odoo-<instance>
|
ODOO_ADMIN_PASSWD |
--admin-passwd |
admin (discouraged) |
ODOO_LOGFILE |
--logfile |
absent → journal/stdout |
WITH_NGINX |
--with-nginx |
false |
NGINX_SERVER_NAME |
--server-name |
_ |
NGINX_OPEN_HTTPS_PORT |
--open-https-port |
false |
NGINX_ENABLE_SSL |
(legacy name of the previous key) | false |
ODOO_HOME is the constant /opt/odoo: if present in the file it is ignored, with a warning.
A .env for a named instance should name as little as possible. ODOO_USER, DB_USER,
DB_NAME and ODOO_INSTALL_DIR are derived from ODOO_INSTANCE, and in the cascade an explicit
value beats a derived one — so a file that spells them out gives a second instance the first one's
user, role and database, silently and without complaint. Name the instance and the port, and let the
rest follow:
# cliente-x.env
ODOO_VERSION=18
ODOO_INSTANCE=cliente-x
ODOO_PORT=8169 # ODOO_GEVENT_PORT follows at 8172
ODOO_ADMIN_PASSWD=a-strong-passwordThe same trap has its own guard in the test suite, on the configuration the CI uses for exactly this scenario.
Boolean values (WITH_NGINX, NGINX_OPEN_HTTPS_PORT): true/1/yes/on mean true.
NGINX_ENABLE_SSL is the name the key was born with, and it keeps working: it lives in .env
files already handed out, and breaking those over a naming question would do more damage than the name
does. The new name says what it actually does — it opens 443 on the firewall, it does not configure
TLS.
# production.env
ODOO_VERSION=18
ODOO_USER=odoo
DB_NAME=odoo
ODOO_PORT=8069
WITH_NGINX=true
NGINX_SERVER_NAME=odoo.example.com
# NGINX_OPEN_HTTPS_PORT=true # opens 443; for TLS run `certbot --nginx` afterwards
# ODOO_ADMIN_PASSWD=a-strong-password # do NOT use 'admin' in productionsudo invok --config production.envA CLI value takes precedence over the one in the .env. See CLI reference and
Non-interactive use and CI.
Protecting secrets: lock down the
.envfile if it containsODOO_ADMIN_PASSWD/DB_PASSWORD. The password goes into the final config file (0640 odoo:odoo) and is never logged.
Start here
Key concepts
References
For developers
Technical detail — how it works inside
Steps:
- 1.1 PrepareOptRoot
- 1.2 CreateOdooUser
- 1.3 SetupLogDir
- 1.3b SetupCacheDir
- 1.4 AptPackages (delta)
- 1.5 InstallWkhtmltopdf
- 1.6 SetupPostgres
- 1.7 CreateDbRole
- 1.8 CreateDatabase
- 1.9 CloneOdooRepo
- 1.10 CreateVirtualenv
- 1.11 InstallPythonRequirements
- 1.12 GenerateConfig
- 1.12b SetupDataDir
- 1.13 InitializeOdooDatabase
- 1.14 SetupSystemd
- 1.15 Nginx (6 sub-steps)
- 1.16 WriteControlScript + PatchBashrc
Cross-cutting: