Desplegar Next.js sin VPS: Railway, Render o Droplet

Desplegar Next.js sin VPS: Railway, Render o Droplet

Evita SSH y nginx para un side project Next.js. Compara Railway, Render, Vercel y un VPS, y despliega desde Git tras minificar los assets en el navegador.

18.09.2026
8 min de lectura
Compartir este artículo:
Next.jsRailwayAlojamientoDevOpsTutorial

La app está lista. Falta una URL.

Un next dev local no es producción. Alquilar un VPS implica SSH, un gestor de procesos, TLS y una noche con nginx. Para muchos proyectos personales basta con Git de entrada y HTTPS de salida, que es lo que hace un PaaS al estilo de Heroku. Esta guía compara ese camino (ejemplo seguido: Railway) con Vercel, Render y un Droplet clásico, para alojar una app Next.js sin convertirte en administrador de sistemas.

Una URL HTTPS pública sin administrar un servidor Linux
Despliegues desde Git en lugar de scp y systemd a mano
PaaS, Vercel o VPS, según el trabajo real
Minificar JS y CSS y revisar los Dockerfiles con un linter en el navegador antes de publicar
Alternativas a Railway, que no es el único PaaS

Cuándo el VPS es trabajo de más

Lo que un PaaS quita de verdad

La plataforma construye desde el repositorio, lanza el proceso, gestiona el TLS y reinicia si cae. Sigues siendo responsable de las variables de entorno, la factura y la madurez de la app. Ya no tienes que parchear Ubuntu.

Mejoras

Sin baile de claves SSH para una demo de fin de semana
URL de vista previa por rama en la mayoría de los PaaS
Facturación por uso en lugar de un Droplet olvidado que sigue encendido cada mes
Un proyecto puede agrupar la app Next.js, un worker y una base de datos pequeña
Lo que no quita

Sigue haciendo falta minificar y comprimir los recursos, dejar los secretos fuera de Git y vigilar los Core Web Vitals. Con next start, Next.js ya comprime las respuestas con gzip por defecto; para Brotli o un CDN, consulta nuestra guía sobre gzip y Brotli en el servidor de origen. Un PaaS solo te ahorra escribir el bloque de nginx.

Beneficios SEO

El TTFB sigue dependiendo de la app y la región, no del logo del panel
El JS y el CSS minificados siguen reduciendo la transferencia, y un PaaS no hace tree shaking por ti
Un VPS barato puede ganar a un cold start serverless; mide, no asumas

Publicar una app Next.js en Railway desde Git

Camino mínimo (sin Dockerfile)

Railway construye tu repositorio con Railpack por defecto (Nixpacks también es compatible) y ejecuta el script start de package.json, así que una app Next.js estándar no necesita más configuración. Lo más sencillo es conectar un repositorio de GitHub. El enlace de invitación de arriba te da ahora 20 $ de créditos al registrarte. Es una oferta de Railway, no un cupón de FastMinify, y el importe puede cambiar.

1. Un repositorio que compila por sí solo

Comprueba que package.json tenga los scripts build y start (next build y next start en una app estándar) y que el lockfile esté en el repositorio. No subas secretos en un .env a Git y define las variables en la interfaz de Railway.

2. Crear el proyecto desde GitHub

En Railway, crea un proyecto nuevo desde GitHub y elige el repositorio. El primer despliegue suele fallar por una variable de entorno que falta, y es normal. Añade DATABASE_URL o tus claves de API y vuelve a desplegar.

3. Dominio generado, luego el tuyo

Usa la URL generada *.up.railway.app para comprobar que la app arranca. Después añade tu propio dominio. Railway emite el certificado TLS por ti.

4. Mira la primera factura, no la captura de pantalla

En el momento de escribir esto, el plan Hobby cuesta 5 $ al mes e incluye 5 $ de uso; Pro cuesta 20 $ e incluye 20 $. Por encima de eso, la CPU, la RAM y el tráfico saliente se cobran según el uso, y un servicio detenido no consume ni CPU ni RAM. Lee la página de precios de Railway antes de dejar un proceso Node pesado funcionando día y noche.

Checklist

El script start funciona en local con NODE_ENV=production
Las variables de entorno están definidas en el servicio, no fijadas en el Dockerfile
El proceso escucha la variable PORT que inyecta Railway
No subas .env a Git; comprueba su sintaxis con el validador de .env en línea si hace falta
Cuándo sí hace falta un Dockerfile

Usa un Dockerfile cuando Railpack se equivoque, falte un paquete del sistema o la imagen ya sea tu fuente de verdad. Revísalo en el navegador antes del primer despliegue con el linter de Dockerfile en línea, que aplica un subconjunto de reglas DL al estilo de Hadolint y no construye la imagen. Combínalo con el formateador de Dockerfile.

Fija la imagen base

Evita FROM node:latest (DL3007) y fija un tag concreto de distribución. Railway construye ese Dockerfile si está en la raíz del repositorio.

Escucha PORT

No fijes el puerto 3000 en producción si la plataforma inyecta la variable PORT. Al ejecutar next start, Next.js lee por sí mismo esa variable (3000 es solo el valor por defecto), igual que el servidor server.js del modo standalone, así que pasar -p $PORT es opcional.

Errores que estropean el primer despliegue en un PaaS

Secretos incluidos en la imagen

Una línea ENV AWS_SECRET= en el Dockerfile o un .env subido a Git se filtra en los logs y en las capas de la imagen. Las variables de Railway existen para que la imagen siga siendo genérica.

A tener en cuenta — Comprueba la sintaxis del archivo .env con el validador ENV de FastMinify y no pegues nunca tokens reales en un campo de texto público.

Dar por hecho que los ajustes por defecto de Vercel valen en otro host

Vercel ejecuta Next.js como funciones serverless y se encarga del enrutamiento. En Railway sueles lanzar next start como un proceso Node de larga duración, y output: 'standalone' genera una carpeta de servidor autónoma. Las funciones ligadas a la plataforma Vercel, como Edge Config o las tareas cron, no te siguen a otro hosting.

A tener en cuenta — Haz un build de producción en tu ordenador antes del primer push al PaaS.

Dejar un bundle grande sin minificar

Un PaaS no minifica tu JavaScript de cliente. Next.js lo hace para la app, pero no para un widget.js copiado en public/. Para esos archivos sueltos, usa el minificador de JavaScript en línea.

A tener en cuenta — Mide la transferencia en la URL de Railway y también en localhost.

Antes de lanzar el despliegue

Recursos y configuraciones en el navegador

FastMinify trabaja en la pestaña del navegador, lo que ayuda cuando el repositorio no está clonado en esta máquina. Minifica el CSS suelto, pasa el Dockerfile por el linter y revisa Compose si Docker sigue en local.

Minificar JS/CSS que no pasa por next build
Revisar el Dockerfile con las reglas DL antes de que Railway construya la imagen
Validar docker-compose.yml si mantienes un stack local
Ningún secreto de producción en Git ni en herramientas en línea
Gasto y servicios olvidados

Railway cobra el uso que supera los créditos incluidos en el plan. Un servicio olvidado que ocupa 2 GB de RAM basta para que un proyecto personal acabe en una factura sorpresa. Detén los servicios que no uses o activa Serverless para que un servicio inactivo pase a reposo (el tráfico saliente, como una conexión abierta a una base de datos, lo mantiene despierto). Un Droplet que nunca destruyes es el mismo error en otro panel.

Alerta de gasto en la cuenta Railway
Apaga los entornos de vista previa que ya no uses
No pongas scrapers ni navegadores de CI en el mismo servicio que la app Next.js

PaaS vs Vercel vs VPS

Elige según la tarea, no según la moda

Vercel es el camino que menos esfuerzo exige para un frontend Next.js. Un VPS gana cuando necesitas un kernel a medida, un servidor de correo o SSH. Railway queda en medio: despliegue desde Git, facturación por uso y sitio para un worker y una base de datos junto a la app.

Si necesitas

frontend:Frontend Next.js, vistas previas, Edge
app completa:App + worker + base de datos pequeña, una sola factura
control total:SSH root, nginx propio, correo, GPU

Empieza por

frontend:Vercel (u otra plataforma de frontend equivalente)
app completa:Railway o Render
control total:Droplet DigitalOcean / otro VPS

Railway no es la única respuesta

Mismo problema, otros compromisos

Úsalo como un mapa, no como un ranking. Los precios y los planes gratuitos cambian, así que lee la página del proveedor antes de decidirte.

Vercel

Creado por el equipo de Next.js, con el soporte más directo para App Router, vistas previas y Edge. Encaja peor si necesitas un worker de larga duración o una base de datos clásica en el mismo proyecto, sin proveedores adicionales.

Ventajas:
Ajustes por defecto de Next.js, URL de vista previa, complementos de analítica
El modelo de la documentación de Next.js se aplica directamente
Inconvenientes:
Las apps con varios servicios piden más productos
El gasto en ancho de banda y en invocaciones puede sorprender

Render

Despliegues desde Git, web services, Postgres, workers en segundo plano. Primo cercano de Railway. Quédate con la plataforma donde ya tienes cuenta.

Ventajas:
Combinación conocida de web service y base de datos
Sitios estáticos y tareas cron en la misma cuenta
Inconvenientes:
Los servicios web gratuitos se detienen tras 15 minutos sin tráfico, y la siguiente petición espera un arranque en frío
No es específico de Next.js, así que tú aportas el comando de arranque

Droplet DigitalOcean (o App Platform)

Un Droplet es un VPS: instalas Node, Caddy o nginx y certbot, y la máquina es tuya. App Platform es el PaaS de DigitalOcean. Un Droplet encaja si ya trabajas con SSH y quieres una dirección IPv4 pública propia.

Ventajas:
Precio de VM predecible si la app sigue siendo minúscula
Control total del gestor de procesos y el reverse proxy
Inconvenientes:
Tú actualizas el sistema y depuras el TLS
Excesivo para una demo Next.js de dos rutas

FastMinify antes de la primera URL de producción

Minificar lo que Next.js no ve

El build de producción de Next.js minifica el JavaScript de la app, pero no un widget.js copiado en public/ ni un fragmento de CMS. Para esos archivos sueltos, usa el minificador de JavaScript en línea y el minificador CSS en línea. Cuando un archivo de terceros se vuelve ilegible en producción, el desminificador de JavaScript en línea lo devuelve a un formato legible.

Minificar JS/CSS pegado de un CDN o de un tema antiguo
Hacer legible un archivo minificado de producción cuando no hay source maps
Se ejecuta en el navegador, así que el host no ve lo que pegas
Docker y .env junto a la app

Si Railway u otro host construye un Dockerfile, revísalo antes. Si todavía usas Compose en local, puedes validar Docker Compose en línea. Busca claves duplicadas en tus archivos .env antes de copiar los nombres en la interfaz del PaaS. Todas estas herramientas están en el hub de herramientas DevOps en línea.

Revisión de Dockerfile al estilo de Hadolint (subconjunto de reglas DL, sin docker build)
Comprobación de la estructura de Compose, no de la especificación completa
Comprueba la sintaxis del .env, las claves duplicadas y los nombres de clave que parecen secretos; no es un detector de secretos

Publica la URL, deja el VPS para más adelante

Si lo que tienes es un proyecto personal con Next.js y quizá un worker, un PaaS cuesta menos noches que un Droplet. Railway es el ejemplo que hemos seguido (enlace de afiliado). Vercel sigue siendo la opción por defecto si solo necesitas el frontend Next.js, y un VPS sigue siendo la opción correcta cuando quieres SSH. En cualquier caso, minifica los archivos sueltos y revisa los Dockerfiles en FastMinify: ese paso es gratis y local.

Prepara los assets y despliega donde hayas elegido

Vercel para un frontend Next.js a solas, Railway o Render para app, worker y base de datos, un VPS para SSH
Nunca secretos en Git: para eso está la interfaz de variables del PaaS
Minificar lo que quede en public/, porque Next.js ya minifica el bundle de la app
Fijar la versión de las imágenes base de Docker si entregas un Dockerfile
Leer la página de precios del host, porque los créditos y la facturación cambian
Compartir este artículo
Compartir este artículo: