An enterprise-grade WordPress image built for scale. It uses the new FrankenPHP server bundled with Caddy. Lightning-fast server side caching Caddy module.
- Standard environment with MariaDB & Docker Compose
- Debug with XDebug & Docker Compose
- SQLite with Docker Compose
- opcache
- Internal server sidekick
SERVER_NAME: change the addresses on which to listen, the provided hostnames will also be used for the generated TLS certificateCADDY_GLOBAL_OPTIONS: inject global options (debug most common)FRANKENPHP_CONFIG: inject config under the frankenphp directive
CACHE_LOC: Where to store cache. Defaults to /var/www/html/wp-content/cacheCACHE_RESPONSE_CODES: Which status codes to cache. Defaults to 200,404,405BYPASS_PATH_PREFIX: Which path prefixes to not cache. Defaults to /wp-admin,/wp-jsonBYPASS_HOME: Whether to skip caching home. Defaults to false.PURGE_KEY: Create a purge key that must be validated on purge requests. Helps to prevent malicious intent. No default.PURGE_PATH: Create a custom route for the cache purge API path. Defaults to /__cache/purge.TTL: Defines how long objects should be stored in cache. Defaults to 6000.
DB_NAME: The WordPress database name.DB_USER: The WordPress database user.DB_PASSWORD: The WordPress database password.DB_HOST: The WordPress database host.DB_TABLE_PREFIX: The WordPress database table prefix.WP_DEBUG: Turns on WordPress Debug.FORCE_HTTPS: Tells WordPress to use https on requests. This is beneficial behind load balancer. Defaults to true.WORDPRESS_CONFIG_EXTRA: use this for adding WP_HOME, WP_SITEURL, etc
The standard WordPress images are a good starting point and can handle many use cases, but require significant modification to scale. You also don't get FrankenPHP app server. Instead, you need to choose Apache or PHP-FPM. We use the WordPress base image but extend it with FrankenPHP & Caddy.
FrankenPHP is built on Caddy, a modern web server built in Go. It is secure & performs well when scaling becomes important. It also allows us to take advantage of built-in mature concurrency through goroutines into a single Docker image. high performance in a single lean image.
It is good practice to avoid using root users in your Docker images for security purposes. If a questionable individual gets access into your running Docker container with root account then they could have access to the cluster and all the resources it manages. This could be problematic. On the other hand, by creating a user specific to the Docker image, narrows the threat to only the image itself. It is also important to note that the base WordPress images also create non-root users by default.
This custom Caddy build also includes an internal project named sidekick. It provides lightning fast cache that can be distributed among many containers. The default cache uses the local wp-content/cache directory but can use many cache services.
tldr: Use a port (ie :80, :8095, etc) for SERVER_NAME env variable.
Working in cloud environments like AWS can be tricky because your traffic is going through a load balancer or some proxy. This means your server name is not what you think your server name is. Your domain hits a proxy dns entry that then hits your application. The application doesn't know your domain. It knows the proxied name. This may seem strange, but it's actually a well established strong architecture pattern.
What about SSL cert? Use SERVER_NAME=mydomain.com, :80
Caddy, the underlying application server is flexible enough for multiple entries. Separate multiple values with a comma. It will still request certificate.
You can join our Slack chat to ask questions or connect directly. Connect on Slack