Cómo usar Docker para entornos de desarrollo. Configurar Docker para desarrollo local resuelve uno de los problemas más frecuentes en equipos de software: que el entorno funcione diferente en cada ordenador.
Con Docker, el repositorio incluye toda la configuración del entorno. Cualquier persona del equipo ejecuta docker compose up y tiene la aplicación funcionando en minutos, con la misma versión de Node, Python, PostgreSQL o Redis que el resto del equipo, sin instalar nada en su sistema operativo.
Según el Stack Overflow Developer Survey 2025, Docker es la herramienta más usada en entornos profesionales de desarrollo. Y uno de sus usos más extendidos, aunque menos documentado en profundidad, es precisamente como entorno de desarrollo local con hot reload, debugging remoto y separación clara entre lo que va a desarrollo y lo que va a producción.
Esta guía cubre la configuración completa: desde el Dockerfile de desarrollo hasta Docker Compose Watch, variables de entorno, debugging con VS Code y las diferencias que debe haber entre tu entorno de desarrollo y el de producción.
Si todavía no tienes claro qué es Docker y cómo funciona su arquitectura, el artículo sobre qué es Docker explica los conceptos fundamentales antes de entrar en la configuración del entorno.
Por qué usar Docker para desarrollo local
La alternativa a Docker en desarrollo es instalar directamente en el sistema operativo del host todo lo que necesita la aplicación: el runtime, la base de datos, el servidor de caché, las herramientas de build. Eso funciona bien para proyectos simples y para un solo desarrollador.
Los problemas aparecen cuando el equipo crece o cuando trabajas en más de un proyecto a la vez.
- Conflictos de versiones. Proyecto A necesita Node 18, Proyecto B necesita Node 20. Sin Docker, gestionar eso requiere herramientas como nvm o pyenv. Con Docker, cada proyecto tiene su propio contenedor con su propia versión.
- El entorno del nuevo miembro del equipo. Sin Docker, configurar el entorno de desarrollo puede llevar medio día o más. Con Docker, es
git clone+docker compose up. - Paridad dev/producción. Con Docker, el entorno de desarrollo usa exactamente las mismas versiones de las dependencias que producción. Los bugs que solo ocurren «en producción» desaparecen.
- Limpieza del sistema operativo. Nada de instalar PostgreSQL, Redis o MongoDB en el host. Todo corre en contenedores que se pueden eliminar cuando no se necesitan.
El Dockerfile de desarrollo
🔴 ¿Quieres entrar de lleno al mundo DevOps & Cloud Computing? 🔴
Descubre el DevOps & Cloud Computing Full Stack Bootcamp de KeepCoding. La formación más completa del mercado y con empleabilidad garantizada
👉 Prueba gratis el Bootcamp en DevOps & Cloud Computing por una semanaEl Dockerfile de desarrollo es diferente al de producción. Incluye herramientas que en producción no necesitas: los tests, las herramientas de debugging, los watchers de hot reload y las dependencias de desarrollo.
Un Dockerfile básico de desarrollo para una aplicación Node.js:
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 3000
CMD ["npm", "run", "dev"]La diferencia clave respecto al Dockerfile de producción está en el comando final: en lugar de node server.js, usa npm run dev, que en el package.json está configurado para ejecutar el servidor con nodemon u otro watcher de hot reload.
Para proyectos Python con FastAPI o Django:
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000", "--reload"]El flag --reload en uvicorn activa el hot reload nativo de FastAPI en desarrollo. Para una guía completa del Dockerfile con todas sus instrucciones, el artículo sobre qué es un Dockerfile cubre el tema en profundidad.
Docker Compose para entornos multi-servicio
La mayoría de aplicaciones reales no son un solo servicio. Necesitan una base de datos, un servidor de caché, quizá una cola de mensajes. Docker Compose permite definir y orquestar todos esos servicios en un único archivo YAML.
Un docker-compose.dev.yml típico para una aplicación con Node.js, PostgreSQL y Redis:
services:
app:
build:
context: .
dockerfile: Dockerfile.dev
ports:
- "3000:3000"
volumes:
- .:/app
- /app/node_modules
environment:
- NODE_ENV=development
- DATABASE_URL=postgresql://user:password@db:5432/myapp
- REDIS_URL=redis://cache:6379
depends_on:
- db
- cache
db:
image: postgres:16-alpine
environment:
POSTGRES_USER: user
POSTGRES_PASSWORD: password
POSTGRES_DB: myapp
volumes:
- postgres_data:/var/lib/postgresql/data
ports:
- "5432:5432"
cache:
image: redis:7-alpine
ports:
- "6379:6379"
volumes:
postgres_data:Con este archivo, un solo docker compose -f docker-compose.dev.yml up levanta la aplicación, la base de datos y el servidor de caché, todos conectados entre sí en la misma red Docker. Para una guía completa de Docker Compose, el artículo sobre qué es Docker Compose lo cubre con más ejemplos.
Volúmenes y hot reload
El volumen es lo que hace que Docker sea práctico para desarrollo. Sin volumen, cada cambio en el código requeriría reconstruir la imagen y reiniciar el contenedor. Con un bind mount, los cambios en el código local se reflejan instantáneamente dentro del contenedor.
En el ejemplo anterior, la línea - .:/app monta el directorio actual del host en /app dentro del contenedor. Cualquier archivo que modifiques en tu editor se modifica simultáneamente en el sistema de archivos del contenedor.
La línea - /app/node_modules es un volumen anónimo que protege el directorio node_modules dentro del contenedor. Sin esta línea, el bind mount del directorio raíz sobreescribiría el node_modules que Docker instaló durante el build con el (posiblemente vacío) node_modules del host.
Docker Compose Watch: hot reload nativo
Docker Compose v2.22+ (incluido en Docker Desktop 4.24+) introduce la funcionalidad watch como alternativa más robusta al bind mount + nodemon. En lugar de montar todo el directorio, watch define reglas específicas sobre qué archivos sincronizar y cuándo reconstruir el contenedor.
services:
app:
build: .
develop:
watch:
- action: sync
path: ./src
target: /app/src
- action: rebuild
path: package.jsonCon esta configuración, los cambios en el directorio src se sincronizan directamente (sin reconstruir la imagen). Un cambio en package.json dispara una reconstrucción automática. Se activa con docker compose watch.
Variables de entorno
Las variables de entorno son la forma correcta de configurar diferencias entre entornos (development, staging, production) sin cambiar el código. Docker Compose las gestiona de dos formas.
Opción 1: directamente en el docker-compose.yml con la clave environment. Válido para valores no sensibles como NODE_ENV=development.
Opción 2: archivo .env, referenciado con env_file: .env en el servicio. Es la forma correcta para credenciales, API keys y cualquier valor sensible.
# .env (nunca subir al repositorio)
POSTGRES_PASSWORD=mipasswordseguro
API_KEY=abc123secreto
JWT_SECRET=supersecretkey# .gitignore
.envDocumenta las variables necesarias en un archivo .env.example con valores de ejemplo (no reales) que sí va al repositorio. Cualquier nuevo miembro del equipo lo copia, rellena los valores reales y tiene el entorno funcionando.
Debugging remoto con VS Code
Una objeción frecuente a usar Docker para desarrollo es que dificulta el debugging. En la práctica, con la extensión correcta, la experiencia es idéntica a debuggear código local.
Dev Containers de VS Code es la forma más directa. La extensión permite abrir el proyecto directamente dentro del contenedor: VS Code se conecta al contenedor, instala sus extensiones dentro y ejecuta el depurador en el mismo entorno que la aplicación. La experiencia de debugging es idéntica a la de un proyecto local.
Para configurar Dev Containers, añade un directorio .devcontainer al proyecto con un archivo devcontainer.json:
{
"name": "Mi Proyecto",
"dockerComposeFile": "../docker-compose.dev.yml",
"service": "app",
"workspaceFolder": "/app",
"extensions": [
"dbaeumer.vscode-eslint",
"esbenp.prettier-vscode"
]
}Para debugging de Node.js sin Dev Containers, expón el puerto de debugging en el Dockerfile (EXPOSE 9229), pasa el flag --inspect=0.0.0.0:9229 al arrancar Node y configura un launch.json en VS Code para conectarse al puerto remoto.
Diferencias entre entorno de desarrollo y producción
Es uno de los errores más comunes al empezar con Docker: usar el mismo Dockerfile para desarrollo y producción. El entorno de desarrollo necesita herramientas que en producción son innecesarias y aumentan el tamaño de la imagen.
| Aspecto | Desarrollo | Producción |
|---|---|---|
| Dependencias | devDependencies incluidas | Solo dependencias de producción |
| Código fuente | Montado como volumen (editable) | Copiado en la imagen (inmutable) |
| Hot reload | Activado (nodemon, –reload) | Desactivado |
| Debugging | Puerto de debug expuesto | Sin herramientas de debug |
| Variables de entorno | Archivo .env local | Secrets del proveedor cloud |
| Multi-stage build | No necesario | Recomendado para minimizar imagen |
La forma más limpia de gestionar estas diferencias es mantener dos archivos separados: Dockerfile.dev y Dockerfile (producción), junto con docker-compose.dev.yml y docker-compose.yml. El archivo de producción usa multi-stage builds para generar una imagen final lo más pequeña posible.
Buenas prácticas para equipos
Lo que hemos visto en equipos que adoptan Docker para desarrollo de forma exitosa es que la clave no está en la configuración técnica sino en la disciplina de equipo para mantenerla.
- El Dockerfile y el docker-compose.dev.yml van al repositorio. Son parte del proyecto, no configuración personal de cada desarrollador.
- El .env nunca va al repositorio. Usar siempre .env.example para documentar qué variables se necesitan.
- Especifica versiones exactas de las imágenes.
postgres:16-alpineen lugar depostgres:latest. Las versioneslatestpueden cambiar y romper el entorno sin previo aviso. - Documenta el flujo de setup en el README. Tres líneas:
cp .env.example .env, rellenar valores,docker compose up. Eso es todo lo que el nuevo miembro del equipo debe necesitar. - Limpia regularmente los recursos no utilizados.
docker system pruneelimina imágenes, contenedores y volúmenes huérfanos que acumulan espacio en disco con el tiempo.
Esther llegó al Bootcamp DevOps de KeepCoding desde la psicología y los recursos humanos, sin experiencia técnica previa. Hoy trabaja como DevOps Engineer en un proyecto bancario de gran escala donde usa Docker, Kubernetes y Jenkins a diario en producción.
Lo que más la sorprendió no fue la complejidad técnica, sino que en pocos meses de experiencia real con herramientas de producción como Docker recibía más ofertas en LinkedIn que en toda su etapa anterior combinada.
Cómo aprender Docker para entornos de desarrollo profesionales
Configurar Docker para desarrollo local es algo que cualquier desarrollador puede hacer siguiendo una guía en su primera tarde. Lo que tarda más en llegar es el criterio para diseñar una configuración que escale bien con el equipo: saber cuándo usar bind mounts y cuándo volúmenes nombrados, cómo estructurar los Dockerfiles para que el tiempo de build sea mínimo, cómo integrar Docker en el pipeline CI/CD para que el entorno de desarrollo y el de integración sean idénticos.
Ese criterio se construye trabajando en proyectos reales donde las decisiones de configuración tienen consecuencias directas en la productividad del equipo.
Para aprender Docker en proyectos reales con profesores en activo, el DevOps y Cloud Computing Full Stack Bootcamp de KeepCoding cubre el recorrido completo en 6 meses.
Conclusión
Usar Docker para entornos de desarrollo elimina una categoría entera de problemas: los conflictos de versiones, los entornos que funcionan en local pero no en otro ordenador y los setups que tardan media jornada en configurarse. DevOps y Cloud Computing Full Stack Bootcamp de KeepCoding.
La inversión para llegar a tener un entorno Docker bien configurado es de pocas horas. El retorno en productividad del equipo es permanente. Y la paridad entre el entorno de desarrollo y el de producción que Docker garantiza reduce una de las fuentes más frecuentes de bugs difíciles de reproducir.
La referencia oficial más actualizada sobre Docker Compose Watch y las nuevas funcionalidades de desarrollo está en docs.docker.com/compose/how-tos/file-watch/.
