WordPress on Nginx.
A production image, free to pull.

Docker Compose walkthrough

The recipe directory ships a docker-compose.yml that runs the full stack: the WordPress on Nginx container, a MariaDB database, and a Redis cache. A trimmed version looks like this:

name: wordpress-nginx

services:
  db:
    image: mariadb:11
    restart: unless-stopped
    environment:
      MARIADB_DATABASE: wordpress
      MARIADB_USER: wordpress
      MARIADB_PASSWORD: ${DB_PASSWORD:-change-me-db}
      MARIADB_ROOT_PASSWORD: ${DB_ROOT_PASSWORD:-change-me-root}
    volumes: [db-data:/var/lib/mysql]
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      interval: 10s
      timeout: 5s
      retries: 12

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: ["redis-server", "--requirepass", "${REDIS_PASSWORD:-change-me-redis}", "--save", "60", "1"]
    volumes: [redis-data:/data]

  wordpress:
    image: ghcr.io/remarkablecloud/wordpress-nginx:7.1-r1
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
    ports: ["${HTTP_PORT:-8081}:80"]
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_NAME: wordpress
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: ${DB_PASSWORD:-change-me-db}
      REDIS_HOST: redis
      REDIS_PORT: "6379"
      REDIS_PASSWORD: ${REDIS_PASSWORD:-change-me-redis}
      WP_ADMIN_USER: ${WP_ADMIN_USER:-admin}
      WP_ADMIN_PASSWORD: ${WP_ADMIN_PASSWORD:-}
      WP_ADMIN_EMAIL: ${WP_ADMIN_EMAIL:-admin@example.com}
      WP_SITE_TITLE: ${WP_SITE_TITLE:-WordPress}
    volumes:
      - wp-content:/var/www/html/wp-content

volumes:
  db-data:
  redis-data:
  wp-content:

Start it with generated secrets:

REDIS_PASSWORD=$(openssl rand -hex 16) DB_PASSWORD=$(openssl rand -hex 16) \
WP_ADMIN_PASSWORD=$(openssl rand -hex 12) docker compose up -d

Then browse http://localhost:8081. The WordPress container stays unhealthy until provisioning is finished, which takes a little longer than the web server coming up, so wait for healthy before you send traffic. If you leave WP_ADMIN_PASSWORD unset, the provisioner generates one and prints it once to the container log.

In production you place a TLS-terminating reverse proxy (such as Traefik) in front of the WordPress service. The proxy handles certificates and forwards X-Forwarded-Proto and X-Forwarded-Host, which the image uses to set the canonical site URL.

Environment variable reference

The database and Redis variables are wired automatically by the RemarkableCloud App Platform from the managed MariaDB and Redis. They are listed here for standalone runs. The WP_* first-run variables are optional and used only when the site is first installed.

Variable	Required	Default	Description
WORDPRESS_DB_HOST	Yes	127.0.0.1	Database host, as host or host:port; port defaults to 3306.
WORDPRESS_DB_NAME	Yes	wordpress	Database name.
WORDPRESS_DB_USER	Yes	wordpress	Database user.
WORDPRESS_DB_PASSWORD	Yes	(empty)	Database password.
REDIS_HOST	No	(unset)	Redis host; when set, the Redis object cache is enabled.
REDIS_PORT	No	6379	Redis port.
REDIS_PASSWORD	No	(unset)	Redis password; written as WP_REDIS_PASSWORD when present.
WP_ADMIN_USER	No	admin	Admin username, created on first install only.
WP_ADMIN_PASSWORD	No	(generated)	Admin password; generated and printed to the log once if unset.
WP_ADMIN_EMAIL	No	admin@example.com	Admin email, used on first install only.
WP_SITE_TITLE	No	WordPress	Site title, used on first install only.

Ports and volumes:

• Port: the container listens on 80 (plain HTTP). Map or proxy it as needed.
• Volume: /var/www/html/wp-content holds uploads, plugins, and themes and should be persisted.
• Health path: /rc-health.txt returns a static ok and is used by the container healthcheck.

Hardening notes

• No version disclosure. Nginx sends no version banner (server_tokens off) and PHP has expose_php off. Error display is off while error logging stays on.
• Sensitive files blocked. Direct requests to wp-config.php and xmlrpc.php are denied, dotfiles are denied except /.well-known, and PHP execution is denied inside uploads, files, and wp-content, so an uploaded script cannot be run.
• Locked-down WordPress. The dashboard file editor is disabled (DISALLOW_FILE_EDIT), core auto-updates are limited to minor releases, and WP_ENVIRONMENT_TYPE is set to production.
• Correct client IP. Nginx trusts the private-range proxy for X-Forwarded-For, so rate limits and logs use the real visitor address.
• Non-root workers. Nginx and php-fpm workers run as www-data rather than root.

Backups

Two things need backing up: the database and the wp-content volume.

# Database dump
docker compose exec db \
  sh -c 'mariadb-dump -u root -p"$MARIADB_ROOT_PASSWORD" wordpress' > wordpress-db.sql

# wp-content archive
docker run --rm -v wordpress-nginx_wp-content:/data -v "$PWD":/backup alpine \
  tar czf /backup/wp-content.tgz -C /data .

Restore by importing the SQL dump into the db service and extracting the archive back into the wp-content volume. Take backups on a schedule and keep copies off the host.

Upgrades

• WordPress core, themes, and plugins. Update these from the WordPress dashboard or with wp-cli, for example docker compose exec wordpress wp core update --allow-root. These changes live in the database and the wp-content volume, so they persist across container restarts.
• The image itself. Pull a newer tag and recreate the container: docker compose pull wordpress && docker compose up -d wordpress. Because core and the baked plugins live in the image while your content lives in the volume, replacing the image updates the web stack and the baseline plugins without touching your uploads and installed extensions. Review the CHANGELOG.md before upgrading, and take a backup first.
• Pin by digest in regulated environments so a rebuild of the same tag cannot change what you run.