Cómo ejecutamos Next.js en producción en un VPS
La configuración exacta que usamos para alojar nuestros propios productos Next.js — gestores de procesos, reverse proxy, despliegues sin caídas y los errores que cometimos hasta llegar aquí.
Por Anested Engineering
Cada producto de Anested — incluido este sitio web — corre sobre la misma infraestructura de Anested Clouds que vendemos a nuestros clientes. Esa restricción nos mantiene honestos. Si un patrón de despliegue es demasiado frágil para nuestros propios productos, no tiene derecho a ser el predeterminado en el VPS de nadie más.
Nuestro stack de Next.js en producción es deliberadamente aburrido, y lo decimos como un cumplido. Un VPS con una versión LTS de Node.js fijada, un gestor de procesos que reinicia la aplicación ante fallos y un reverse proxy terminando TLS al frente. Sin clúster de orquestación, sin service mesh, sin contenedores sidecar. Ninguna de nuestras cargas de trabajo se ha ganado esa complejidad todavía, y fingir lo contrario solo significaría más cosas rompiéndose a las dos de la madrugada.
El despliegue sin caídas es el único lugar donde invertimos esfuerzo real de ingeniería. Cada versión se construye en un directorio separado mientras la antigua sigue sirviendo tráfico. Ejecutamos comprobaciones de salud contra el nuevo build en un puerto interno, y solo cuando responde correctamente cambiamos el upstream del reverse proxy. Si algo se ve mal diez minutos después, la vuelta atrás es un cambio de symlink y una recarga — no un redespliegue desesperado.
El mayor error que cometimos al principio fue tratar los logs como algo secundario. Cuando algo se rompía, entrábamos por SSH a los servidores a rebuscar entre archivos dispersos. Hoy cada aplicación envía logs estructurados a un almacén central desde el primer día, y el ingeniero de guardia puede responder a la pregunta '¿qué cambió?' en menos de un minuto. Ese solo hábito ha reducido nuestro tiempo de resolución de incidentes más que cualquier compra de herramientas.
El caché merece mención porque Next.js te da muchísimas capas — páginas estáticas en build, revalidación incremental, cabeceras de CDN. Nuestra regla es cachear agresivamente en el borde para tráfico anónimo y nunca para páginas autenticadas. Las reglas aburridas y explícitas ganan a las ingeniosas que no puedes explicar durante una caída.
Si quieres esta misma configuración sin construirla tú mismo, eso es literalmente lo que vende Anested Clouds. Los patrones descritos en este artículo son los predeterminados de cada nuevo VPS que aprovisionamos — porque nuestra propia empresa corre sobre ellos.
¿Necesitas ayuda con algo de este artículo?
Nuestros ingenieros responden directamente — hosting, bases de datos, código o cualquier tema de este artículo.