Monta tu Drupal local con DDEV y olvídate del "en mi máquina sí funciona"

Si trabajas con Drupal en serio, tarde o temprano te topas con el mismo muro: cada desarrollador tiene una versión distinta de PHP, una base de datos que no se parece a la del compañero y un servidor web montado a mano que solo entiende quien lo configuró. Las horas que se pierden replicando ese caos no las recupera nadie. Aquí te explico cómo configurar un entorno de desarrollo local con DDEV para Drupal de forma que todo el equipo arranque exactamente el mismo entorno con dos comandos, sin pelearse con Docker a pelo.

No es un tutorial teórico. Vamos a montar un proyecto, importar la base de datos y los ficheros de un sitio que ya existe, conectar Composer y Drush dentro del contenedor, activar Xdebug, capturar el correo de pruebas y dejar la configuración versionada en git para que el siguiente que clone el repo no tenga que preguntarte nada.

Qué es DDEV y por qué deberías importarte

DDEV es una herramienta de código abierto que orquesta contenedores Docker para levantar entornos de desarrollo web. Por debajo usa Docker, pero te abstrae casi por completo de él: no escribes docker-compose.yml a mano ni recuerdas flags imposibles. Defines qué tipo de proyecto tienes (Drupal, en nuestro caso), qué versión de PHP quieres, y DDEV genera toda la infraestructura.

La ventaja real no es ahorrarte un docker run. Es la paridad entre desarrolladores. Cuando la configuración del entorno vive dentro del repositorio, todos trabajáis con la misma versión de PHP, la misma de MariaDB o MySQL, el mismo servidor web. El clásico "pues a mí me funciona" deja de ser una excusa porque ya no hay diferencias que esconder.

Docker sin el dolor de Docker

Mucha gente prueba Docker para desarrollo local, se pelea una semana con volúmenes, permisos y rendimiento, y vuelve a su XAMPP de siempre. DDEV resuelve esa fricción:

• Genera y mantiene los ficheros de Docker Compose por ti.
• Gestiona los certificados HTTPS locales sin que tengas que tocar nada.
• Te da un router que enruta dominios .ddev.site a tu proyecto automáticamente.
• Incluye servicios habituales (base de datos, captura de correo, phpMyAdmin opcional) preconfigurados.

Tú te concentras en el código de Drupal; DDEV se encarga de la fontanería.

DDEV frente a Lando y frente a Docker manual

Las tres opciones acaban en lo mismo: contenedores. La diferencia está en cuánto trabajo te ahorran.

• Docker manual: control total, pero mantienes tú cada fichero de configuración, las redes, los volúmenes y los problemas de rendimiento en macOS. Bien si tienes un caso muy particular; un lastre si solo quieres desarrollar.
• Lando: filosofía parecida a DDEV, también basado en Docker. Es flexible y potente, aunque su configuración por YAML tiende a ser más verbosa y su comunidad en el ecosistema Drupal es algo menor.
• DDEV: es hoy el estándar de facto en el mundo Drupal. La documentación oficial de Drupal lo recomienda, los proveedores de hosting Drupal especializados publican guías para él y la curva de entrada es corta.

Si tu equipo trabaja sobre todo con Drupal, DDEV es la apuesta con menos sorpresas.

Lo único que necesitas instalar antes: Docker

El requisito de fondo es un motor de contenedores. En la práctica:

1. Docker Desktop en Windows o macOS, o bien Docker Engine en Linux. En macOS también funcionan alternativas como OrbStack o Colima, que suelen rendir mejor.
2. DDEV instalado en tu sistema. En macOS se hace con Homebrew; en Linux hay un script oficial; en Windows va de la mano de WSL2.

Comprueba que Docker está vivo antes de seguir. Si docker ps responde sin errores, vas bien. Una vez tengas DDEV, verifica la versión instalada y listo: a partir de aquí casi no vuelves a tocar Docker directamente.

Una nota de hardware: para proyectos Drupal medianos te basta con 8 GB de RAM, aunque con 16 GB irás más holgado si levantas varios proyectos a la vez. El consumo de disco crece con las imágenes Docker, así que de vez en cuando conviene limpiar lo que ya no usas.

Arrancar un proyecto desde cero: ddev config y ddev start

Partimos de una carpeta con tu código (o vacía, si vas a montar un Drupal nuevo). Te sitúas dentro y configuras el proyecto. DDEV te pregunta el tipo y la ubicación del docroot, o lo detecta solo.

ddev config --project-type=drupal11 --docroot=web
ddev start

El primer comando crea una carpeta .ddev/ con toda la configuración. El segundo descarga las imágenes necesarias la primera vez y levanta los contenedores. Cuando termina, te muestra la URL local, algo del estilo https://miproyecto.ddev.site, ya con HTTPS funcionando.

Si arrancas un Drupal totalmente nuevo, puedes pedirle a DDEV que lo instale por ti con Composer dentro del propio contenedor, sin tener PHP ni Composer en tu máquina anfitriona. Ese es uno de los puntos que más gusta: tu sistema operativo queda limpio, todo vive dentro de los contenedores.

Comandos del día a día

Hay un puñado de órdenes que vas a usar constantemente:

• ddev start y ddev stop para encender o apagar el proyecto.
• ddev restart cuando cambias configuración del entorno.
• ddev describe para ver URLs, puertos y servicios activos.
• ddev ssh para entrar en el contenedor web como si fuera un servidor.
• ddev poweroff para parar todos los proyectos y liberar recursos.

Acostúmbrate a ddev describe: es tu panel de control rápido.

Importar la base de datos y los ficheros de un sitio que ya existe

Lo más frecuente no es empezar de cero, sino traerte una copia de producción o de staging para trabajar en local. DDEV lo pone fácil.

Para la base de datos, exportas un volcado del sitio existente (con drush sql:dump o desde el panel de tu hosting) y lo importas:

ddev import-db --file=copia-produccion.sql.gz
ddev import-files --source=copia-de-files.tar.gz

El primer comando carga el SQL en la base de datos del contenedor; admite ficheros comprimidos en .gz directamente. El segundo coloca los ficheros públicos (imágenes, PDFs subidos por usuarios) en la carpeta sites/default/files que corresponda.

Un detalle nada menor si trabajas con datos reales de clientes españoles: cualquier copia de producción que descargas a tu portátil cae bajo el RGPD y la LOPDGDD. Estás manejando datos personales de usuarios fuera del entorno controlado de producción. Lo razonable es anonimizar o sanear esa base de datos antes de moverla (Drupal y Drush ofrecen mecanismos para ello), evitar guardarla en sitios sincronizados con la nube sin cifrar y borrarla cuando termines. No es un tecnicismo: es responsabilidad real sobre datos personales.

Tras importar, casi siempre toca limpiar caché y, si vienes de producción, ajustar configuración local. Eso ya nos lleva a Drush.

Composer y Drush dentro del contenedor, no en tu máquina

Aquí está una de las decisiones que mejor envejecen: no instales Composer ni Drush en tu sistema. Ejecútalos dentro del contenedor, donde la versión de PHP es la correcta y reproducible para todo el equipo.

DDEV envuelve estas herramientas para que las uses con naturalidad:

• ddev composer require drupal/admin_toolbar instala un módulo respetando las versiones de PHP del proyecto.
• ddev composer install reconstruye las dependencias tras clonar el repo.
• ddev drush cr limpia la caché de Drupal.
• ddev drush uli te genera un enlace de acceso de administrador sin recordar contraseñas.
• ddev drush cim o ddev drush cex para importar y exportar la configuración.

La gran ventaja: si un compañero usa PHP 8.1 en su máquina y el proyecto requiere 8.3, da igual, porque Composer se ejecuta con la versión del contenedor. Las dependencias se resuelven siempre igual, lo que evita esos composer.lock que cambian según quién los toca.

Depurar con Xdebug y atrapar el correo con Mailpit

Dos comodidades que convierten DDEV en un entorno serio de trabajo, no solo en un sitio donde el proyecto "se ve".

Xdebug a un comando de distancia

Xdebug viene instalado pero apagado por defecto, porque ralentiza cada petición. Lo enciendes solo cuando lo necesitas:

ddev xdebug on
ddev xdebug off

Con tu IDE escuchando (VS Code, PhpStorm), pones un breakpoint, recargas la página y el código se detiene donde le dijiste. Puedes inspeccionar variables, recorrer la pila de llamadas y entender de verdad qué hace ese hook que heredaste sin documentación. Recuerda apagarlo cuando termines para recuperar velocidad.

Mailpit: ningún correo de pruebas se escapa

Drupal envía correos: registros, recuperaciones de contraseña, notificaciones de pedidos. En local no quieres que esos emails salgan de verdad (y menos a direcciones reales de un volcado de producción). DDEV incluye Mailpit, que captura todo el correo saliente y lo muestra en una bandeja web local.

Accedes a esa bandeja con ddev mailpit (o desde la URL que aparece en ddev describe) y ves cada mensaje tal como saldría, sin riesgo de bombardear a nadie. Para probar flujos de e-commerce o de formularios de contacto, es oro: revisas el HTML del correo, los enlaces y los adjuntos sin tocar un servidor SMTP real.

HTTPS local sin certificados a mano

El acceso por HTTPS local ya lo tienes desde el primer ddev start. DDEV gestiona una autoridad certificadora local de confianza (mkcert), de modo que el navegador no te muestra avisos de seguridad en tu dominio .ddev.site.

Esto importa más de lo que parece. Muchas funcionalidades modernas (service workers, ciertas APIs del navegador, cookies con atributos seguros) solo se comportan igual que en producción si trabajas sobre HTTPS. Desarrollar en http:// y descubrir el problema al desplegar es una pérdida de tiempo evitable. Con DDEV, el local se parece al real también en esto.

Trabajar en equipo: la configuración vive en git

Aquí cierra el círculo y se nota el retorno de haber montado todo esto. La carpeta .ddev/ se versiona en el repositorio. Cuando un compañero clona el proyecto, ya tiene la receta completa del entorno.

El flujo para alguien que se incorpora se reduce a:

git clone git@servidor:cliente/proyecto-drupal.git
cd proyecto-drupal
ddev start
ddev composer install
ddev import-db --file=db-saneada.sql.gz
ddev drush cr

En cinco comandos pasa de no tener nada a un Drupal funcionando idéntico al tuyo. Sin documentación de instalación de tres páginas, sin "instálate esta versión de PHP", sin sorpresas.

Algunas buenas prácticas para que el equipo no tropiece:

1. Versiona .ddev/config.yaml y los servicios personalizados; ignora solo lo que sea local de cada máquina.
2. Fija las versiones de PHP y base de datos en la configuración para que nadie use otra sin querer.
3. Documenta dónde se consiguen los volcados saneados de base de datos, idealmente automatizados.
4. Estandariza comandos propios con ddev hooks o scripts para tareas repetitivas (importar, anonimizar, reconstruir).

El resultado es un onboarding de minutos en lugar de una tarde entera, y un equipo que discute código en vez de discutir entornos. En proyectos con varios desarrolladores rotando, ese ahorro se nota cada semana.

Cuándo merece la pena dar el paso (y cómo te echamos una mano)

DDEV brilla en cuanto hay más de una persona tocando el proyecto, o cuando mantienes varios sitios Drupal con requisitos distintos de PHP. Para un encargo puntual de una tarde quizá te sobra, pero si el proyecto va a vivir meses y pasar por varias manos, montar el entorno bien desde el principio se paga solo.

Si tu equipo todavía pelea con entornos locales inconsistentes, o estás migrando un Drupal antiguo y quieres reproducir producción con fidelidad antes de tocar nada, en Tangram lo hacemos a diario y podemos acompañarte a dejarlo montado sin fricción. A veces la diferencia entre un proyecto que avanza y uno que se atasca está en la base, no en el código.

Un último consejo: empieza pequeño. Coge un proyecto, móntalo con DDEV, importa una base de datos saneada y enseña a un compañero a clonarlo. Cuando veas a alguien arrancar tu entorno entero con cinco comandos, entenderás por qué este estándar se ha impuesto en la comunidad Drupal.