DOLI_DB_HOST_PORT environment variable ignored: conf.php always generated with port 3306 regardless of custom port setting

[ccrica]

Environment

• Image: dolibarr/dolibarr:23.0.2
• Database type: PostgreSQL (DOLI_DB_TYPE=pgsql)
• Custom DB port: <custom_port> (non-standard, not 3306 nor 5432)
• Host: Synology NAS, Docker via Portainer

Description

When using a non-standard database port with PostgreSQL - which is actually common practice in Docker environments where multiple containers share the same host and default ports (3306, 5432) - the DOLI_DB_HOST_PORT environment variable set in docker-compose (Stacks in Portainer) is not reflected in the generated conf.php.
The file is always generated with port 3306 (MariaDB default), regardless of what is declared in the stack.

This issue has two distinct impacts, the second being critical in production.

Steps to reproduce

1. Deploy the official dolibarr/dolibarr:23.0.2 image with the following environment:

   DOLI_DB_TYPE: pgsql
   DOLI_DB_HOST: 192.168.x.x
   DOLI_DB_HOST_PORT: <custom_port>
   DOLI_DB_NAME: dolidb
   DOLI_DB_USER: dolidbu
   DOLI_DB_PASSWORD: xxxxxx

2. Start the container (first run, no install.lock present)
3. Check the generated conf.php:

   docker exec -it <container> cat /var/www/html/conf/conf.php

Expected behavior

$dolibarr_main_db_port should be set to <custom_port> in conf.php.

Actual behavior

$dolibarr_main_db_port='3306'; is always written into conf.php by docker-run.sh, making Dolibarr unable to connect to the database.

Impact

1. At initial installation (minor)

docker-run.sh generates conf.php with the wrong port, but the install wizard allows the user to correct it manually before completing setup. The issue can go unnoticed at this stage, as the user naturally replaces 3306 with the correct port during the wizard flow.

2. After a redeploy (critical)

When redeploying the container - for example to apply a stack environment change, upgrade the image, or restart after maintenance - conf.php is regenerated with port 3306, silently breaking the database connection.

No error is reported in initdb.log: the log file remains completely empty, giving no indication whatsoever that the configured port was not applied. The application fails silently, which makes this regression hard to detect and potentially dangerous in production.

This second scenario is the most severe: the deployment appears successful, the container starts normally, Apache responds, but Dolibarr cannot reach the database - with no trace in either the container logs (docker/Portainer) or initdb.log, the only log files checked during this investigation.

Additional notes

• DOLI_DB_PORT (documented in some forks) is not recognized at all by docker-run.sh
  • only DOLI_DB_HOST_PORT is used internally, yet neither correctly propagates
    a non-standard port into conf.php.
• The same stack configuration worked correctly with a previous version (v22).
• Current workaround: manually patch conf.php after each container start:

  sed -i "s/\$dolibarr_main_db_port='3306'/\$dolibarr_main_db_port='<custom_port>'/" \
    /var/www/html/conf/conf.php

Additional notes

• The issue persists whether or not install.lock is present prior to redeployment.
• Important context: the official documentation states that when using DOLI_DB_TYPE=pgsql, Dolibarr must be installed manually on first execution, and install.lock must be created manually afterwards. This flow was followed in our setup. The port issue described in this report occurs regardless of compliance with this procedure.
• DOLI_DB_HOST_PORT is the only officially documented variable for the database port in this image (default value: 3306). However, using a non-standard port is standard practice in any multi-container Docker environment, regardless of the database engine - since default ports (3306 for MariaDB/MySQL, 5432 for PostgreSQL) are typically already in use or remapped on the host. This issue therefore potentially can potentially affects any user running Dolibarr in Docker with a non-default database port, not only PostgreSQL users.
• No error is reported in either the container logs (docker/Portainer) or initdb.log - the only log files checked during this investigation. initdb.log remains completely empty, giving no indication that the configured port was not applied.
• The same stack configuration worked correctly with a previous version (v22).
• Current workaround: manually patch conf.php after each container start:

  sed -i "s/\$dolibarr_main_db_port='3306'/\$dolibarr_main_db_port='<custom_port>'/" \
    /var/www/html/conf/conf.php

PS : Bug identified and investigated and documented by myself. Write-up drafted with the assistance of Claude (Anthropic) for clarity and technical accuracy.

[erjo-cocoba]

Hello,

You don't need to change postgreSQL default port.
You just have map a different host to postgreSQL default port

i.e:
volumes: - postgres-data:/var/lib/postgresql ports: - 6432:5432

IMAGE --> PORTS
postgres:17-alpine --> 0.0.0.0:6433->5432/tcp, [::]:6433->5432/tcp
postgres:latest --> 0.0.0.0:5433->5432/tcp, [::]:5433->5432/tcp
postgres:latest --> 5432/tcp

[ccrica]

You don't need to change postgreSQL default port.
You just have map a different host to postgreSQL default port

Hi,
thanks for the suggestion. However, the core issue here is not about which port is used - it is that DOLI_DB_HOST_PORT, whatever value is set in the stack, does not appear to be reliably applied: conf.php ends up with 3306 after a redeploy, regardless of what is declared in the environment. Remapping the host port would not prevent this behavior.
Also worth noting: in most Docker environments, exposed ports rarely match the application's default — that is precisely the point of port mapping.