Instalar WordPress con Docker y Composer: configuración de desarrollo moderna para 2026

El desarrollo de WordPress ha superado las subidas por FTP y los paneles de alojamiento compartido. En 2026, los equipos profesionales tratan WordPress como cualquier otro proyecto de software, con dependencias versiónadas, entornos containerizados y pipelines de despliegue automatizados. Si todavía estás editando archivos directamente en un servidor en producción, esta guía cambiara tu forma de trabajar.

Este tutorial cubre dos enfoques complementarios para el desarrollo moderno de WordPress: Docker Compose para entornos de servidor reproducibles y Composer con Bedrock para la gestión de dependencias. Obtendrás archivos de configuración completos y listos para copiar, configuración de Xdebug para depuración PHP adecuada y un flujo de despliegue que lleva tu código desde la máquina local hasta producción de forma segura.

#Por qué usar Docker para desarrollar WordPress

El enfoque clásico de descargar un archivo ZIP de wordpress.org y subirlo vía FTP crea varios problemas que se acumulan con el tiempo:

• Desviación de entorno - tu configuración local MAMP o XAMPP nunca coincide exactamente con el servidor de producción, lo que lleva a errores del tipo “funciona en mi máquina”.
• Sin seguimiento de dependencias - los plugins y temas se descargan y actualizan manualmente, haciendo imposible reproducir exactamente el mismo sitio en otra máquina.
• Sin control de versiones para el núcleo - los archivos del núcleo de WordPress están en tu repositorio (o peor, no se rastrean en absoluto), mezclando código de aplicación con código de framework.
• Despliegues manuales - copiar archivos por FTP es propenso a errores y no proporciona mecanismo de reversión.

Docker y Composer resuelven cada uno de estos problemas de forma sistemática.

#Configurar WordPress con Docker Compose

Docker Compose te permite definir toda tu pila de servidor en un único archivo YAML. Cada desarrollador del equipo obtiene exactamente la misma versión de PHP, versión de MySQL y configuración de servidor ejecutando un solo comando.

#Prerrequisitos

Instala Docker Desktop para tu sistema operativo. Docker Desktop incluye tanto el motor Docker como el plugin CLI docker compose. Verifica la instalación:

docker --version
docker compose version

#Estructura del proyecto

Crea un directorio de proyecto limpio:

mkdir wordpress-docker && cd wordpress-docker
mkdir -p wp-content/themes wp-content/plugins wp-content/uploads

#El docker-compose.yml completo

Crea un archivo docker-compose.yml en la raíz de tu proyecto:

services:
  db:
    image: mysql:8.0
    container_name: wp_mysql
    restart: unless-stopped
    environment:
      MYSQL_DATABASE: ${DB_NAME:-wordpress}
      MYSQL_USER: ${DB_USER:-wpuser}
      MYSQL_PASSWORD: ${DB_PASSWORD:-wppassword}
      MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD:-rootpassword}
    volumes:
      - db_data:/var/lib/mysql
    ports:
      - "3306:3306"
    networks:
      - wp_network
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 10s
      timeout: 5s
      retries: 5

  wordpress:
    image: wordpress:7.1-php8.3-apache
    container_name: wp_app
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_NAME: ${DB_NAME:-wordpress}
      WORDPRESS_DB_USER: ${DB_USER:-wpuser}
      WORDPRESS_DB_PASSWORD: ${DB_PASSWORD:-wppassword}
      WORDPRESS_DEBUG: ${WP_DEBUG:-1}
      WORDPRESS_CONFIG_EXTRA: |
        define('WP_DEBUG_LOG', true);
        define('WP_DEBUG_DISPLAY', false);
        define('SCRIPT_DEBUG', true);
        define('DISALLOW_FILE_EDIT', true);
    volumes:
      - ./wp-content/themes:/var/www/html/wp-content/themes
      - ./wp-content/plugins:/var/www/html/wp-content/plugins
      - ./wp-content/uploads:/var/www/html/wp-content/uploads
      - ./php-custom.ini:/usr/local/etc/php/conf.d/custom.ini
    ports:
      - "8080:80"
    networks:
      - wp_network

  phpmyadmin:
    image: phpmyadmin:5
    container_name: wp_phpmyadmin
    restart: unless-stopped
    depends_on:
      - db
    environment:
      PMA_HOST: db
      PMA_PORT: 3306
      MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD:-rootpassword}
    ports:
      - "8081:80"
    networks:
      - wp_network

  mailhog:
    image: mailhog/mailhog:latest
    container_name: wp_mailhog
    ports:
      - "1025:1025"
      - "8025:8025"
    networks:
      - wp_network

volumes:
  db_data:

networks:
  wp_network:
    driver: bridge

Esta configuración te proporciona cuatro servicios:

• MySQL 8.0 con verificación de salud para que WordPress espere a que la base de datos este lista antes de iniciar.
• WordPress 7.1 en PHP 8.3 con Apache, montando solo tus temas, plugins y subidas personalizados.
• phpMyAdmin para gestión visual de la base de datos en http://localhost:8081.
• MailHog para capturar correos electrónicos salientes durante el desarrollo en http://localhost:8025.

#Variables de entorno con .env

Crea un archivo .env en la raíz del proyecto:

# Base de datos
DB_NAME=wordpress
DB_USER=wpuser
DB_PASSWORD=secure_local_password_2026
DB_ROOT_PASSWORD=secure_root_password_2026

# WordPress
WP_DEBUG=1

# Sitio
SITE_URL=http://localhost:8080

Docker Compose lee automáticamente archivos .env del directorio del proyecto. Agrega .env a tu .gitignore inmediatamente y haz commit de una plantilla .env.example en su lugar.

#Guardar las contraseñas de la base de datos en secrets de Compose

El archivo .env anterior pasa las contraseñas como variables de entorno. La documentación de Docker sobre secrets en Compose advierte que las variables de entorno suelen estar disponibles para todos los procesos del contenedor y pueden acabar impresas en los logs mientras depuras. Un secret de Compose se monta como archivo en /run/secrets/<secret_name>, y solo lo pueden leer los servicios que lo declaran.

La imagen oficial de WordPress en Docker Hub lee esos archivos cuando añades _FILE al nombre de una variable. Su documentación lo admite para el host, el usuario, la contraseña y el nombre de la base de datos, las ocho claves y salts de autenticación, WORDPRESS_TABLE_PREFIX y WORDPRESS_DEBUG. La imagen de MySQL sigue la misma convención:

services:
  db:
    environment:
      MYSQL_PASSWORD_FILE: /run/secrets/db_password
      MYSQL_ROOT_PASSWORD_FILE: /run/secrets/db_root_password
    secrets:
      - db_password
      - db_root_password

  wordpress:
    environment:
      WORDPRESS_DB_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password

secrets:
  db_password:
    file: ./secrets/db_password.txt
  db_root_password:
    file: ./secrets/db_root_password.txt

La variable _FILE sustituye a la variable simple en el mismo servicio, así que elimina MYSQL_PASSWORD, MYSQL_ROOT_PASSWORD y WORDPRESS_DB_PASSWORD de esos servicios. Deja el directorio secrets/ fuera de Git, igual que .env. Docker indica un límite: los secrets de Compose solo funcionan en contenedores Linux, porque cada secret se monta como un único archivo mediante bind mount.

#Configuración PHP personalizada

Crea php-custom.ini para ajustes PHP amigables con el desarrollo:

upload_max_filesize = 128M
post_max_size = 128M
memory_limit = 512M
max_execution_time = 300
max_input_vars = 3000
display_errors = On
error_reporting = E_ALL

#Iniciar el entorno

docker compose up -d

Abre http://localhost:8080 y completa la instalación de WordPress. Tus directorios de temas y plugins están montados desde la máquina anfitriona, por lo que cualquier cambio que hagas en tu editor aparece instantáneamente en la instancia de WordPress en ejecución.

#Añadir un contenedor WP-CLI con la imagen wordpress:cli

La variante Apache de la imagen de WordPress no incluye el comando wp, por eso las llamadas a WP-CLI de esta guía pasan por un servicio wpcli separado. Docker Hub publica para ello una variante cli de la misma imagen, como wordpress:cli y con una versión de PHP fijada, por ejemplo wordpress:cli-php8.3. Añádela dentro de services::

  wpcli:
    image: wordpress:cli-php8.3
    user: "33:33"
    profiles: ["tools"]
    depends_on:
      - db
      - wordpress
    volumes_from:
      - wordpress
    environment:
      HOME: /tmp
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_NAME: ${DB_NAME:-wordpress}
      WORDPRESS_DB_USER: ${DB_USER:-wpuser}
      WORDPRESS_DB_PASSWORD: ${DB_PASSWORD:-wppassword}
    networks:
      - wp_network

La documentación de la imagen explica la línea user. Las variantes cli se basan en Alpine, donde www-data tiene el UID 82, mientras que las imágenes de WordPress basadas en Debian se ejecutan con el UID 33. Sin user: "33:33", los archivos que crea WP-CLI pertenecen a un usuario que el servidor web no reconoce. La misma documentación sugiere HOME=/tmp para los comandos que intentan escribir en ~/.wp-cli. volumes_from monta los archivos del servicio wordpress, y las variables de la base de datos permiten que el wp-config.php compartido se conecte.

La entrada profiles evita que docker compose up -d arranque el contenedor. La documentación de perfiles de Compose indica que un servicio invocado de forma explícita se ejecuta aunque su perfil no esté activo, así que docker compose run --rm wpcli wp plugin list funciona sin opciones adicionales. Para un repaso más amplio de los contenedores en el trabajo con WordPress, lee nuestra guía de Docker para el desarrollo de WordPress.

#Comandos Docker útiles para el trabajo diario

# Ver registros de todos los contenedores
docker compose logs -f

# Ver registros solo de WordPress
docker compose logs -f wordpress

# Abrir una shell dentro del contenedor WordPress
docker compose exec wordpress bash

# Ejecutar comandos WP-CLI dentro del contenedor
docker compose run --rm wpcli wp plugin list

# Detener todos los contenedores (preserva datos)
docker compose stop

# Detener y eliminar contenedores (preserva datos de volumenes)
docker compose down

# Reinicio completo incluyendo base de datos
docker compose down -v

#Gestionar WordPress con Composer y Bedrock

Mientras Docker maneja el entorno de servidor, Bedrock de Roots reestructura WordPress en si mismo como una aplicación correctamente gestionada por Composer. Bedrock trata el núcleo de WordPress como una dependencia, no como la raíz del proyecto, lo que cambia todo sobre cómo gestionas y despliegas WordPress.

#Qué es Bedrock y por qué usarlo

WordPress estándar mezcla código de aplicación (tu tema, plugins) con código de framework (wp-admin, wp-includes) en el mismo directorio. Bedrock separa estas preocupaciones:

project-root/
  config/              # Configuración específica del entorno
    application.php
    environments/
      development.php
      staging.php
      production.php
  web/                 # Raiz del documento (publica)
    app/               # Equivalente a wp-content
      themes/
      plugins/
      uploads/
    wp/                # Nucleo de WordPress (gestionado por Composer)
    wp-config.php      # Cargador mínimo
  vendor/              # Dependencias de Composer
  .env                 # Variables de entorno
  composer.json        # Manifiesto de dependencias

El núcleo de WordPress reside en web/wp/ y nunca se modifica. Tu código personalizado reside en web/app/. El directorio vendor/ y web/wp/ están ambos en el gitignore porque Composer los recrea a partir de composer.json.

#Instalar Bedrock

composer create-project roots/bedrock my-wordpress-project
cd my-wordpress-project

#La estructura de composer.json

El composer.json de Bedrock gestiona el núcleo de WordPress, plugins y temas como paquetes:

{
  "name": "your-agency/client-project",
  "type": "project",
  "license": "MIT",
  "description": "WordPress project managed with Bedrock and Composer",
  "require": {
    "php": ">=8.3",
    "composer/installers": "^2.3",
    "vlucas/phpdotenv": "^5.6",
    "oscarotero/env": "^2.1",
    "roots/bedrock-autoloader": "^1.0",
    "roots/bedrock-disallow-indexing": "^2.0",
    "roots/wordpress": "7.1.*",
    "roots/wp-config": "1.0.0",
    "wpackagist-plugin/wordpress-seo": "^23.0",
    "wpackagist-plugin/wp-super-cache": "^1.12",
    "wpackagist-plugin/wordfence": "^7.11"
  },
  "require-dev": {
    "squizlabs/php_codesniffer": "^3.10",
    "roave/security-advisories": "dev-latest"
  },
  "config": {
    "optimize-autoloader": true,
    "preferred-install": "dist",
    "allow-plugins": {
      "composer/installers": true,
      "roots/wordpress-core-installer": true
    }
  },
  "repositories": [
    {
      "type": "composer",
      "url": "https://wpackagist.org",
      "only": [
        "wpackagist-plugin/*",
        "wpackagist-theme/*"
      ]
    }
  ],
  "extra": {
    "installer-paths": {
      "web/app/mu-plugins/{$name}/": [
        "type:wordpress-muplugin"
      ],
      "web/app/plugins/{$name}/": [
        "type:wordpress-plugin"
      ],
      "web/app/themes/{$name}/": [
        "type:wordpress-theme"
      ]
    },
    "wordpress-install-dir": "web/wp"
  }
}

El punto clave: WordPress Packagist replica todo el repositorio de plugins y temas de WordPress.org como paquetes Composer. Agregar un plugin es tan simple como:

composer require wpackagist-plugin/advanced-custom-fields

Eliminarlo es igualmente limpio:

composer remove wpackagist-plugin/advanced-custom-fields

#Versionar composer.lock y desplegar con composer install

composer.json contiene rangos de versiones como ^23.0; composer.lock registra las versiones exactas que Composer resolvió. La documentación de uso básico de Composer indica que hay que confirmar el archivo lock en el repositorio del proyecto, porque así cualquiera que monte el proyecto usa las mismas versiones de las dependencias. Si existe un archivo lock, composer install instala exactamente lo que figura en él. composer update es el comando que obtiene versiones compatibles más nuevas y reescribe el lock.

En un proyecto WordPress, ejecuta composer update en local, o composer update wpackagist-plugin/wordpress-seo para un solo plugin, prueba el resultado en Docker, confirma el composer.lock modificado y deja que el pipeline ejecute composer install, como hace el ejemplo de GitHub Actions más abajo. Así una actualización de plugin se convierte en un diff que se puede revisar, en lugar de un clic en wp-admin sobre el sitio en producción.

El sitio de WPackagist explica que escanea el repositorio Subversion de WordPress.org cada hora y asigna las etiquetas a versiones, de modo que una nueva versión de un plugin puede tardar hasta una hora en aparecer allí. Para los plugins añade además trunk como versión de desarrollo (dev-trunk), que sigue código no publicado y no debe estar en un lock de producción. La misma página señala que WPackagist lo mantiene ahora WP Engine.

#Configuración de entorno Bedrock

Bedrock usa archivos .env en lugar de codificar valores directamente en wp-config.php:

# Archivo .env para Bedrock
DB_NAME=wordpress
DB_USER=wpuser
DB_PASSWORD=secure_local_password_2026
DB_HOST=db:3306
DB_PREFIX=wp_

WP_ENV=development
WP_HOME=http://localhost:8080
WP_SITEURL=${WP_HOME}/wp

# Genere estos en https://roots.io/salts.html
AUTH_KEY='generate-unique-key-here'
SECURE_AUTH_KEY='generate-unique-key-here'
LOGGED_IN_KEY='generate-unique-key-here'
NONCE_KEY='generate-unique-key-here'
AUTH_SALT='generate-unique-salt-here'
SECURE_AUTH_SALT='generate-unique-salt-here'
LOGGED_IN_SALT='generate-unique-salt-here'
NONCE_SALT='generate-unique-salt-here'

Cada entorno (desarrollo, staging, producción) tiene su propio archivo .env en su respectivo servidor. La misma base de código se ejecuta en todas partes, con el comportamiento controlado completamente por variables de entorno.

#Ejecutar Bedrock en Docker

El verdadero poder surge al ejecutar Bedrock dentro de Docker. Modifica el docker-compose.yml para montar tu proyecto Bedrock en lugar de la imagen WordPress predeterminada:

services:
  wordpress:
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - .:/var/www/html
    environment:
      - WP_ENV=development

Con un Dockerfile personalizado:

FROM php:8.3-apache

RUN apt-get update && apt-get install -y \
    libzip-dev \
    libpng-dev \
    libjpeg-dev \
    libfreetype6-dev \
    libicu-dev \
    && docker-php-ext-configure gd --with-freetype --with-jpeg \
    && docker-php-ext-install \
    mysqli \
    pdo_mysql \
    zip \
    gd \
    intl \
    opcache

RUN a2enmod rewrite

COPY --from=composer:latest /usr/bin/composer /usr/bin/composer

ENV APACHE_DOCUMENT_ROOT /var/www/html/web

RUN sed -ri -e 's!/var/www/html!${APACHE_DOCUMENT_ROOT}!g' \
    /etc/apache2/sites-available/*.conf \
    /etc/apache2/apache2.conf

WORKDIR /var/www/html

Esto te da un entorno Bedrock completamente containerizado donde composer install se ejecuta dentro del contenedor y la raíz del documento apunta al directorio web/ de Bedrock.

#Configuración de Xdebug para depuración PHP

La depuración paso a paso reemplaza var_dump y error_log con un depurador adecuado que te permite pausar la ejecución, inspeccionar variables y recorrer el código línea por línea.

#Agregar Xdebug a su contenedor Docker

Crea un archivo xdebug.ini:

[xdebug]
zend_extension=xdebug
xdebug.mode=debug,develop
xdebug.start_with_request=yes
xdebug.client_host=host.docker.internal
xdebug.client_port=9003
xdebug.discover_client_host=0
xdebug.log=/tmp/xdebug.log
xdebug.idekey=VSCODE

Agrega la instalación de Xdebug a tu Dockerfile:

RUN pecl install xdebug-3.3.2 \
    && docker-php-ext-enable xdebug

COPY xdebug.ini /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini

#Configuración de VS Code

Crea .vscode/launch.json en la raíz de tu proyecto:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Listen for Xdebug (Docker)",
      "type": "php",
      "request": "launch",
      "port": 9003,
      "pathMappings": {
        "/var/www/html": "${workspaceFolder}"
      },
      "log": true
    }
  ]
}

Instala la extensión PHP Debug de Xdebug en VS Code, establece un breakpoint en cualquier archivo PHP, presiona F5 para comenzar a escuchar y recarga tu página WordPress. El depurador se detendrá en tu breakpoint.

#Configuración de PhpStorm

PhpStorm maneja las conexiones Xdebug de Docker de forma nativa:

1. Ve a Settings > PHP > Debug y verifica que el puerto 9003 está configurado.
2. Ve a Settings > PHP > Servers, agrega un nuevo servidor con localhost en el puerto 8080 y configura el mapeo de rutas de /var/www/html a la raíz de tu proyecto.
3. Haz clic en el botón Start Listening for PHP Debug Connections en la barra de herramientas.

#Desplegar WordPress de local a staging y producción

#Ejecutar composer install en un hosting gestionado

En los proyectos que acompañamos en España, el destino habitual es un hosting gestionado con panel, no un servidor propio, y ahí el acceso SSH depende del plan contratado. Comprueba eso antes de elegir Bedrock: sin SSH el composer install tiene que ocurrir en el pipeline y el directorio vendor viaja con la release.

La otra consecuencia es el volcado de base de datos. Si el equipo trabaja con copias de producción en local, los datos personales salen del entorno controlado, así que la anonimización va en el mismo paso automatizado y no a mano después.

Una pipeline de despliegue profesional asegura que los cambios de código fluyan predeciblemente desde el desarrollo hasta producción sin copia manual de archivos.

#El modelo de tres entornos

1. Local (Docker) - donde escribes y pruebas código.
2. Staging - un servidor que refleja producción para pruebas finales.
3. Producción - el sitio en vivo.

#Despliegue basado en Git con GitHub Actions

Tu repositorio debe contener el código del tema, plugin y configuración de Bedrock. No debe contener el núcleo de WordPress, vendor/ ni uploads/.

Ejemplo .github/workflows/deploy.yml:

name: Deploy to staging

on:
  push:
    branches: [staging]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: "8.3"

      - name: Install dependencies
        run: composer install --no-dev --optimize-autoloader

      - name: Run code quality checks
        run: vendor/bin/phpcs --standard=WordPress web/app/themes/

      - name: Deploy via rsync
        uses: burnett01/[email protected]
        with:
          switches: -avz --delete --exclude='.env' --exclude='web/app/uploads/'
          path: ./
          remote_path: /var/www/staging.example.com/
          remote_host: ${{ secrets.STAGING_HOST }}
          remote_user: ${{ secrets.STAGING_USER }}
          remote_key: ${{ secrets.STAGING_SSH_KEY }}

#Sincronización de base de datos y archivos subidos

El código se despliega a través de Git, pero las bases de datos y los archivos multimedia requieren un manejo separado:

# Exportar base de datos de producción
wp db export production-backup.sql --ssh=user@production

# Importar en staging
wp db import production-backup.sql --ssh=user@staging

# Buscar y reemplazar URLs
wp search-replace 'https://example.com' 'https://staging.example.com' --ssh=user@staging

# Sincronizar subidas de producción a staging
rsync -avz user@production:/var/www/html/web/app/uploads/ \
  user@staging:/var/www/html/web/app/uploads/

Para el desarrollo local, usa los comandos WP-CLI wp db export y wp db import a través de Docker:

docker compose run --rm -T wpcli wp db export - > ./backups/backup.sql

#Comparación: Docker vs Composer vs LocalWP vs MAMP

La conclusion principal: Docker y Composer son complementarios, no competidores. Docker reemplaza a MAMP/XAMPP como entorno de servidor, mientras que Composer reemplaza la gestión manual de plugins/temas. LocalWP sigue siendo una opción válida para prototipado rápido, pero carece de la reproducibilidad e integración CI/CD que los equipos profesionales necesitan.

#Consejos de rendimiento para Docker en macOS

Docker en macOS sufrió históricamente de un rendimiento lento del sistema de archivos debido a la capa de virtualizacion. En 2026, Docker Desktop usa VirtioFS por defecto, lo que mejora dramáticamente las velocidades de E/S. Si todavía experimentas lentitud:

• Verifica que VirtioFS está habilitado en Docker Desktop > Settings > General.
• Limita los volúmenes montados solo a lo que necesitas (temas, plugins, subidas), no a toda la instalación de WordPress.
• Usa las directivas de cache integradas de Docker si es necesario: volumes: - ./wp-content:/var/www/html/wp-content:cached.
• Asigna recursos suficientes en Docker Desktop > Settings > Resources (al menos 4 GB de RAM y 2 CPUs).

#Seguridad de WordPress local en Docker

Incluso en entornos locales, los hábitos de seguridad importan porque las configuraciones a menudo se filtran a producción:

• Nunca hagas commit de archivos .env en Git. Usa .env.example como plantilla.
• Usa contraseñas fuertes y únicas en tu .env incluso localmente, para nunca desplegar accidentalmente credenciales débiles.
• Mantén DISALLOW_FILE_EDIT configurado como true en todos los entornos.
• Ejecuta composer audit regularmente para verificar vulnerabilidades conocidas en tus dependencias.
• Fija versiones específicas en composer.json para despliegues en producción en lugar de usar restricciones de versión flexibles.

#Errores comunes de WordPress en Docker

El contenedor MySQL se cierra inmediatamente Verifica los registros con docker compose logs db. La causa más común es un volumen existente con datos incompatibles. Ejecuta docker compose down -v para eliminar volúmenes y comenzar de nuevo.

WordPress no puede conectarse a la base de datos Verifica que el valor WORDPRESS_DB_HOST coincide con el nombre del servicio en docker-compose.yml (típicamente db:3306). Asegúrate de que el contenedor de la base de datos está saludable antes de que WordPress inicie, usando la condición depends_on mostrada en la configuración anterior.

Xdebug no se conecta Confirma que host.docker.internal se resuelve correctamente dentro del contenedor. En Linux, puedes necesitar agregar extra_hosts: - "host.docker.internal:host-gateway" a la definición del servicio WordPress.

Errores de permisos de archivos Si WordPress no puede escribir en wp-content/uploads, ajusta los permisos dentro del contenedor:

docker compose exec wordpress chown -R www-data:www-data /var/www/html/wp-content/uploads

#Herramientas para ampliar WordPress con Docker

Una vez que tengas Docker y Composer funcionando, considera estas adiciones para profesionalizar aun más tu configuración:

• WP-CLI como dependencia de Composer para gestión de WordPress mediante scripts.
• PHPStan o Psalm para análisis estático del código PHP de tus temas y plugins.
• GitHub Actions o GitLab CI para pruebas automatizadas en cada pull request.
• Redis o Memcached como servicio Docker adicional para cache de objetos durante el desarrollo.
• Traefik o Nginx Proxy para gestionar múltiples proyectos WordPress locales con dominios personalizados en lugar de números de puerto.

La ingeniería WordPress moderna significa tratar tu sitio como un producto de software, con builds reproducibles, pruebas automatizadas y despliegues seguros. Las herramientas cubiertas en esta guía, Docker Compose para entornos y Composer con Bedrock para gestión de dependencias, forman la base que todo equipo WordPress serio necesita en 2026.

En wppoland.com, construyo y mantengo proyectos WordPress usando exactamente estos flujos de trabajo. Si tu equipo necesita ayuda para modernizar tu proceso de desarrollo WordPress, configurar pipelines CI/CD o migrar de configuraciones heredadas a entornos containerizados, estoy disponible para consultoría e implementación. Los precios son siempre individuales y dependen del alcance de tu proyecto.