Desplegar una aplicación Next.js en Fly.io es una alternativa potente frente a Vercel cuando buscas flexibilidad estilo DevOps, control total sobre Docker y un costo predecible cercano a 5 dólares al mes. Aquí verás cómo levantar el proyecto, crear una base de datos Postgres administrada por ti y exponerla a Internet sin perder el camino.

Por qué elegir Fly.io para desplegar Next.js

Fly.io despliega cualquier aplicación que esté dockerizada, sin importar el lenguaje o framework. Solo le interesa que el contenedor sea funcional y que el mapeo de puertos esté correcto.

Esa neutralidad lo vuelve favorito de equipos DevOps que necesitan mover servicios distintos bajo una misma plataforma. Vercel se especializa en React, Vue y frameworks modernos; Fly.io se mueve más cerca de AWS o Azure, con interacción por línea de comandos y despliegues genéricos.

La aplicación que vas a desplegar ronda los 4 a 5 dólares mensuales. Si el tráfico crece, el precio sube, pero la transparencia en el cobro es una de las razones por las que startups y empresas medianas lo adoptan [02:10].

¿Qué es Fly.io? Una plataforma que despliega cualquier aplicación dockerizada, exponiéndola a Internet con configuración mínima de puertos y soporte para bases de datos como Postgres.

Cómo iniciar el proyecto con fly launch

Antes de tocar nada necesitas crear cuenta en Fly.io, registrar tarjeta de crédito e instalar el CLI llamado flyctl (también disponible como fly). Toda la guía paso a paso vive en el archivo README.flydeploy.md en la raíz del proyecto [03:30].

Dentro del proyecto ejecutas fly launch. El CLI detecta que es una aplicación Next.js y propone valores por defecto que conviene revisar:

• Nombre de la aplicación y región (en este caso Bogotá por defecto).
• Puerto, CPU y memoria. Para una app académica basta con 1 GB.
• Extensión de Postgres self-managed, eligiendo entre Supabase o el Postgres propio de Fly.
• Modo development con single node en lugar de la configuración de tres nodos para alta demanda.
• Integraciones disponibles como S3, Redis o Sentry.

Fly genera varios archivos clave: un Dockerfile basado en node slim que detecta pnpm, hace build, limpia dependencias y expone el puerto 3000; un fly.toml con la configuración del servicio; un .dockerignore; y un GitHub Action en .github/workflows/fly-deploy.yml listo para automatizar despliegues desde el repositorio [05:50].

Por qué falla el primer deploy y cómo resolverlo

El primer despliegue falla porque Docker no conoce las variables de entorno locales y la base de datos aún no está accesible desde el mundo externo. La página de Expenses usa Server Components que React intenta pre renderizar durante el build, y ese pre render dispara getExpenses, que depende de SQL y de la variable de entorno con la conexión.

Sin esa variable, el build truena. Necesitas dos cosas: configurar la base de datos como pública y pasarle al contenedor la cadena de conexión correcta.

Cómo exponer Postgres con una IP pública

En el dashboard de Fly aparecen dos aplicaciones: la de Next.js y la de Postgres. Al listar las IPs de la base con flyctl ips list, solo verás una IPv6 privada. Para aceptar conexiones externas necesitas una IP pública.

Fly ofrece dos caminos:

• IP compartida gratuita, que solo funciona en los puertos 80 u 8080.
• IP dedicada IPv4 a unos 2 dólares al mes, necesaria porque Postgres usa el puerto 5432.

Para una base de datos no queda alternativa: compras la IPv4 dedicada. Al volver a listar, ya verás la privada y la pública conviviendo [09:45].

Cómo configurar el fly.toml de Postgres

La app de Postgres no trae fly.toml por defecto. Creas un directorio flydb, entras y descargas el archivo de configuración con el comando que indica la guía oficial.

Lo importante en ese archivo es el mapeo de puertos. Necesitas un bloque TCP con los puertos 5432 y 5433, manejados por el daemon de Postgres de Fly. Además copias el bloque del servicio HTTP desde el fly.toml de la aplicación principal y ajustas para que el puerto público sea el 5432.

Luego ejecutas fly deploy desde la carpeta flydb, pasando el nombre de la app de Postgres y la imagen flyio/postgres-flex con la versión correspondiente, por ejemplo 16.4 [12:20].

Cómo conectar la cadena de Postgres a tu app

Cuando corriste fly launch por primera vez, Fly te entregó la cadena de conexión interna que usa el dominio .flycast:5432. Esa cadena vive en la red interna de Fly. Para conectarte desde fuera, reemplazas .flycast por .fly.dev y conservas usuario, contraseña y hostname.

Una prueba rápida con psql y esa nueva URL confirma el acceso. Desde ahí preparas las dos miniaplicaciones del proyecto:

1. Expense Tracker: dentro de app/expense-tracker corres el SQL del README para crear la base, te conectas a ella y aplicas el esquema.
2. Bookmarks: en app/bookmarks actualizas el .env con la URL remota, ejecutas push del ORM para generar el esquema y corres el script populate con pnpx tsx para sembrar datos.

Al terminar tendrás dos autores y ocho bookmarks cargados, señal de que la conexión remota funciona [18:40].

¿Por qué cambiar .flycast por .fly.dev? Porque .flycast solo resuelve dentro de la red privada de Fly, mientras que .fly.dev es el dominio público que permite conexiones desde tu máquina o desde un build externo.

¿Qué hace fly launch en un proyecto Next.js? Detecta el framework, genera Dockerfile, fly.toml, .dockerignore y un workflow de GitHub Actions, además de ofrecer extensiones como Postgres o Sentry.

Con la base de datos pública y poblada, el siguiente paso es pasarle al Docker las variables de entorno y volver a desplegar la aplicación Next.js. ¿Tú qué servicio prefieres para tus despliegues, Vercel o Fly.io? Cuéntame en los comentarios.