- Este artículo es una checklist que documenta paso a paso y en detalle el proceso de self-hosting en un VPS usando Hetzner y Coolify
- Se recomienda Hetzner por su baja latencia en Europa, su excelente relación precio-rendimiento y sus planes transparentes
- Incluye temas frecuentes en la práctica como configuración inicial del servidor, seguridad SSH, firewall y ajustes de actualizaciones automáticas
- Explica en detalle cómo preparar un entorno de producción, monitoreo, respaldos y solución de problemas para desplegar aplicaciones Node.js de forma segura
- Es una guía práctica para desarrollar habilidades de DevOps y ganar capacidad de administración libre mientras montas tu propio servidor
Checklist de preparación para configurar un VPS
- En la sección para elegir un proveedor de VPS, se menciona a Hetzner como una opción recomendada por su precio/rendimiento
- Se necesita elegir una configuración con al menos 1 GB de RAM y 20 GB de almacenamiento, además de registrar la dirección IP del servidor y la información de la cuenta root
- Prepara un cliente SSH en tu máquina local y usa un generador de contraseñas seguras
Por qué elegir este proveedor de VPS
- Hetzner Cloud es barato, rápido y confiable en la región europea
- Alternativas: DigitalOcean (excelente onboarding y documentación, pero más caro), AWS Lightsail (dependencia de AWS y mayor dificultad para principiantes), Linode (estable, pero menos competitivo en precio), Render/Fly.io (cómodos como PaaS, pero con más costos y restricciones)
- Hetzner cuesta entre 2 y 3 veces menos para especificaciones equivalentes, no tiene cobros opacos y destaca por sus centros de datos en Europa
Checklist de configuración inicial del servidor
Primer acceso y actualización del sistema
- Actualizar la lista de paquetes y realizar la actualización del sistema
- Se proporcionan comandos para verificar información del sistema (por ejemplo: uname -a, cat /etc/os-release)
Configuración de seguridad de la cuenta root
- Es necesario definir una contraseña compleja y guardarla de forma segura
- Crear una cuenta de usuario única en lugar de usar nombres convencionales como 'admin' o 'user'
- Otorgar permisos sudo a la nueva cuenta y verificar que se hayan aplicado correctamente
Configuración de autenticación con claves SSH
- Generar en la máquina local un par de claves Ed25519 (recomendado) o RSA
- Agregar la clave pública a
.ssh/authorized_keys del servidor y configurar los permisos
- Verificar que el inicio de sesión por clave SSH funcione correctamente (es decir, que se conecte sin pedir contraseña)
- Desactivar la autenticación por contraseña y, si hace falta, revisar también archivos separados de cloud-init
- Reiniciar el demonio SSH y comprobar que funcione con normalidad
- Confirmar que el inicio de sesión root esté deshabilitado para bloquear el acceso remoto como root
Checklist de configuración del firewall
Configuración básica de UFW
- Denegar por defecto todas las conexiones entrantes y permitir las salientes
- Permitir los puertos de SSH, HTTP (80) y HTTPS (443), y comprobar que UFW se haya aplicado correctamente
- Opcional: restringir el puerto SSH a una IP específica y cambiar el número de puerto para agregar una capa extra de protección
Checklist de configuración de actualizaciones automáticas
Configuración de Unattended Upgrades
- Instalar los paquetes unattended-upgrades y apt-listchanges, y elegir la opción de aceptar el uso básico
- Se puede descomentar la sección de actualizaciones de seguridad, además de configurar notificaciones por correo y reinicio automático
- Probar el funcionamiento de las actualizaciones automáticas y revisar su estado
Checklist de despliegue de aplicaciones en producción
Configuración del entorno de Node.js
- Instalar Node.js LTS y verificar la versión
- Subir los archivos de la aplicación al servidor y dejarla lista para producción con la instalación de dependencias
Uso del administrador de procesos PM2
- Ejecutar la app con PM2 en modo production, con opción de clustering
- Configurar el inicio automático al arrancar el sistema y usar comandos de reinicio/monitoreo
Configuración de Reverse Proxy con Nginx
- Crear el archivo de configuración del sitio en Nginx y aplicar proxy_pass
- Activar el sitio y reiniciar Nginx
Checklist de configuración de certificados SSL
Let's Encrypt y Certbot
- Instalar certbot y python3-certbot-nginx para la emisión automática de certificados SSL basada en dominio
- Configurar opciones de renovación automática y probar la validez del certificado
Checklist de monitoreo y mantenimiento
Métodos básicos de monitoreo
- Instalar herramientas de verificación de recursos del sistema como htop e iotop
- Monitorear en tiempo real syslog y auth.log, y configurar la política de rotación de logs (logrotate)
Estrategia de respaldos
- Crear un script de respaldo de la aplicación y la base de datos usando tar
- Ejecutar respaldos periódicos según una programación en crontab
Checklist de solución de problemas
Problemas de conexión SSH
- Revisar la configuración del firewall, el estado del servicio SSH, los logs de autenticación y la red
Errores relacionados con permisos
- Verificar permisos de archivos/carpetas, grupos y configuración de sudo
Servicio que no arranca
- Usar systemctl y journalctl para revisar estado y logs, y validar la sintaxis de los archivos de configuración
Uso excesivo de recursos
- Analizar procesos, disco, red y logs de la aplicación
Checklist de verificación final
Verificación de seguridad
- Revisar que funcionen correctamente todos los puntos: autenticación por clave SSH, inicio de sesión por contraseña, inicio de sesión root, firewall, actualizaciones automáticas, modo de producción, SSL y respaldos
Prueba de rendimiento
- Realizar una prueba de carga con Apache Bench, monitorear recursos y revisar errores en los logs
Lista rápida de comandos de referencia
Verificación de información del sistema
- htop, df -h, free -h, uname -a
Gestión de procesos
- pm2 status, pm2 restart all, pm2 logs, pm2 monit
Seguridad
- sudo ufw status, sudo fail2ban-client status, sudo lynis audit system
Gestión de servicios
- sudo systemctl status nginx, sudo systemctl restart nginx, sudo journalctl -u nginx
Cierre
- Esta checklist ofrece un procedimiento completo de configuración y administración de un VPS
- Además del bajo costo, permite obtener gestión directa, aprendizaje y autonomía DevOps
- El self-hosting con Hetzner y Coolify hace posible experimentar confianza y libertad a través de experiencia práctica real
- Es un contenido que sirve como guía concreta para quienes quieren iniciarse en el hosting con VPS
1 comentarios
Comentarios de Hacker News
Creo que es un muy buen resumen para alguien principiante como yo; sin duda lo voy a guardar en marcadores.
Pero lo que me decepciona es que el título menciona Coolify, aunque en el cuerpo casi no se habla de eso.
Otro artículo útil sobre un tema similar es 'Setting up a Production-Ready VPS from Scratch', así que también lo guardé con este enlace:
https://dreamsofcode.io/blog/setting-up-a-production-ready-vps-from-scratch
Cuando quiero entender ese tipo de temas con más profundidad, normalmente le paso el enlace del artículo a un LLM y le digo:
"Este es un artículo sobre 'tema/título': https://article.link. Entiéndelo bien, analízalo, luego amplía cada sección con tu conocimiento e incluye también secciones adicionales relacionadas"
Así es como estudio.
https://www.youtube.com/watch?v=taJlPG82Ucw
Llevo alrededor de un año operando con esa configuración, y fue la primera vez que sentí confianza con el self-hosting.
OVH también es tan confiable como Hetzner, y ahora tiene planes mucho más baratos.
https://us.ovhcloud.com/vps/configurator/?planCode=vps-2025-model3&brick=VPS%2BModel%2B3&pricing=upfront12&processor=%20&vcore=8__vCore&storage=200__SSD__NVMe
Si fuera a usar Coolify, estaría dudando qué distribución elegir.
Estoy entre Ubuntu 24.04 y Debian 13 como mejor opción.
En OVH VPS son $53.4 al mes por 24 vCPU (o hilos) y 96 GB de RAM.
En Hetzner VPS (tomando la opción AMD) son 16 vCPU, 32 GB y $54.9/mes.
Un Droplet de DO cuesta $504/mes por 16 vCPU y 64 GB de RAM.
Linode y Upcloud también salen mucho más caros que OVH, con 24~20 vCPU y 96 GB de RAM por $576/mes.
No sé qué CPU usa OVH, pero incluso considerando la diferencia de precio, aunque fuera un CPU Intel E-Core, sigue pareciendo una oferta bastante buena.
Como referencia, Hetzner también tiene una opción más barata con Intel vCPU, pero usa hardware viejo y solo se liberan espacios cuando otro cliente cancela.
Por eso comparé únicamente con la opción AMD más reciente.
El único problema con OVH es que, para rentar un VPS (de unos $30 al mes), te obligan a enviar una copia de tu identificación.
No quiero repartir mis datos personales de esa forma, así que al final elegí una opción más cara.
En mi experiencia, aunque no es muy extensa, los servidores cloud de Hetzner me dieron mucho mejor rendimiento que los VPS de OVH.
Aun así, estoy satisfecho con ambos.
Me pregunto por qué OVH y Hetzner son tan baratos comparados con otros proveedores.
Puedo entenderlo hasta cierto punto si los VPS están más sobrevendidos que en otros lados, pero ambos también tienen servidores dedicados muy baratos.
Hasta me hace pensar si será algún tipo de honeypot, o si quizá OVH cambió sus precios recientemente.
Recuerdo que hace algunos años era más caro que Hetzner.
Es muy probable que todos los CPU mencionados aquí sean en realidad recursos compartidos.
Y no publican cuánto se comparte realmente.
En Hetzner hay servidores con la misma cantidad de núcleos pero a la mitad de precio.
No se ve a simple vista, pero si haces pruebas de rendimiento, los servidores baratos en realidad rinden la mitad.
En la configuración de CSS, desactivé estas dos cosas y la UI/UX del blog mejoró muchísimo:
pre {
margin: 2rem 0 !important;
padding: 1rem !important;
}
El padding y el margin de los bloques de código eran tan grandes que en pantalla solo se veían tres líneas.
Y si instalas Webmin/Virtualmin, tareas como agregar nuevos subdominios o usuarios se vuelven mucho más sencillas.
Hice clic porque me interesaba Coolify, pero en realidad solo se menciona en las etiquetas, la introducción y el cierre; en el cuerpo no hay nada.
Me parece inapropiado incluso mencionarlo.
En realidad este artículo trata sobre cómo preparar un VPS para desplegar Coolify.
No trata sobre la instalación de Coolify en sí.
Hasta ahora he estado administrando todos mis servicios con Docker Compose en una VM, así que entré porque quería saber si Coolify sería una alternativa claramente mejor a ese enfoque.
Pero no había contenido real sobre Coolify, y los trabajos manuales para "prepararlo" incluso parecían más complicados.
Mi forma de hacerlo, que básicamente es “usar una imagen base de Docker Compose y ajustar unas pocas cosas”, se ve mucho más simple,
así que sentí que mi método actual sigue siendo perfectamente válido.
Lo bueno es que migrar entre hosts se resuelve en un 99% simplemente copiando un archivo YAML de Docker Compose.
Probé Coolify hace unos meses, y cuando varios contenedores estaban conectados con Compose aparecían todo tipo de problemas.
Por ejemplo, a veces olvidaba que cierto contenedor ya estaba corriendo y lo levantaba duplicado, o ambos seguían activos pero Coolify solo reconocía uno.
Si registras cada servicio por separado en Coolify, funciona más o menos bien.
Al final yo también regresé a una configuración independiente basada en Docker Compose, y de hecho fue mucho más fácil de operar.
Creo que intentos como Coolify son realmente necesarios, pero por ahora todavía le falta para usarse en producción seria.
Si Coolify o proyectos similares no soportan respaldos de base de datos y streaming replication, se van a quedar en el terreno del hobby.
Yo opero 2 VM con Docker Compose y scripts de bash, y con solo configurar respaldos por hora a S3, wal streaming, y streaming replication de PG y Redis, siento que ya se cubre el mínimo necesario para producción real.
Supongo que depende del caso de uso, pero yo probé tanto Coolify como CapRover.
Al final me quedé con CapRover porque podía levantar apps de NodeJS más rápido con compilación automática en cada commit usando Git Hook.
Ambos soportan esa función, pero con CapRover hay menos fricción.
Coolify tiene más funciones.
Coolify funciona sobre Traefik y Docker, y en esencia es una UI encima de eso.
Le faltan muchas funciones esenciales relacionadas con respaldos (aunque puedes resolverlo con algo como restic), y la UX simplemente es aceptable.
Coolify todavía requiere permisos de root durante la instalación.
Escuché que están desarrollando una rama para instalarlo sin permisos de root.
Podrías entrar por ssh al servidor, instalar Coolify y luego desactivar el login de root.
Si estás dispuesto a borrar el servidor y volver a configurarlo desde cero, eso se puede hacer.
Yo también intenté hace poco un despliegue de Coolify completamente desde cero, pero seguía fallando por errores con las llaves ssh.
Aunque despliego varios proyectos sin problemas en otros servidores, el enfoque de “solo dame el archivo docker compose” en la práctica nunca me ha funcionado bien ni una sola vez.
Hace poco migré un servidor FreeBSD a Hetzner y fue muy fácil.
La única variable fue que, hasta que no termina por completo el primer ciclo de pago, bloquean los puertos para servidor de correo.
Entiendo la política, pero al empezar no estaba explicada con claridad y me tomó por sorpresa.
Por cierto, si tu tarjeta de crédito vence, Hetzner puede cortarte la red de inmediato.
No hubo aviso previo y solo me enteré cuando me contactó un cliente o alguien del staff.
A mí sí me pasó de verdad.
Si le explicas al equipo de Hetzner qué tipo de tráfico vas a manejar y haces la consulta, a veces te abren los puertos por adelantado.
Yo les mostré pruebas del proyecto que iba a migrar y me lo habilitaron enseguida.
Herramientas como Coolify (o Dokploy) se ven bien, pero siempre me molesta que el estado del servidor no quede reflejado en código.
Por eso prefiero NixOS o Ansible, aunque para montar producción de verdad exigen demasiado boilerplate y personalización.
Me pregunto si alguien conoce algún framework de infraestructura como código, que no sea Kubernetes, pero sí más declarativo y que facilite administrar servidores de producción.
Casi no hay nada que respaldar de la configuración de Coolify, y la configuración de las aplicaciones queda toda en /data/coolify.
Respaldo el volumen completo con kopia.
No es algo elegante ni bien diseñado, más bien es un truco, pero como recuperación ante desastres sí puede servir.
Es una buena guía.
Pero no estoy de acuerdo con la configuración del firewall, especialmente si usas Hetzner.
Si solo necesitas una configuración sencilla, el firewall provisto por Hetzner es más que suficiente y además tiene el efecto de estar “tercerizado”.
Si quieres algo más personalizado, incluso puedes configurarlo por API.
https://docs.hetzner.cloud/reference/cloud#firewalls
Me pregunto si el firewall de Hetzner tiene alguna desventaja crítica.
Me parece riesgoso el consejo de “permitir SSH solo para mi IP” (opcional, pero recomendado).
Si tu IP cambia, podrías quedarte completamente sin acceso.
Se puede restablecer desde el panel de Hetzner, pero en vez de amarrarte a una IP residencial que cambia todo el tiempo, es mejor usar algo como Tailscale
o tener una IP fija externa de VPN.
Solo con usar autenticación por llave en SSH ya evitas casi todos los problemas de seguridad.
Además está bien agregar alguna capa para reducir el ruido en los logs, y si tienes servicios que no necesitan exponerse hacia afuera aparte de SSH,
me parece mejor protegerlos con una VPN o algo similar.
De hecho, la mayoría de los servicios suelen ser más vulnerables que SSH.
Sí, definitivamente es riesgoso.
Mucha gente en casa usa IP dinámica.
Con configurar llaves SSH y desactivar el login de root, me parece suficientemente seguro.
Creo que la parte de configurar la app para producción sería mejor reemplazarla por Docker.
Hoy en día Docker es mucho más repetible y más fácil de configurar.