What are we building?

A production-ready WordPress installation with WordPress 7.1.0 (PHP 8.5) and MariaDB 11.8 behind Traefik. The database runs in an isolated internal network with no internet access, WordPress gets its HTTPS from Traefik, and we cleanly solve the classic reverse-proxy pitfall (redirect loop / mixed content). By the end you have a running blog – and you know how to keep it secure.

Prerequisites

• A server with Traefik running and Docker Compose
• A domain pointing at the server – YOUR_DOMAIN below
• A bit more RAM than simple services need – WordPress + database + PHP run comfortably from the VPS 2000 up

Step by step

Step 1: Two containers, two networks

WordPress consists of two parts: the PHP application and a MariaDB database. A clean setup separates the two and isolates the database – it should only be reachable by WordPress and needs no internet itself. That’s exactly what the two networks are for (see Understanding Docker networks): the public proxy network between WordPress and Traefik, and an internal network between WordPress and the database.

mkdir -p /opt/wordpress && cd /opt/wordpress

Step 2: The Compose file

Replace YOUR_DOMAIN and all passwords with your own values:

services:
  db:
    image: mariadb:11.8
    restart: unless-stopped
    environment:
      MARIADB_DATABASE: wordpress
      MARIADB_USER: wordpress
      MARIADB_PASSWORD: YOUR_DB_PASSWORD
      MARIADB_RANDOM_ROOT_PASSWORD: "1"
    volumes:
      - db_data:/var/lib/mysql
    networks: [intern]
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      start_period: 10s
      start_interval: 2s
      interval: 30s
      timeout: 5s
      retries: 5

  wordpress:
    image: wordpress:7.1.0-php8.5-apache
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: YOUR_DB_PASSWORD
      WORDPRESS_DB_NAME: wordpress
      WORDPRESS_CONFIG_EXTRA: |
        if (isset($$_SERVER['HTTP_X_FORWARDED_PROTO']) && $$_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') { $$_SERVER['HTTPS'] = 'on'; }
        define('WP_HOME', 'https://YOUR_DOMAIN');
        define('WP_SITEURL', 'https://YOUR_DOMAIN');
    volumes:
      - wp_data:/var/www/html
    networks: [proxy, intern]
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.wp.rule=Host(`YOUR_DOMAIN`)"
      - "traefik.http.routers.wp.entrypoints=websecure"
      - "traefik.http.routers.wp.tls.certresolver=le"
      - "traefik.http.services.wp.loadbalancer.server.port=80"

volumes:
  db_data: {}
  wp_data: {}
networks:
  proxy:
    external: true
  intern:
    internal: true

Three details are crucial here:

• depends_on: condition: service_healthy – WordPress only starts once the database reports ready via the health check. Without it the first start fails in a race condition.
• intern is internal: true – the database is only on this network and therefore has no internet access; WordPress reaches it at the hostname db.
• WORDPRESS_CONFIG_EXTRA – the most important part (next step).

Step 3: Start

docker compose up -d

Docker starts the database first, waits for its health check and then starts WordPress. Check:

docker compose ps

NAME                    IMAGE                           SERVICE     STATUS
wordpress-db-1          mariadb:11.8                    db          Up (healthy)
wordpress-wordpress-1   wordpress:7.1.0-php8.5-apache   wordpress   Up

Verify from outside that WordPress responds with valid HTTPS (the 302 redirects to the install):

curl -sI https://YOUR_DOMAIN/ | head -1

HTTP/2 302

Step 4: The famous 5-minute install

Open https://YOUR_DOMAIN/. WordPress redirects to the install wizard. After the language selection you fill in the basics:

After clicking “Install WordPress” and the first login you land in the dashboard:

Step 5: The website is live

Your site is immediately public – with valid HTTPS from Traefik and no mixed-content errors thanks to the proxy configuration:

Step 6: Basic hardening

WordPress is functional out of the box but not optimally secured. The most important immediate measures:

• Enable automatic updates: under Dashboard → Updates make sure at least security updates are applied automatically.
• Delete unnecessary default content: the “Hello world!” post, the sample page and the bundled example plugin (Hello Dolly) can go.
• Less is more with plugins: every plugin is additional attack surface. Only install what you really need, and only from a trustworthy source.
• Protect the login further: ideally put another hurdle in front of the WordPress login (/wp-login.php). A rate-limit/BasicAuth middleware in Traefik or a 2FA plugin work well. Fail2ban can also evaluate WordPress login attempts.
• Keep an eye on XML-RPC: the file xmlrpc.php is a common target for brute force and DDoS. If you don’t need it, block it via a Traefik middleware or plugin.

When things go wrong

Maintenance & backups

• Honestly: WordPress is maintenance work. Unlike a static site, active code with a database runs here – core, themes and plugins get regular security updates that must be applied promptly. A neglected WordPress will reliably get hijacked. Enable automatic updates and check the update status monthly. Keep the container tag (wordpress:7.1.0-php8.5-apache) current via your normal update process.
• The backup has two parts – both are mandatory. WordPress consists of a database (posts, settings, users) and files (wp_data volume: uploads, themes, plugins). A Restic snapshot of the running MariaDB volume alone is no guarantee – back up the database additionally via a dump. -T matters here (without it the command hangs on the password prompt and leaves an empty file), as does putting the password directly after -p, with no space:

docker compose exec -T db mariadb-dump -u wordpress -p'YOUR_DB_PASSWORD' --single-transaction wordpress > backup.sql

Afterwards make sure the file isn’t empty (ls -l backup.sql). The dump and the wp_data volume belong in your Restic backup.

• Test the restore. A backup that was never restored is just a hope – run a restore at least once as a test, so that in an emergency you know the dump and files fit together.