Generador de scripts de instalación para VPS Linux
Armá el checklist de setup inicial de tu servidor (Docker, Nginx, Node.js, Fail2Ban, UFW, swap, Certbot, hardening) y llevate un solo script bash listo para copiar y correr, o cada comando por separado. Para Ubuntu 22.04, 24.04 y Debian 12.
Revisá el script antes de correrlo en producción: no todos los pasos son necesarios para todos los casos, y algunos — como deshabilitar el login por contraseña de SSH — pueden dejarte afuera del servidor si no configuraste antes una llave SSH y probaste que funciona.
Separados por coma. Ej: 80, 443, 25565/udp.
#!/bin/bash
set -e
# Generado con el generador de scripts de instalación de SolumeCore
# solumecore.com/tools/install-scripts
# Distro objetivo: Ubuntu 24.04 LTS (Noble)
# Revisá cada sección antes de correrlo en producción.
# ---- Actualizar el sistema ----
apt update && apt upgrade -y
# ---- Firewall UFW ----
apt update
apt install -y ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw allow 80
ufw allow 443
ufw --force enable
# Verificación
ufw status verbose
# ---- Archivo de swap ----
# Evita crear un swapfile duplicado si ya hay uno activo con este nombre
if ! swapon --show | grep -q '/swapfile'; then
fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
fi
# Lo persiste en /etc/fstab, sin duplicar la línea si ya está
grep -q '^/swapfile ' /etc/fstab || echo '/swapfile none swap sw 0 0' >> /etc/fstab
Por qué un VPS recién creado no está listo para producción
Una imagen base de Ubuntu o Debian viene pensada para ser genérica, no segura por default: sin firewall activo, con login por contraseña habilitado por SSH (incluyendo para root en muchas imágenes), sin swap, y sin nada corriendo que banee intentos de fuerza bruta. Eso está bien para una imagen que tiene que arrancar en cualquier escenario, pero significa que apenas tu servidor tiene una IP pública, empieza a recibir escaneos e intentos de login automatizados en minutos. El checklist de esta página no es exótico — es básicamente el mismo puñado de pasos que cualquier sysadmin corre a mano en cada VPS nuevo, antes de poner una sola app en producción.
UFW y Fail2Ban no son lo mismo (y no son redundantes)
UFW es un firewall: filtra tráfico de forma proactiva, por puerto y protocolo, antes de que llegue a ningún servicio — si un puerto está cerrado, ni siquiera se intenta el login. Fail2Ban actúa después: lee logs (por ejemplo /var/log/auth.log) y banea temporalmente una IP recién cuando detecta varios intentos fallidos de login, típicamente por SSH. Son complementarios: UFW reduce la superficie de ataque (qué puertos existen), Fail2Ban mitiga el ruido en los puertos que sí dejaste abiertos (como el 22 de SSH, que casi siempre tiene que quedar accesible desde algún lado). Tener uno no reemplaza al otro.
¿Por qué swap si ya tengo mucha RAM?
No es para que el sistema dependa de él en uso normal — paginar activamente a disco es mucho más lento que la RAM y no es algo que quieras que pase seguido. La razón real es que actúa como red de seguridad ante un pico puntual de memoria: un build que se descontrola, un proceso con una fuga, un momento de carga inusual. Sin swap, el kernel de Linux resuelve eso con el OOM killer, que mata procesos (a veces el que menos esperás) para liberar memoria de golpe. Con un swapfile de por medio, ese pico se absorbe con una degradación de performance temporal en vez de un proceso muerto de la nada.
Preguntas frecuentes
¿Esto rompe algo si ya tengo Nginx (o Docker, o Node) instalado?+
En general no — apt install sobre un paquete que ya está en su última versión simplemente no hace nada, y systemctl enable/start sobre un servicio que ya está corriendo tampoco es destructivo. Lo único a tener en cuenta es Fail2Ban (sobreescribe jail.local con la config generada acá, no tu config anterior si tenías una personalizada) y Node vía NodeSource (si ya tenías Node de otra fuente, puede convivir mal con el paquete de NodeSource — lo ideal es partir de un servidor limpio o revisar antes qué versión tenés).
¿Necesito ejecutar esto como root?+
Sí — todos los comandos asumen una shell de root (sin prefijo sudo), que es como normalmente accedés a un VPS recién creado. Si tu usuario no es root, o corré el script con sudo bash script.sh, o agregá sudo delante de cada línea.
¿Por qué el hardening de SSH no viene marcado por default?+
Porque es el único paso de este checklist que te puede dejar afuera de tu propio servidor si lo corrés sin haber configurado antes el acceso por llave SSH. Por eso además de destildarlo por default, pedimos una confirmación explícita aparte antes de activar esas líneas en el script — mientras no la marqués, quedan comentadas (inactivas) igual si incluís esa sección.
¿Funciona igual en Ubuntu que en Debian?+
Casi todo es idéntico porque ambos usan apt/dpkg. La única diferencia real que maneja el selector de distro es la URL del repositorio oficial de Docker (download.docker.com/linux/ubuntu vs /debian) — el codename exacto (jammy, noble, bookworm) se detecta automáticamente dentro del script vía /etc/os-release, así que no depende de que elijas bien la versión exacta.
¿Necesitás el VPS antes que el script?
VPS con NVMe real e IP dedicada, listo en menos de un minuto para correr este checklist desde cero.
Ver planes