WordPress on LiteSpeed Enterprise. Bring your own license.

Docker Compose walkthrough

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

name: wordpress-litespeed

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-litespeed:6.3.6-r1
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
    ports: ["${HTTP_PORT:-8085}: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}
      # LSWS_SERIAL: your-litespeed-enterprise-serial   # omit to run on the trial license
    volumes:
      - wp-content:/var/www/vhosts/localhost/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:8085. 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. For production, uncomment LSWS_SERIAL and set your license serial.

In production you place a TLS-terminating reverse proxy (such as Traefik) in front of the WordPress service. The proxy handles certificates and HTTP/3 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. LSWS_SERIAL is optional and controls licensing.

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.
LSWS_SERIAL	No	(unset)	LiteSpeed Enterprise serial; omit to run on the 14-day trial.
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/vhosts/localhost/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. PHP has expose_php off. Error display is off while error logging stays on.
• 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.
• Minimal exposure. Only the HTTP port (80) is published; TLS terminates at the reverse proxy.
• Non-root workers. lsphp workers run as nobody:nogroup 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-litespeed_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 server and the baseline plugins without touching your uploads and installed extensions. Your LSWS_SERIAL is supplied through the environment, so it carries across upgrades. 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.