Using Docker with WordPress

Docker can modernize your WordPress infrastructure with benefits like consistent environments, easier deployments, and better scalability.

However, WordPress's architecture predates modern containerization, so you'll need to balance container best practices with WordPress conventions to maintain plugin compatibility.

Security Optimizations

These images include security hardening specifically for WordPress deployments:

• Hardened Apache & NGINX configurations
• XML-RPC disabled by default (prevents common attack vectors)
• Protected access to sensitive files (.git, .env, CI configurations)
• Additional protections against common WordPress exploits

See our Apache security.conf for complete details.

"The WordPress Way"

WordPress has evolved significantly over the years, but its architecture was designed before modern containerization practices became standard. This means you'll find the smoothest experience when you align with WordPress's conventions rather than trying to impose modern development patterns that conflict with how WordPress expects to operate.

What does "The WordPress Way" mean for Docker users?

WordPress was built with certain assumptions:

• Files are directly accessible and writable by the web server
• Plugins and themes can be updated through the admin interface
• The application runs on traditional LAMP (Linux, Apache, MySQL, PHP) stacks
• Core, plugins, and themes are typically deployed together

When you try to modernize WordPress with approaches like immutable containers, NGINX instead of Apache, or separating core files from your custom code, you may encounter compatibility issues with popular plugins that expect traditional WordPress file structures and permissions.

The more you work with WordPress's conventions, the fewer compatibility issues you'll face with community plugins and themes.

Common Compatibility Challenges

Modern container practices that work well with Laravel or other frameworks may cause issues with WordPress:

Using NGINX instead of Apache

• Many WordPress plugins expect Apache's .htaccess functionality
• URL rewriting rules often need manual translation to NGINX
• Some plugins detect the web server and behave differently

Packaging WordPress core into images

• The WordPress admin expects to update core, plugins, and themes through the UI
• Immutable containers conflict with this expectation
• Popular plugins may break when they can't write to expected directories

Using newer PHP versions

• Some popular plugins haven't updated for newer PHP versions
• WordPress core itself is conservative with PHP version requirements
• Testing against your specific plugin stack is essential

Using modern project structures (like Roots Bedrock)

• Changes WordPress's default directory structure
• Some plugins hardcode paths and break with non-standard layouts
• Community support often assumes standard WordPress structure

Recommended Approach

Based on our experience running WordPress in production containers, we recommend these principles:

1. Align with WordPress conventions

• Use Apache as your web server for maximum plugin compatibility
• Allow WordPress to manage its own updates when possible
• Maintain the standard WordPress directory structure

2. Keep customizations minimal

• Limit plugin installation to essential functionality
• Fewer plugins means fewer compatibility concerns
• Each plugin is a potential maintenance burden

3. Separate your code from WordPress core

• Only commit your custom themes and plugins to version control
• Exclude WordPress core and third-party plugins from your repository
• This makes your codebase smaller and easier to manage

Production Stack Example

Here's a proven WordPress stack running on Docker Swarm that balances containerization benefits with WordPress compatibility:

Infrastructure components:

1. Traefik - Automatic SSL with Let's Encrypt and request routing
2. serversideup/php:8.4-fpm-apache - PHP with Apache for WordPress compatibility
3. MariaDB - MySQL-compatible database without Oracle licensing

Deployment Strategies

WordPress presents unique challenges when deciding how to deploy updates in containerized environments.

Immutable Container Approach (Advanced)

Packaging WordPress into Docker images with tools like Roots Bedrock enables modern deployment practices:

Benefits:

• Rolling updates with zero downtime
• Immutable infrastructure (containers don't change after deployment)
• Easy rollback to previous versions

Challenges:

• Many popular plugins expect to write to WordPress directories
• Plugin updates must happen outside the WordPress admin interface
• Requires thorough compatibility testing with your plugin stack
• Non-standard directory structure breaks some plugins

Volume-Based Approach (Traditional)

Treating containers as the runtime environment while keeping WordPress files on persistent volumes offers the most compatibility:

Benefits:

• WordPress admin can update core, plugins, and themes normally
• Maximum compatibility with community plugins
• Familiar workflow for WordPress developers

Challenges:

• Updates aren't versioned in your deployment pipeline
• Requires traditional deployment methods for custom code
• Less alignment with immutable infrastructure principles

Example implementation:

services:
  wordpress:
    image: serversideup/php:8.4-fpm-apache
    volumes:
      - ./:/var/www/html
    ports:
      - 80:8080
      - 443:8443

Deploy your custom theme/plugin updates:

# On your deployment server
cd /path/to/your/project
git pull origin main

Which approach should you choose?

• Volume-based: Best for sites heavily dependent on third-party plugins or when you need maximum WordPress ecosystem compatibility
• Immutable containers: Best for custom WordPress applications with minimal third-party dependencies where you control the entire codebase

Always test your specific plugin stack thoroughly before committing to either approach.

Example Repository

Below is an example repository showing the "traditional" approach to using WordPress with Docker.