Desplegar una app de Next.js sin una cuenta de Vercel
Next.js está construido para correr en Vercel, lo cual es un valor por defecto razonable hasta que la factura empieza a seguir invocaciones de funciones y requests en el edge en vez de un número fijo que de verdad puedas predecir. El framework en sí no exige eso — un next build seguido de next start es solo un proceso de Node, lo que significa que corre igual en cualquier lugar donde pueda correr un proceso de Node, incluyendo un servidor que sea tuyo.
Qué pasa en realidad en cada push
No hay ninguna configuración específica de Next.js que escribir. Railyard lee package.json, detecta el script build, y para una dependencia de Next.js específicamente corre next build antes de iniciar la app con next start — la misma detección que maneja también Nuxt y SvelteKit, ya que el patrón (el framework declara un paso de build, el framework provee su propio comando de inicio) es compartido entre los tres. El gestor de paquetes — npm, pnpm, yarn o bun — se toma del lockfile que ya esté en el repo, no se adivina.
railyard create my-app https://github.com/me/my-appo pega la misma URL de Git en el panel una vez que GitHub está conectado. De cualquier forma, cada push después del primero reconstruye y redespliega automáticamente — el mismo flujo de git push que popularizó Vercel, corriendo contra infraestructura que no se mide por request.
La única decisión que vale la pena tomar deliberadamente: estática o con servidor
Una app de Next.js que usa output: "export" (o que nunca toca una función exclusiva de servidor — sin API routes, sin server actions, sin ISR) produce una salida puramente estática. Eso es algo significativamente distinto, y más barato de correr, que una app renderizada en servidor, y Railyard lo trata como tal: un export estático se sirve sin ningún proceso de Node detrás, mientras que cualquier cosa que use renderizado del lado del servidor, API routes o server actions mantiene vivo el proceso completo de next start. Saber qué tipo de app se está desplegando en realidad — antes de preocuparse por el costo de hosting — es la pregunta útil para hacerse primero, no una idea de último momento.
Las variables de entorno funcionan igual que en local
process.env.LOQUESEA lee lo que esté definido en Variables, o vía railyard env:set my-app KEY=VALUE desde la CLI — el mismo artefacto de build corre sin cambios desde una rama de preview hasta producción, así que un despliegue de staging nunca corre un bundle distinto al que se publica. Un complemento de base de datos se resuelve a ${{postgres.RAILYARD_PRIVATE_URL}}, delimitado por entorno automáticamente.
El trabajo en segundo plano no necesita una segunda app
Si la app necesita un queue worker junto al proceso web — correos, webhooks, cualquier cosa que no debería bloquear un request — eso es un segundo script en el mismo package.json, no un segundo repo ni un segundo deploy: npm run worker se detecta como su propio tipo de proceso escalable junto a web, compartiendo un solo build.
Referencia completa de Node.js: Documentación de Node.js, Desplegar desde un repositorio.