VPS para Node.js y Python: servidor y despliegue
Ambos entornos funcionan en un VPS modesto si el proceso es reproducible. Dimensiona concurrencia, memoria, tareas en segundo plano y base; después diseña actualizaciones y rollback.
CPU, RAM y disco
| Carga | Inicio |
|---|---|
| Bot o webhook | 1 vCPU, 1–2 GB |
| API pequeña | 2 vCPU, 2 GB |
| SSR y PostgreSQL | 2–4 vCPU, 4–8 GB |
| Media o jobs | 4+ vCPU, 8+ GB |
Suma sistema, cada proceso, base y margen para desplegar dos versiones. NVMe ayuda a bases y builds; deja 20–30 % de disco libre.
Arquitectura simple
Nginx/Caddy termina TLS y pasa tráfico a un puerto local. Node, Gunicorn o Uvicorn no se publica directamente; base y Redis escuchan loopback o red privada. Systemd o Compose reinicia procesos. Para un único VPS, Kubernetes suele añadir más complejidad que disponibilidad.
- proxy público únicamente en 80/443;
- usuario de sistema separado para la aplicación;
- healthcheck y reinicio supervisado;
- logs estructurados con rotación;
- backup externo de base y uploads;
- alertas enviadas fuera del servidor.
Versiones reproducibles
Usa Node LTS y lock-file; en Python, entorno virtual o contenedor con dependencias fijadas. No instales paquetes de aplicación globalmente como root. El mismo commit debe producir el mismo artefacto en CI y producción.
Despliegue y rollback
- Ejecutar tests y construir fuera de producción.
- Versionar imagen o artefacto, nunca depender de latest.
- Guardar copia antes de migración irreversible.
- Arrancar la nueva versión en otro puerto.
- Comprobar health y rutas críticas.
- Cambiar tráfico y conservar la anterior para volver.
Las migraciones deben permitir durante un tiempo que ambas versiones funcionen.
Base local o gestionada
Una base local reduce coste y latencia, pero comparte CPU, RAM, disco y fallo. Sepárala cuando compita con la app o el RTO lo exija. Nunca abras PostgreSQL, MySQL o Redis a internet; usa VPN/túnel y limita pools de conexiones.
Busca el cuello real
| Síntoma | Primer paso |
|---|---|
| CPU al 100 % | Perfilar y sacar tareas pesadas |
| OOM | Revisar fuga y número de workers |
| I/O wait alto | Analizar base, logs y disco |
| Lento con poca carga | Medir red y APIs externas |
En Node, el trabajo CPU debe ir a workers o cola. En Python, el número de procesos depende de carga y memoria. Asincronía ayuda a esperas, no acelera cálculo automáticamente.
Mide peticiones por segundo, errores, p95/p99, RSS por proceso, swap, I/O wait y tiempo SQL. Una media oculta picos importantes. La prueba debe reproducir autenticación, base y servicios externos, no un endpoint vacío. Ajusta un elemento por vez y conserva resultados comparables.
Si varias aplicaciones viven en el mismo VPS, aplica límites y usuarios distintos. La separación reduce el daño de una fuga, pero no elimina el fallo común del disco o del host. Cuando servicios necesitan escalar o recuperarse por separado, conviene dividirlos.
Seguridad
Firewall para SSH/HTTP/HTTPS, proceso sin root, secrets fuera del código, timeout de integraciones, logs rotados y alertas externas. Consulta la guía completa.
Errores frecuentes
- Servidor de desarrollo en producción.
- Build pesado en el VPS activo.
- Logs sin límite.
- Demasiados workers para la RAM.
- .env incluido en Git.
- Deploy sin rollback.
- Base pública.
Preguntas frecuentes
¿Node o Python?
Elige por ecosistema y equipo; arquitectura y base suelen pesar más.
¿Hace falta Docker?
No, aunque facilita fijar entorno.
¿Varias apps en un VPS?
Sí, con aislamiento y límites; comparten fallo.
¿Cuándo separar?
Cuando servicios compiten o deben escalar y recuperarse de forma independiente.
También: VPS para Docker.