Desplegar una aplicación Next.js en Fly.io con Docker requiere configurar variables de entorno en dos lugares distintos: en el contenedor Docker durante el build y en Fly.io para el tiempo de ejecución. Aquí aprendes cómo cerrar ese flujo de despliegue, conectar tu base de datos y validar que todo corre en producción.

¿Por qué necesitas configurar variables de entorno en Docker y en Fly.io?

La respuesta corta es que cada uno opera en un momento distinto del ciclo de vida de tu aplicación.

Fly.io maneja sus secretos desde el dashboard, en la sección de secrets. El detalle clave es que esos secretos solo están disponibles en tiempo de ejecución, no durante el build. Cuando Docker construye tu imagen de forma local antes de subirla, no puede ver esos valores a menos que se los pases explícitamente.

Por eso necesitas hacer ambas cosas: cargar los secretos en Fly.io para cuando la app ya esté corriendo, y entregárselos a Docker como argumentos de build para que la imagen quede lista.

¿Qué diferencia hay entre tiempo de build y tiempo de ejecución? El build time es cuando Docker compila tu imagen con todo el código y dependencias. El runtime es cuando esa imagen ya está corriendo como contenedor en Fly.io. Cada momento necesita sus propias variables.

¿Cómo paso variables de entorno al Dockerfile correctamente?

El patrón estándar combina dos instrucciones de Docker: ARG y ENV. Primero declaras los argumentos que vas a recibir desde afuera, y luego los conviertes en variables de entorno dentro del contenedor.

La estructura queda así:

• Declaras cada ARG con un valor por defecto vacío.
• Defines cada ENV igualándola al ARG correspondiente.
• Pasas los valores reales al momento de hacer el build.

Entre las variables típicas que vas a manejar están el Postgres endpoint, el session secret, el SD key y el Sentry DSN. Cada una entra como argumento y se transforma en variable de entorno disponible para tu app.

¿Cuál es la forma profesional de pasar estos secretos?

La forma profesional es a través de CI, no quemando valores en el archivo. Fly.io ya genera un archivo de GitHub Actions cuando configuras el despliegue, y ahí es donde encajan tus secretos.

El flujo profesional funciona en cadena:

1. Guardas los secretos en GitHub, en la sección de secrets del repositorio.
2. GitHub Actions los lee y los inyecta al workflow con la sintaxis de doble llave.
3. El workflow se los pasa al fly deploy como argumentos de build.
4. Docker los recibe y arma la imagen lista para producción.

Así, cada push a tu repositorio dispara un despliegue seguro sin exponer credenciales en el código.

¿Cómo hago el deploy final a Fly.io desde la raíz del proyecto?

Una vez configurado el Dockerfile con sus ARG y ENV, y cargados los secretos en Fly.io, el despliegue se ejecuta con un solo comando desde la raíz del proyecto: fly deploy.

El proceso completo toma entre cinco y 10 minutos. Cuando termina, Fly.io te devuelve la URL pública donde quedó disponible tu aplicación. Al abrirla con las dev tools puedes verificar que no hay errores en producción.

La prueba real es interactuar con la base de datos. Si entras a una sección como Expense Tracker, guardas un registro nuevo, recargas la página y el dato persiste, significa que el servidor está corriendo correctamente y conectándose al Postgres configurado en Fly.io. Los datos precargados que aparezcan en otras secciones, como Bookmarks, terminan de validar la conexión.

¿Qué hago si Fly.io no encuentra mis variables después del deploy? Revisa que estén cargadas tanto en el dashboard de Fly.io como pasadas al Dockerfile vía ARG y ENV. Si solo las pones en uno de los dos lugares, la app falla en build o en runtime.

¿Conviene desplegar Next.js en un VPS propio en lugar de Fly.io?

Desplegar en un VPS o bare metal es una opción real, pero implica asumir mucho más trabajo de DevOps. En los recursos de la clase encuentras un repositorio creado por un colaborador importante de Next.js que muestra cómo hacerlo paso a paso.

Ese flujo también usa Docker con un servicio para la base de datos y otro para la app, pero suma capas de configuración:

• Creación de usuarios del sistema y permisos.
• Asignación de memoria RAM.
• Configuración de memoria swap o de intercambio.
• Aseguramiento del servidor para producción.

La pregunta honesta es si vale la pena. Que algo se pueda hacer no significa que se deba hacer. El esfuerzo inicial es alto, y mantener, actualizar y asegurar el servidor a lo largo del tiempo tiene un costo importante para proyectos y organizaciones.

Servicios como Vercel y Fly.io ofrecen un punto intermedio: Vercel automatiza casi todo, mientras Fly.io te deja manipular puertos y detalles de bajo nivel sin perder la facilidad de un managed service. Ese balance es lo que los hace atractivos frente a un servidor propio.

Me encantaría ver en los comentarios lo que has desplegado con Next.js y Fly.io, así que comparte tu URL y cuéntame qué construiste.