Docker para desarrollo WordPress en 2026: Contenerización fácil

Si eres un desarrollador WordPress profesional en 2026, Docker es tu mejor aliado. Quedaron atrás los días de instalar manualmente versiones de PHP en tu Mac o luchar con errores específicos del servidor en Windows. Docker se ha convertido en el lenguaje común de los entornos de desarrollo, y conocerlo bien es parte del oficio para cualquier profesional que trabaje en el ecosistema WordPress actual.

En esta guía recorremos Docker aplicado al desarrollo WordPress: desde los conceptos básicos y la imagen oficial wordpress hasta Compose, wp-env, depuración, CI/CD y la migración desde MAMP o LocalWP. Los detalles técnicos salen de la documentación oficial de Docker, de la imagen wordpress en Docker Hub, de MariaDB y del manual de desarrolladores de WordPress, enlazados en cada sección.

#Por qué usar Docker para desarrollo WordPress

La excusa de “funciona en mi máquina” deja de valer cuando el entorno vive en archivos versionados. La contenerizacion garantiza consistencia entre entornos, y ese cambio ha transformado la forma en que los equipos de desarrollo WordPress colaboran y entregan software.

#Paridad entre el entorno local y producción

Tu contenedor local puede utilizar la misma distribución Linux, versión de PHP y configuración de MySQL que tu servidor de producción. Esto reduce la categoría más frustrante de errores: los que solo aparecen en producción. Cuando desarrollas dentro de un contenedor Docker con la misma imagen que usa el servidor, el código que funciona en tu portátil se comporta igual en el servidor de staging y en producción.

La paridad de entornos va más allá de las versiones de software. Incluye configuraciones de red, variables de entorno y permisos de archivos. Con Docker, cada miembro del equipo trabaja en un entorno idéntico, sin importar si usa macOS, Windows o Linux como sistema operativo anfitrión.

#Varias versiones de PHP en proyectos aislados

El Proyecto A necesita PHP 8.4, y el Proyecto B necesita PHP 7.4? No hay problema. Cada proyecto vive en su propia “burbuja” y nunca entra en conflicto con otros. Este nivel de aislamiento era muy difícil con herramientas tradicionales como MAMP o XAMPP, donde cambiar la versión de PHP afectaba a todos los proyectos a la vez.

El aislamiento de Docker también protege tu sistema operativo anfitrión. Las extensiones de PHP, las bibliotecas del sistema y las dependencias del proyecto se mantienen separadas. Si un proyecto requiere una extensión PHP experimental o una configuración de servidor poco convencional, puedes implementarla sin riesgo para tus otros proyectos.

#Entorno reproducible con archivos versionados en Git

Cada entorno Docker se define mediante archivos de configuración versionados en Git. Un miembro nuevo del equipo clona el repositorio, ejecuta un comando y tiene el entorno funcionando, sin una guía de instalación paso a paso que se queda desactualizada. La documentación del entorno vive en el propio código del proyecto.

#WordPress con Docker Compose

Docker Compose es la herramienta que coordina múltiples contenedores. Una configuración típica de WordPress en 2026 incluye varios servicios que trabajan juntos para crear un entorno de desarrollo completo.

#Qué servicios incluye WordPress en Docker Compose

1. WordPress (PHP-FPM o Apache): el motor que ejecuta el código PHP de WordPress.
2. Nginx: el servidor web delante de PHP-FPM, si eliges la variante fpm.
3. MariaDB/MySQL: la base de datos donde se almacena todo el contenido.
4. Redis: la caché de objetos, recomendable si el proyecto la usa en producción.
5. Mailpit: para capturar correos salientes durante las pruebas.

# Fragmento de compose.yaml con la variante FPM
services:
  db:
    image: mariadb:11.4
    volumes:
      - db_data:/var/lib/mysql
  wordpress:
    image: wordpress:php8.4-fpm
    depends_on:
      - db
volumes:
  db_data:

La variante fpm no incluye servidor web, así que necesita un contenedor Nginx que le pase las peticiones PHP. Si no quieres configurar Nginx, la variante con Apache (wordpress:php8.4-apache) sirve WordPress directamente en el puerto 80 del contenedor.

#Bind mounts o volúmenes nombrados para WordPress

Los volúmenes en Docker Compose son cruciales para el desarrollo WordPress. Necesitas montar tu directorio de temas y plugins para editar el código en tiempo real, mientras que los datos de la base de datos deben persistir en volúmenes nombrados para no perder información entre reinicios del contenedor.

La estrategia correcta equilibra rendimiento con funcionalidad. Para archivos que editas con frecuencia (temas, plugins propios), usa bind mounts. Para datos que solo necesitan persistir (base de datos, uploads), usa volúmenes nombrados de Docker. La documentación de la imagen oficial indica las rutas: los temas van en /var/www/html/wp-content/themes/ y los plugins en /var/www/html/wp-content/plugins/.

#Credenciales en archivos .env con Docker Compose

La gestión de secretos importa incluso en local. Utiliza archivos .env para credenciales de base de datos y claves de API, y asegúrate de que estos archivos estén incluidos en tu .gitignore. Docker Compose lee el archivo .env del directorio del proyecto y sustituye las variables como ${DB_PASSWORD} dentro de compose.yaml, lo que separa la configuración sensible del código versionado.

#Variables de entorno de la imagen oficial de WordPress

La imagen wordpress de Docker Hub genera su propio wp-config.php a partir de variables de entorno. Según la página oficial de la imagen, estas son las que reconoce:

El detalle que más tiempo hace perder: el contenedor de WordPress no crea la base de datos indicada en WORDPRESS_DB_NAME. La crea el contenedor de la base de datos, con MARIADB_DATABASE en MariaDB o MYSQL_DATABASE en MySQL. Si los dos nombres no coinciden, WordPress muestra un error de conexión aunque las credenciales sean correctas.

WORDPRESS_CONFIG_EXTRA sirve para constantes que la imagen no expone, por ejemplo WP_ALLOW_MULTISITE o WP_ENVIRONMENT_TYPE. Todo lo que pongas ahí se ejecuta con eval(), así que conviene mantenerlo corto y versionado junto al resto de la configuración.

#Cómo esperar a que MariaDB esté lista antes de WordPress

Un depends_on simple no basta. La documentación de Compose sobre el orden de arranque explica que Compose espera a que el contenedor de la dependencia esté en ejecución, no a que esté listo para aceptar conexiones. MariaDB tarda unos segundos en inicializarse la primera vez, y WordPress puede arrancar antes y fallar al conectar.

La solución es un healthcheck en la base de datos y condition: service_healthy en WordPress. La imagen oficial de MariaDB incluye el script healthcheck.sh para esto, y la documentación de MariaDB publica un ejemplo con WordPress. Adaptado a un entorno de desarrollo queda así:

services:
  db:
    image: mariadb:11.4
    environment:
      MARIADB_DATABASE: wordpress
      MARIADB_USER: wordpress
      MARIADB_PASSWORD: ${DB_PASSWORD}
      MARIADB_RANDOM_ROOT_PASSWORD: '1'
    volumes:
      - db_data:/var/lib/mysql
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      start_period: 10s
      interval: 10s
      timeout: 5s
      retries: 3
  wordpress:
    image: wordpress:php8.4-apache
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_NAME: wordpress
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: ${DB_PASSWORD}
      WORDPRESS_DEBUG: '1'
    volumes:
      - wp_data:/var/www/html
      - ./mi-tema:/var/www/html/wp-content/themes/mi-tema
    depends_on:
      db:
        condition: service_healthy
volumes:
  db_data:
  wp_data:

Con este archivo, docker compose up -d arranca la base de datos, espera a que el healthcheck pase y solo entonces inicia WordPress en http://localhost:8080. El tema propio se monta como bind mount, y el resto de WordPress queda en el volumen wp_data.

#Imágenes apache, fpm, alpine y cli de WordPress

La imagen oficial se publica en varias variantes. Las etiquetas combinan versión de WordPress, versión de PHP y tipo, por ejemplo php8.4-apache, php8.4-fpm, php8.4-fpm-alpine o cli.

• apache: WordPress y Apache en un solo contenedor. Es la opción más directa para desarrollo local.
• fpm: solo PHP-FPM, pensado para ir detrás de Nginx u otro proxy.
• fpm-alpine: lo mismo sobre Alpine Linux, con una imagen más pequeña.
• cli: WP-CLI sin servidor web, para ejecutar comandos wp contra una instalación existente.

La variante cli tiene una trampa documentada en Docker Hub: se basa en Alpine y su usuario www-data tiene el UID 82, mientras que las variantes basadas en Debian usan el UID 33. Al ejecutar wordpress:cli contra una instalación Debian suele hacer falta --user 33:33, y a veces -e HOME=/tmp, para que WP-CLI pueda escribir en los archivos.

#Cómo añadir extensiones PHP a la imagen oficial

La imagen no incluye extensiones PHP adicionales, aunque las pidan plugins populares. Docker Hub pone como ejemplo que la imagen no puede enviar correo por sí sola. Para añadir extensiones hay que construir una imagen propia con FROM wordpress:... y seguir las instrucciones de la imagen php. Para ajustar directivas como upload_max_filesize, basta con copiar un custom.ini a $PHP_INI_DIR/conf.d/:

FROM wordpress:php8.4-apache
COPY custom.ini $PHP_INI_DIR/conf.d/

Si quieres incluir temas o plugins dentro de la imagen para varias instalaciones, la documentación indica copiarlos a /usr/src/wordpress/, que se copia a /var/www/html/ en el primer arranque del contenedor.

#wp-env, el entorno Docker oficial de WordPress

Si desarrollas plugins o temas y no necesitas reproducir un servidor concreto, wp-env evita escribir el compose.yaml a mano. Es un paquete de Node mantenido en el repositorio de Gutenberg que usa Docker por debajo. Se instala con npm -g i @wordpress/env y se arranca con wp-env start desde la carpeta del plugin.

El entorno queda en http://localhost:8888 con el usuario admin y la contraseña password. La configuración va en un archivo .wp-env.json en la raíz del proyecto:

{
  "$schema": "https://schemas.wp.org/trunk/wp-env.json",
  "core": null,
  "phpVersion": "8.3",
  "plugins": [ "." ],
  "config": {
    "WP_DEBUG_LOG": true
  }
}

core en null usa la última versión estable de WordPress, phpVersion fija la versión de PHP y plugins lista los plugins que se instalan y activan. Existen además themes, mappings para montar directorios, port (8888 por defecto), testsPort (8889) y mariadbVersion.

Composer, PHPUnit y WP-CLI vienen incluidos en el contenedor cli: wp-env run cli wp plugin list o wp-env run cli --env-cwd=wp-content/plugins/mi-plugin composer install. Xdebug está instalado pero apagado, y se activa con wp-env start --xdebug. La documentación describe también un modo experimental, wp-env start --runtime=playground, que ejecuta WordPress en WebAssembly sin Docker, con SQLite y sin el comando run.

La diferencia práctica con Compose: wp-env decide la arquitectura por ti. Para un plugin es más rápido. Para reproducir un servidor de producción con Nginx, Redis y una versión exacta de MariaDB, Compose sigue siendo la herramienta adecuada.

#VS Code Dev Containers para WordPress

Muchos desarrolladores ya no instalan PHP en su portátil. Utilizan VS Code Dev Containers, que cambian la forma de trabajar con el editor.

#Cómo funciona un Dev Container en VS Code

Abres la carpeta de tu proyecto, y VS Code detecta la carpeta .devcontainer, arranca Docker y conecta el IDE directamente dentro del contenedor. Las extensiones de VS Code, las herramientas de línea de comandos y la configuración del editor se ejecutan dentro del contenedor.

#Extensiones y linters preconfigurados en el contenedor

Un espacio de trabajo configurado para cada proyecto, al abrir la carpeta. No importa si el desarrollador se unió al equipo hace cinco minutos o hace cinco años; el entorno es idéntico para todos. Las extensiones de PHP, los linters, los formateadores de código y las herramientas de depuración quedan definidos en el repositorio.

#Dev Containers para equipos distribuidos

Para agencias WordPress con equipos distribuidos, los Dev Containers eliminan una fuente común de fricción: las diferencias entre entornos locales. Un desarrollador en Madrid trabaja en el mismo entorno que uno en Buenos Aires o Ciudad de México, sin sesiones de “configuremos tu portátil”.

#Rendimiento de Docker en Mac y Windows

Docker era lento en sistemas que no fueran Linux, porque los archivos del proyecto cruzan una máquina virtual. Docker Desktop ofrece hoy varias opciones para reducir ese coste.

#Cómo activar VirtioFS en Docker Desktop

En macOS, elige VirtioFS como implementación de compartición de archivos en la configuración de Docker Desktop. La documentación de ajustes de Docker Desktop indica que VirtioFS ha reducido el tiempo de las operaciones de sistema de archivos hasta un 98%. Sustituye a las opciones anteriores, osxfs y gRPC FUSE.

#Synchronized file shares para repositorios grandes

Para proyectos muy grandes, Docker Desktop ofrece Synchronized file shares: mantiene una caché sincronizada de los archivos del anfitrión en un sistema ext4 dentro de la máquina virtual. Docker lo recomienda para repositorios de 100 000 archivos o más, y está disponible en las suscripciones Pro, Team y Business. Una instalación WordPress con un node_modules grande en el tema puede acercarse a esa cifra.

#Cuánta RAM usa Docker Desktop

La máquina virtual de Docker Desktop reserva memoria mientras está encendida. El modo Resource Saver la detiene cuando no hay contenedores en marcha durante 5 minutos (valor ajustable), y Docker indica un ahorro de 2 GB o más de memoria y CPU en el anfitrión.

#Docker vs LocalWP, MAMP y DDEV

#Docker Compose frente a DDEV y Lando

DDEV y Lando simplifican la experiencia Docker para desarrolladores WordPress. Proporcionan configuraciones preestablecidas y comandos simplificados que reducen la curva de aprendizaje. Para proyectos donde necesitas control total sobre cada pieza de la infraestructura, Compose con tu propio archivo sigue siendo la opción más flexible.

#Cuándo elegir DDEV y cuándo Docker Compose

La elección depende de tu experiencia y del proyecto. Si estás empezando con la contenerizacion, DDEV ofrece una curva de aprendizaje más suave. Si gestionas varios proyectos con requisitos de infraestructura distintos, Docker Compose con configuraciones propias te da más margen.

#Seguridad en entornos Docker para WordPress

Docker proporciona aislamiento por defecto, pero la configuración decide cuánta protección obtienes.

#Contenedores sin root e imágenes actualizadas

Evita ejecutar procesos como root dentro de tus contenedores cuando no haga falta. Mantén las imágenes base actualizadas para recibir parches de seguridad; la propia documentación de la imagen wordpress recuerda reconstruir y redesplegar con regularidad. Escanea tus imágenes en busca de vulnerabilidades conocidas con herramientas como Docker Scout o Trivy.

#Redes Docker separadas por proyecto

Compose crea una red propia para cada proyecto. Mantén esa separación y no conectes contenedores de proyectos distintos a la misma red sin motivo, para que una brecha en uno no alcance a los demás.

#Docker Secrets y archivos .env para contraseñas

Nunca incluyas credenciales directamente en tu Dockerfile o en compose.yaml. La imagen wordpress acepta el sufijo _FILE en sus variables: WORDPRESS_DB_PASSWORD_FILE=/run/secrets/db_password lee la contraseña desde un archivo en lugar de una variable. Compose monta cada secreto en /run/secrets/<nombre> dentro del contenedor, según su guía de secretos, que añade un límite: los secretos solo funcionan en contenedores Linux.

#Cómo configurar CI/CD para WordPress con Docker

La mayor ventaja de Docker es que tu pipeline de CI/CD (GitHub Actions, GitLab CI) puede utilizar las mismas imágenes que usas localmente. Esa consistencia elimina una categoría completa de errores de despliegue.

#Pasos de un pipeline CI/CD con Docker

1. Ejecutar pruebas PHPUnit en el contenedor para verificar la lógica del backend.
2. Ejecutar pruebas de extremo a extremo con Cypress o Playwright contra el contenedor.
3. Desplegar la imagen estable a tu clúster de producción (Kubernetes/Swarm).

#Registro privado de imágenes Docker para WordPress

Los equipos que construyen imágenes WordPress propias las guardan en un registro privado de contenedores. Esas imágenes incluyen las extensiones PHP necesarias, las herramientas de desarrollo y la configuración del proyecto, de modo que un miembro nuevo descarga la imagen en lugar de construirla.

Docker Hub describe también un modo de despliegue estático: construir una imagen con WordPress, el tema y los plugins dentro de /usr/src/wordpress, ejecutarla en modo --read-only con tmpfs para /tmp y /run, y actualizar desplegando una imagen nueva en lugar de usar las actualizaciones automáticas.

#WordPress en Kubernetes o Docker Swarm

Para sitios WordPress de alto tráfico, la orquestación con Kubernetes o Docker Swarm permite escalar según la demanda. Cuando el tráfico aumenta durante campañas o eventos de ventas, se levantan contenedores nuevos para absorber la carga.

#Cómo depurar WordPress en Docker

La depuración de WordPress dentro de contenedores requiere algunas técnicas distintas del desarrollo local tradicional.

#Xdebug dentro de contenedores

Configurar Xdebug dentro de un contenedor requiere atención a la red: el contenedor tiene que alcanzar el IDE que escucha en el anfitrión. Muchas configuraciones de Dev Containers ya traen Xdebug, wp-env lo activa con --xdebug, y en una imagen propia necesitarás instalar la extensión y configurar el host de conexión y el puerto.

#Cómo ver los logs con docker compose logs

Docker da acceso centralizado a los logs de todos los servicios. Utiliza docker compose logs para ver la salida combinada de WordPress, Nginx, MariaDB y Redis, o docker compose logs -f wordpress para seguir un solo servicio. Con WORDPRESS_DEBUG activado, los avisos de PHP aparecen en esa misma salida. En producción, herramientas como Grafana y Prometheus ofrecen paneles de monitorización.

#Query Monitor y Blackfire en Docker

Herramientas como Query Monitor y Blackfire funcionan dentro de entornos Docker WordPress. Perfilar dentro del contenedor da una imagen del rendimiento en condiciones cercanas a las de producción.

#Migrar de MAMP o LocalWP a Docker

Si usas MAMP, XAMPP o LocalWP, la migración a Docker es más sencilla de lo que parece. El proceso típico incluye exportar las bases de datos, crear archivos Compose que repliquen tu configuración actual y adoptar el resto de prácticas poco a poco.

#Cómo migrar un proyecto piloto a Docker Compose

Empieza con un solo proyecto piloto. Crea un archivo compose.yaml que replique tu entorno actual, incluida la versión de PHP, el motor de base de datos y las extensiones necesarias. Cuando el piloto funcione, migra los demás proyectos.

#Cómo importar la base de datos y wp-content

Exporta tus bases de datos con mysqldump e impórtalas en el contenedor MariaDB. Copia tus archivos de WordPress (especialmente wp-content) a la estructura de volúmenes de Docker. Si la URL cambia, por ejemplo a http://localhost:8080, ejecuta wp search-replace con WP-CLI y comprueba que los medios y enlaces funcionan en el nuevo entorno.

#Conclusión

Docker ya no es solo para DevOps; es una habilidad fundamental para los desarrolladores WordPress en 2026. Con la contenerizacion eliminas errores de entorno, aceleras la incorporación de nuevos miembros del equipo y construyes aplicaciones más seguras. El tiempo invertido en aprender Docker se recupera en productividad y calidad del código.

Descubre más sobre nuestros servicios de optimización de velocidad WordPress y como la contenerizacion contribuye al rendimiento general de tu sitio.

Sigues luchando con configuraciones de servidores locales? Es hora de contenerizar tu entorno con Docker.