FPM image & WORDPRESS_DB env ?

[lejeczek]

Hi guys.

Should FPM image make use of WORDPRESS_DB_ env vars?
Reason I ask is - I use those as I do with regular images & a difference is that upon first start Wordpress asks me to supply DB bits, to fill the input fields - regular image, with the same vars, does not do that.
I see FPM container says that WORDPRESS_DB_ were provided at container creation.
What I might be missing?
thanks, L.

[tianon]

See https://github.com/docker-library/wordpress/blob/5ec12a3ef21493a12f3d211e0d69d0c6a30a9794/wp-config-docker.php for the custom configuration we apply when our environment variables are specified (which can then skip the wizard).

[RyanAccuWebCloud]

Hey @lejeczek ,

Good question! This can be confusing, but it is related to how the official wordpress:fpm image works.

The WORDPRESS_DB_* environment variables are used to create the wp-config.php file. However, they do not complete the WordPress installation automatically.

Here is what might be happening and a few things you can try.

1. Why do you see the installation screen?

Both the standard wordpress image and the wordpress:fpm image use similar steps to create the configuration file.

When you set the WORDPRESS_DB_* variables, the entrypoint uses them to create wp-config.php.

However, WordPress still needs to create the database tables and the admin account. The FPM image only runs PHP-FPM and needs a separate web server, such as Nginx, to handle HTTP requests.

If the database is empty, WordPress may show the installation screen because the required tables do not exist yet. Having the correct database settings does not mean WordPress is already installed.

2. Check the database connection

First, make sure the FPM container can connect to your database.

For example, if you use Docker Compose, WORDPRESS_DB_HOST should normally be the database service name, such as mysql or db, instead of localhost.

Check the container logs for any database connection errors. This is a good first step before trying other solutions.

3. Use WP-CLI to complete the installation

You can use the wordpress:cli image to run the WordPress installation command. For example:

wp core install \
  --url="your-site.com" \
  --title="Your Blog" \
  --admin_user="admin" \
  --admin_password="your-password" \
  --admin_email="you@example.com"

Make sure the WP-CLI container can access the same WordPress files and database. Run this command only once the database is ready and the WordPress files are available.

This command creates the required database tables and admin account.

4. Check your volume settings

If you mount a volume to /var/www/html, check that the WordPress files are present and that the permissions are correct.

You can also try starting the container without a custom volume to see if the problem is related to the mounted files.

5. Check the configuration file

Make sure wp-config.php exists and contains the correct database settings. Also, check that the file can be read by the PHP process.

If the file was not created correctly, WordPress may not use the expected database settings.

My suggestion

I would first check the database connection and confirm whether the database already contains WordPress tables. If the database is empty, you may need to complete the installation using WP-CLI or the WordPress installer.

The important thing to remember is that setting the database environment variables is not the same as completing the WordPress installation.

Hope this helps!

Regards,
Ryan P.

[tianon]

When you set the WORDPRESS_DB_* variables, the entrypoint uses them to create wp-config.php.

Just to clarify, while this used to be true, it's no longer accurate -- we don't embed credentials or settings directly in that file at all (the wizard does, but our custom version of that config file reads the environment variables direclty at runtime instead, as noted/linked in my reply above).

[RyanAccuWebCloud]

Thanks @tianon , that clarification is super helpful, so the env vars are definitely being read at runtime, not baked into the config file. That means L.'s setup is actually connecting to the DB fine; the wizard is just appearing because the database is empty (no WordPress tables yet).

The FPM image intentionally doesn't run the installer for you, so the cleanest fix is to use the wordpress:cli image to run wp core install against the same volume and env vars. Here's a quick compose snippet you can add as a one-off service:

yaml
wordpress-cli:
image: wordpress:cli
depends_on:
- db
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: youruser
WORDPRESS_DB_PASSWORD: yourpass
WORDPRESS_DB_NAME: wordpress
volumes:
- wordpress_data:/var/www/html
command: >
sh -c "sleep 10 && wp core install
--url='https://your-site.com'
--title='Your Site'
--admin_user='admin'
--admin_password='strongpassword'
--admin_email='you@example.com'"

Just run docker compose run --rm wordpress-cli once, and the tables will be created. After that, the wizard should disappear.

If you'd rather not use CLI, the alternative is to just fill in the wizard manually once—since wp-config.php already has the right values from your env vars, it should complete without issues. But the CLI route is more repeatable if you're scripting deployments.

Also worth double-checking: make sure WORDPRESS_DB_HOST uses the Compose service name (e.g., db) and not localhost, and that the MySQL container has finished initializing before WordPress tries to connect. A healthcheck on the DB side can help with race conditions on first boot .

Regards,
Ryan P.