Hosting Node.js i Next.js. Wypychasz kod, strona działa.

1. Node.js necesita algo intermedio entre PaaS y un servidor bare metal

Para las aplicaciones Node.js, un modelo como el de las plataformas PaaS (Platform as a Service) suele ser la primera opción natural: haces git push y la aplicación funciona, sin gestionar el servidor. El problema empieza con la factura: la mayoría de estas plataformas cobran en dólares, con precios que suben rápidamente con el tráfico real de producción, mientras que la infraestructura está físicamente fuera de Polonia.

En Saplo, la aplicación Node.js se instala con un starter (Express) listo para usar, te permite elegir la versión de Node (18, 20 o 22, con 20 por defecto) y queda lista para que sustituyas el código del starter por el tuyo mediante git deploy: un push al repositorio actualiza automáticamente la aplicación en ejecución, sin que tengas que iniciar sesión manualmente en el servidor tras cada cambio.

El manifiesto de la aplicación declara un mínimo de 512 MB de RAM y 3 GB de disco, por lo que incluso Box S (1 GB de RAM) tiene capacidad técnica para alojar una aplicación Node sencilla, aunque para algo más que un prototipo conviene considerar Box M con acceso completo por SSH.

2. Git deploy frente a la subida manual de archivos

Git deploy significa que el repositorio de código es la única fuente de verdad sobre lo que está en producción: un push a la rama configurada desencadena la actualización de la aplicación en Box, sin tener que subir archivos manualmente por FTP ni copiar nada por SSH tras cada cambio en el código.

Para un equipo de varias personas que trabaja en la misma aplicación Node.js, la diferencia es real: cada commit que llega a la rama adecuada se despliega al instante en el servidor, lo que facilita iteraciones rápidas sin pasos de despliegue adicionales aparte del propio git push.

A partir de Box M, el acceso SSH con sudo permite, además, gestionar manualmente el proceso de Node (por ejemplo, reiniciarlo tras cambiar las variables de entorno o instalar paquetes del sistema adicionales necesarios para algunas dependencias de npm), algo que no siempre puede hacerse únicamente con git deploy.

3. ¿Por qué no un VPS clásico?

En un VPS sin nada instalado de Competidor A (1 vCPU, 2 GB de RAM, 20 GB de disco por 11 €/mes netos, precios públicos, estado a fecha de 2026-10-10), desplegar una aplicación Node.js exige instalar manualmente Node, un gestor de procesos (p. ej., PM2), un proxy inverso y un certificado SSL antes de que la aplicación esté disponible públicamente en un dominio con https.

En Saplo, el proxy inverso nginx, el SSL y el gestor de procesos dentro del contenedor se configuran automáticamente al instalar una aplicación desde el catálogo. Así, desde que eliges la versión de Node hasta que la aplicación funciona y está disponible públicamente en tu propio dominio pasan minutos, no horas de configuración manual del servidor.

El coste es comparable al de un VPS con recursos similares, pero no tienes que administrar el sistema operativo ni arriesgarte a que un error en la configuración del firewall o de una actualización del sistema desactive la aplicación por algo ajeno al código de Node.js.

4. Varias aplicaciones Node.js en un solo Box

Sin límite en el número de aplicaciones de un Box, puedes desplegar varios proyectos Node.js independientes (por ejemplo, una API, un panel de administración o un microservicio aparte) al mismo tiempo, cada uno en su propio contenedor LXC y con su propio dominio o subdominio, sin conflictos de puertos entre proyectos.

Para aplicaciones que usan una base de datos, hay módulos de bases de datos independientes (Postgres, MySQL, Redis) que se despliegan como contenedores en tu propio compose, no como complementos de pago. Para una pila típica de Node.js más una base de datos, esta es una combinación natural sin costes adicionales por la base de datos. Añadir una base de datos como otra aplicación en el mismo Box tarda lo mismo que desplegarla desde el catálogo, sin necesitar un contrato aparte con un proveedor externo de bases de datos en la nube.

5. Para quién es ideal

Si desarrollas un backend API sencillo o un microservicio, Box M, con SSH completo y despliegue con Git, te ofrece un entorno de producción rápido sin configurar un servidor desde cero.

Si tu startup desarrolla varios servicios Node.js a la vez (API, panel y worker), Box L te permite desplegarlos todos en una sola cuenta, con contenedores separados y sin facturas independientes por cada microservicio en distintos proveedores de PaaS.

Para quien migra desde una plataforma PaaS extranjera facturada en dólares, Saplo ofrece una experiencia de despliegue similar (git push), pero con facturación en PLN y la infraestructura en un centro de datos europeo.

6. Primer despliegue de una aplicación Node.js en Saplo

Tras desplegar el starter de Express con la versión de Node elegida (18, 20 o 22), conecta un repositorio Git en el panel para que los siguientes cambios en el código lleguen al servidor automáticamente con cada push a la rama configurada.

Sustituye el código del starter por tu propia aplicación y conserva la estructura de puertos y las variables de entorno que exige el motor de Saplo, para que el proxy inverso siga dirigiendo correctamente el tráfico a tu aplicación en el dominio vinculado.

Configuras las variables de entorno (claves de API, cadena de conexión a la base de datos) en el panel de la aplicación, sin guardarlas directamente en el repositorio de código. Es una buena práctica de seguridad, independientemente de dónde esté alojada la aplicación.

Si la aplicación utiliza una base de datos, añade un módulo independiente (Postgres, MySQL o Redis) en el mismo Box y accede a él mediante la dirección interna, sin exponer la base de datos públicamente en Internet.

Consulta los logs de la aplicación por SSH (disponible desde Box M) para detectar rápidamente los errores tras cada despliegue, antes de que sean visibles para los usuarios de la aplicación en producción.

7. Node.js con una arquitectura de microservicios en un solo Box

Varios servicios Node.js independientes (una API, un worker que procesa una cola y un panel de administración) pueden desplegarse como aplicaciones separadas en el mismo Box, cada uno en su propio contenedor, y comunicarse mediante la red interna o una API pública.

Esta separación facilita el despliegue independiente de cada servicio (un git push a un servicio no exige redesplegar los demás) y resulta más cómoda a medida que crece el proyecto que depender de un único proceso monolítico de Node.js que se ocupa de todo a la vez.

Redis como módulo de base de datos independiente en el mismo Box suele servir como cola de tareas o caché entre microservicios, sin necesidad de conectarse a un servicio Redis externo y de pago fuera de la infraestructura de Saplo.

En una arquitectura de microservicios, conviene que consideres Box L o superior, ya que varios procesos Node.js independientes, junto con una base de datos y Redis, consumen más memoria que una sola aplicación sencilla.

8. Monitorización y logs de aplicaciones Node.js en producción

Una aplicación Node.js en producción tarde o temprano se topa con un error que no apareció durante las pruebas locales. Por eso, acceder a los logs del proceso por SSH (disponible desde Box M) es una herramienta de diagnóstico esencial para ver qué estaba pasando realmente en el momento de un fallo o un comportamiento inesperado.

Es una buena práctica registrar de forma estructurada (por ejemplo, en JSON, con un nivel de gravedad y una marca de tiempo) en lugar de usar simples console.log repartidos por el código. Así, después resulta más fácil filtrar los logs por tipo de evento o nivel de error, sobre todo cuando la aplicación crece y genera muchos registros.

El reinicio del proceso tras un fallo (por ejemplo, una excepción no controlada que detenga Node.js) se puede configurar mediante el gestor de procesos que se ejecuta en el contenedor. Así, una incidencia breve no causa una larga interrupción de la disponibilidad antes de que alguien del equipo detecte el problema y actúe manualmente.

Para una aplicación con muchas dependencias npm, conviene comprobar periódicamente las vulnerabilidades conocidas en los paquetes utilizados (herramientas estándar de auditoría de npm), porque las dependencias obsoletas son un vector de ataque habitual contra las aplicaciones Node.js, por bien escrito que esté el código.

Controlar el consumo de RAM del proceso Node.js en tiempo real ayuda a detectar fugas de memoria antes de que provocen la caída de toda la aplicación, un riesgo real en procesos de larga duración (servidores WebSocket, conexiones persistentes) sin monitorización adecuada. Revisar de forma sencilla y regular la tendencia del consumo de memoria, incluso sin herramientas avanzadas de perfilado, permite detectar un problema creciente con antelación suficiente para planificar una corrección antes de que cause una caída en producción.

El panel de Saplo muestra el uso actual de recursos del contenedor y sirve como primer punto de referencia al diagnosticar problemas de rendimiento, antes de recurrir a herramientas de perfilado más detalladas para la propia aplicación Node.js.

9. La comunidad y el ecosistema npm como factor para elegir la pila tecnológica

Node.js tiene uno de los mayores ecosistemas de paquetes (npm) entre los lenguajes y plataformas populares, lo que significa que la mayoría de las necesidades habituales (autenticación, conexión con una base de datos, gestión de archivos) cuentan con bibliotecas listas y probadas, en lugar de escribir esa lógica desde cero para cada proyecto nuevo.

En Saplo, todo este ecosistema está disponible porque la aplicación se ejecuta en un entorno Node.js estándar con acceso al registro de npm, sin ninguna de las restricciones que impone la plataforma de hosting y que se encuentran en algunas plataformas PaaS cerradas con una lista limitada de paquetes compatibles.

La elección entre frameworks populares y Node.js sin framework (Express, Fastify, NestJS) queda en tus manos, porque el starter incluido por Saplo (Express) es un punto de partida que puedes sustituir, no una restricción fija, si tu proyecto necesita otro framework.

Las actualizaciones del propio entorno Node.js, como pasar a una versión LTS más reciente, están disponibles al reconfigurar la aplicación. Así puedes mantenerte al día con el ciclo de lanzamiento de Node.js sin cambiar de proveedor solo porque se modifique la versión de entorno requerida.

Para los equipos que siguen la evolución del ecosistema JavaScript, con nuevas herramientas de compilación y nuevos patrones arquitectónicos, el acceso SSH completo y el entorno Node.js estándar de Saplo no imponen restricciones adicionales frente a lo que puedes hacer en un servidor clásico administrado por ti.

10. Pruebas de aplicaciones Node.js antes de desplegarlas en producción

Antes de cada despliegue en producción, conviene probar la nueva versión de la aplicación en un entorno similar al de producción, por ejemplo, en una aplicación temporal aparte en el mismo Box, antes de que el cambio llegue al dominio final que usan tus clientes.

Las pruebas automatizadas, unitarias y de integración, ejecutadas antes del despliegue, aunque sea en un pipeline CI sencillo a nivel del repositorio, ayudan a detectar regresiones en el código antes de que lleguen al servidor de producción mediante git deploy. Es mucho más barato que corregir un error que los usuarios ya ven.

Para aplicaciones con tráfico crítico en producción, conviene desplegar los cambios fuera de las horas punta. Así reduces el número de usuarios afectados por un posible error breve durante el proceso de actualización del código mediante git deploy.

Volver a la versión anterior del código que funcionaba, revirtiendo el commit y haciendo otro git push, es un mecanismo de seguridad sencillo cuando un despliegue nuevo genera problemas. Además, el backup del Box, disponible desde Box L, protege la base de datos de la aplicación ante problemas más graves.

11. Resumen: Node.js con git deploy como ruta rápida a producción

La combinación de un starter Express listo para usar, la elección de la versión de Node y el despliegue automático mediante git push reduce a minutos el tiempo entre la idea y una aplicación Node.js funcionando y disponible públicamente. Evita las horas que requiere configurar manualmente un servidor, el cortafuegos y el proxy inverso, tareas que en un VPS vacío tendrías que hacer por tu cuenta antes de que la primera línea de código de la aplicación empezara a funcionar en una URL de producción con un certificado SSL activo. Para una persona desarrolladora que prueba una idea nueva, esta diferencia en el tiempo de arranque puede ser decisiva, porque le permite dedicar las primeras horas a la lógica de la aplicación y no a la configuración de la infraestructura que debe alojarla. El mismo argumento es aún más válido cuando se prueban varias ideas en paralelo, ya que el coste de validar cada idea se reduce al tiempo de escribir el código, sin repetir la misma configuración del servidor en cada intento.