Most VPS security advice is either too abstract to act on or too paranoid to be worth the setup time for a solo founder's server. This is the practical middle: the specific steps that meaningfully reduce risk for the kind of server most indie SaaS builders actually run, in the order I do them.
SSH hardening
- Disable root login (
PermitRootLogin no) once you've confirmed a sudo user works. - Disable password authentication entirely (
PasswordAuthentication no) — key-based auth only. - Change the default port. This stops the overwhelming majority of automated bot scanning, even though it's not a defense against a targeted attacker.
- Limit login attempts and add a short delay for failures at the SSH daemon level if your distribution supports it.
Firewall rules that matter
Default-deny inbound, and explicitly allow only what you need:
ufw default deny incoming
ufw default allow outgoing
ufw allow 2222/tcp # your SSH port
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
If your control panel runs on its own port, allow that too — but consider restricting it to your own IP address specifically (ufw allow from YOUR_IP to any port 7800) rather than opening it to the world. Most VPS providers also offer a network-level firewall in their dashboard; using both the provider firewall and ufw is redundant but not harmful, and gives you a second layer if one is misconfigured.
Fail2ban configuration
Fail2ban watches log files for repeated failed login attempts and temporarily bans the offending IP at the firewall level. Install it and enable at minimum the SSH jail:
sudo apt install fail2ban
sudo systemctl enable --now fail2banIf you're running Nginx with a login form (a customer dashboard, an admin panel), add a custom jail that watches your application's auth failure logs too — brute-force attempts against application logins are at least as common as SSH scanning.
Keeping packages patched
Enable unattended security upgrades for the base OS:
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgradesThis patches OS-level security vulnerabilities automatically without requiring you to remember a monthly maintenance window. It won't touch your application dependencies, though — those need their own update discipline (Dependabot or equivalent, reviewed regularly, not left to accumulate).
Control panel and admin surface
Whatever control panel you use (aaPanel, cPanel, or none at all), enable two-factor authentication on its login if it's supported — see our walkthrough for adding 2FA to both SSH and your panel login — and treat its admin URL and port like a secret — don't link to it from anywhere public, and restrict access by IP where your workflow allows it.
What not to bother with (yet)
Intrusion detection systems, SIEM tooling, and full audit logging pipelines are genuinely valuable at scale, but for a single-server indie SaaS they're often more operational overhead than the threat model justifies at that stage. Get the fundamentals above solid first — they address the overwhelming majority of real-world compromise vectors for a small server — and revisit heavier tooling once you have the team bandwidth to actually act on what it reports.
Frequently asked questions
Is changing the SSH port actually worth doing?
It's not a defense against a targeted, determined attacker, but it removes the overwhelming majority of automated bot scanning traffic from your logs, which makes real attempts easier to spot and reduces noise on Fail2ban. It's a five-minute change with a genuinely favorable cost-to-benefit ratio.
How do I know if my server has already been compromised?
Warning signs include unexpected outbound network connections, unfamiliar processes consuming CPU (often cryptocurrency miners), new SSH keys or user accounts you didn't create, and modified system binaries. If you suspect compromise, the safest response is usually to rebuild from a known-clean snapshot or fresh image rather than trying to manually clean an already-compromised system.
Do I need a Web Application Firewall (WAF) on top of all this?
Not necessarily for a small single-server SaaS — a WAF adds real value against application-layer attacks (SQL injection attempts, bad bots) once you have meaningful traffic, but the fundamentals in this checklist address a larger share of real-world small-server compromises. Consider a WAF (many CDN providers offer one as an add-on) once you've outgrown this baseline, not instead of it.