atws/docker-wordpress repository overview

⁠WordPress Docker Container

Lightweight WordPress container with & based on Alpine Linux 3.23

WordPress version currently installed: 7.1.2

• Used in production for my own sites, making it stable, tested and up-to-date
• PHP-FPM pool sized automatically from the container's memory limit, so the same image is safe from a 700Mi container up to 8Gi
• Best to be used with Amazon Cloudfront as SSL terminator and CDN
• Built on the lightweight Alpine Linux distribution
• Can safely be updated without losing data
• Fully configurable because wp-config.php uses the environment variables you can pass as a argument to the container

⁠Usage

See docker-compose.yml⁠ how to use it in your own environment.

docker-compose up

Or

docker run -d -p 80:80 -v <volumename>:/var/www/html/wp-content \
-e "DB_HOST=db" \
-e "DB_NAME=wordpress" \
-e "DB_USER=wp" \
-e "DB_PASSWORD=secret" \
-e "TABLE_PREFIX=only_if_not_wp_" \
-e "FS_METHOD=direct" \
-e "DISABLE_AUTO_CHOWN=true" \
-e "DISABLE_AUTO_DB_UPDATE=true" \
atws/docker-wordpress:latest

⁠PHP-FPM tuning

pm.max_children is derived at startup from the container's own memory limit (the cgroup limit Kubernetes/Docker enforces), because a single static value cannot be right for both a 700Mi and an 8Gi container. The computed value is logged on every boot:

php-fpm sizing: pm=dynamic pm.max_children=7 spares=2..5 (container memory limit 700MB - 192MB reserved, / 64MB per worker)

Roughly (container_limit_MB - reserved) / per_worker, clamped to 2..64, where per_worker defaults to half of PHP_MEMORY_LIMIT. Measured across live pods, a steady-state worker holds 25-45MB of unreclaimable memory against a 128M limit - opcache and the binaries are shared, and are counted in the reserve rather than per worker - so half the limit is a realistic budget with headroom.

Because the two are linked, raising PHP_MEMORY_LIMIT buys fewer workers rather than the same number of hungrier ones:

pm.max_children is only the ceiling for bursts. The idle pool stays at 2-5 workers whatever the limit, because every idle worker keeps the heap of its last request: deriving the spares from max_children held 15-30 idle workers on 4Gi sites, which pushed pods past their memory request and got them evicted under node memory pressure.

If no container memory limit is set at all, the pool falls back to 16 workers and logs a warning - set resources.limits.memory so it can be sized properly.

Everything is overridable per container:

Prefer these over mounting a .user.ini into the docroot. .user.ini is PHP_INI_PERDIR, so it overrides both php.ini and PHP_MEMORY_LIMIT — a site that mounts one silently defeats the setting above and hides the real per-worker cost from the sizing, which is how sites end up OOM-killed.

If a site queues requests rather than crashing, raise the container's memory limit; the pool resizes itself on the next restart.

⁠WP-CLI

This image includes wp-cli⁠ which can be used like this:

docker exec <your container name> /usr/local/bin/wp --path=/var/www/html <your command>

⁠Inspired by

• https://hub.docker.com/_/wordpress/⁠
• https://codeable.io/wordpress-developers-intro-to-docker-part-two/⁠
• https://github.com/TrafeX/docker-php-nginx/⁠
• https://github.com/etopian/alpine-php-wordpress/⁠
• https://github.com/Trafex/docker-wordpress/⁠
• https://github.com/raulr/nginx-wordpress-docker/⁠
• and Kris!