Install script generator for Linux VPS
Build your VPS initial setup checklist (Docker, Nginx, Node.js, Fail2Ban, UFW, swap, Certbot, hardening) and get a single copy-paste bash script, or each command on its own. For Ubuntu 22.04, 24.04 and Debian 12.
Review the script before running it in production: not every step is necessary for every case, and some — like disabling SSH password login — can lock you out of the server if you haven't already set up an SSH key and confirmed it works.
Comma-separated. E.g: 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
Why a freshly created VPS isn't production-ready
A base Ubuntu or Debian image is built to be generic, not secure by default: no active firewall, SSH password login enabled (often for root too on many images), no swap, and nothing running to ban brute-force attempts. That's fine for an image that has to boot in any scenario, but it means the moment your server has a public IP, it starts getting automated scans and login attempts within minutes. This checklist isn't exotic — it's basically the same handful of steps any sysadmin runs by hand on every new VPS, before putting a single app into production.
UFW and Fail2Ban aren't the same thing (and aren't redundant)
UFW is a firewall: it filters traffic proactively, by port and protocol, before it reaches any service — if a port is closed, a login attempt never even gets a chance. Fail2Ban acts afterward: it reads logs (e.g. /var/log/auth.log) and temporarily bans an IP once it detects several failed login attempts, typically over SSH. They're complementary: UFW reduces your attack surface (which ports even exist), Fail2Ban mitigates the noise on the ports you did leave open (like SSH's port 22, which almost always has to stay reachable from somewhere). Having one doesn't make the other redundant.
Why swap if I already have plenty of RAM?
It's not meant for the system to lean on it in normal use — actively paging to disk is far slower than RAM and not something you want happening often. The real reason is that it acts as a safety net for a one-off memory spike: a build that runs away, a process with a leak, an unusual moment of load. Without swap, the Linux kernel handles that with the OOM killer, which kills processes (sometimes not the one you'd expect) to free memory immediately. With a swapfile in place, that spike gets absorbed as temporary slowdown instead of a process dying out of nowhere.
FAQ
Does this break anything if I already have Nginx (or Docker, or Node) installed?+
Generally no — apt install on a package that's already at its latest version is a no-op, and systemctl enable/start on an already-running service isn't destructive either. The one thing to watch is Fail2Ban (this overwrites jail.local with the config generated here, not any custom config you already had) and Node via NodeSource (if you already had Node from another source, it can conflict with the NodeSource package — best to start from a clean server or check your existing version first).
Do I need to run this as root?+
Yes — every command assumes a root shell (no sudo prefix), which is how you typically access a freshly created VPS. If your user isn't root, either run the script with sudo bash script.sh, or prefix each line with sudo yourself.
Why isn't SSH hardening checked by default?+
Because it's the only step in this checklist that can lock you out of your own server if you run it without having set up SSH key access beforehand. That's why, on top of leaving it unchecked by default, we require a separate explicit confirmation before those lines go live in the script — until you check it, they stay commented out (inactive) even if you include that section.
Does this work the same on Ubuntu and Debian?+
Almost everything is identical since both use apt/dpkg. The one real difference the distro selector handles is the official Docker repo URL (download.docker.com/linux/ubuntu vs /debian) — the exact codename (jammy, noble, bookworm) is auto-detected inside the script via /etc/os-release, so it does not depend on picking the exact right version.
Need the VPS before the script?
VPS with real NVMe and a dedicated IP, ready in under a minute to run this checklist from scratch.
View plans