Tu app funciona en tu máquina. Y ahí se queda.
La creaste con IA — Antigravity, Codex cloud o VS Code — y corre perfecto en tu computadora. Pero no sabés cómo empaquetarla, conectarla a una base de datos ni prepararla para un VPS sin que se rompa.
Este kit te lleva de la app local a una aplicación corriendo en Docker, conectada a MySQL, con red interna y volumen persistente. Al terminar vas a poder eliminar y recrear los contenedores sin perder un solo dato.
¿Todavía no tenés la app? Creala con IA en 3 prompts
Criterio: app mínima, un solo puerto, una sola tabla. Un CRUD simple de tareas alcanza. Copiá cada prompt en tu herramienta favorita.
Prompt 1 — App base
Genera la aplicación mínima en Node.js con Express.
Sos un desarrollador senior. Generame una aplicación web mínima en Node.js con Express que tenga: un endpoint GET / que muestre una lista de tareas guardadas en memoria, un endpoint POST /tareas para agregar tareas, y un archivo package.json con el script start. Sin frameworks pesados, sin base de datos todavía. Incluí un README.md con los comandos para correrla.
Prompt 2 — Empaquetado
Dockerfile multi-etapa y .dockerignore explicados.
Ahora agregale a este proyecto un Dockerfile multi-etapa optimizado para producción y un .dockerignore. Explicame cada línea del Dockerfile.
Prompt 3 — Base de datos
MySQL con variable de entorno, healthcheck y volumen.
Modificá la app para que las tareas se guarden en MySQL en lugar de memoria. Usá una variable de entorno MYSQL_HOST para la conexión y dotenv para la configuración. Dame también el docker-compose.yml con dos servicios: app y mysql, en una red interna, con un volumen para los datos de MySQL y un healthcheck para que la app espere a que la base esté lista.
El mapa del sistema que vas a construir
Cinco piezas. La última es la que protege tus datos.
1. Aplicación
Tu código, el que creaste con IA
2. Contenedor
La app empaquetada con todo lo que necesita para correr
3. Red interna
Red privada: app y MySQL se ven entre sí, sin exponerse a internet
4. MySQL
La base de datos, en su propio contenedor
5. Volumen persistenteLA PIEZA CLAVE
El disco real del servidor. Se borra el contenedor, el volumen queda
Qué vas a tener al finalizar
- docker compose up -d levanta la app y MySQL juntos
- La app responde en http://localhost:3000 (o el puerto que elijas)
- Las tareas guardadas sobreviven a docker compose down y a borrar los contenedores
- El .env existe y está fuera de git
- Dominás los comandos básicos: ver logs, entrar a un contenedor, reiniciar servicios
El paso a paso, resumido
01 · Instalá Docker
Windows/Mac: Docker Desktop (incluye Compose). Linux: Docker Engine + plugin Compose. Verificá con docker --version y docker compose version.
02 · Estructura del proyecto
miapp/ con Dockerfile, docker-compose.yml, .env, .dockerignore y el código en src/.
03 · Dockerfile multi-etapa
Etapa 1 instala dependencias, etapa 2 arma la imagen final chica sin herramientas de desarrollo ni cachés. Cada capa aprovecha caché.
04 · docker-compose.yml
Dos servicios (app + mysql), red interna declarada, volumen db_data montado en /var/lib/mysql, credenciales desde .env y healthcheck para que la app espere a MySQL.
05 · Levantá y verificá
docker compose up -d --build, mirá los logs con docker compose logs -f app y agregá 2 o 3 tareas de prueba en el navegador.
La prueba de fuego
El corazón del kit. Si esto funciona, entendiste Docker:
- 1. Agregá tareas en la app
- 2.
docker compose down— baja TODO - 3.
docker compose up -d— levanta de nuevo - 4. Abrí la app: las tareas siguen ahí
¿Por qué? Los datos no viven en el contenedor: viven en el volumen db_data del disco del host. El contenedor es descartable; el volumen no.
Errores comunes y cómo salir
“Puerto 3000 ocupado”
Otro proceso lo usa. Cambiá el puerto en compose (ej. "3001:3000") o liberalo.
La app arranca antes que MySQL y se cae
Falta el healthcheck en mysql y depends_on con condition: service_healthy en la app.
“Access denied” en MySQL
Credenciales hardcodeadas o .env desactualizado. Toda credencial vive en .env.
Los datos no persisten
Revisá que el volumen esté declarado en el servicio mysql Y en la sección volumes. Ojo: si corriste down -v, los datos se fueron.
La imagen pesa gigas o no corre igual que en local
Revisá el .dockerignore (node_modules, .git y .env NO van adentro) y que existan los lockfiles.
Qué NO hacer
- Guardar datos o archivos importantes dentro del contenedor (se pierden al recrearlo)
- Subir el .env a git, jamás
- Usar latest en producción: pinear versiones (mysql:8.0, node:20-alpine)
- Exponer el puerto 3306 de MySQL a internet
- Correr docker compose down -v en producción sin backup
Del Docker local a producción
Camino A — VPS
Instalá Docker en el VPS, cloná el repo, creá el .env en el servidor y docker compose up -d. Frente web con Nginx o Caddy (HTTPS automático).
Ideal cuando querés control total, varias apps en el mismo servidor o bases de datos propias. Conecta con el kit de Despliegue (A7).
Camino B — Vercel
Aclaración honesta: Vercel no usa tu Docker. Tiene su propio build y runtime serverless. La app dockerizada local te sirve igual como entorno idéntico para probar.
Regla práctica: ¿control y base de datos propia? VPS. ¿Publicar ya sin administrar servidor? Vercel + base de datos administrada.
Fuentes oficiales
Llevate el kit completo en PDF
Dejá tu email y descargá el paso a paso completo: los 3 prompts, el Dockerfile y el docker-compose explicados línea por línea, la prueba de fuego y los comandos de supervivencia.
Accedé al material exclusivo
Ingresá con tu cuenta para descargar la guía en PDF en 1 clic.