Every time I spin up a new VPS, I usually start with the same thought:
“I just need this server for one app. I’ll secure it properly later.”
And that is exactly where problems begin.
A fresh VPS is convenient, cheap, and fast to create. But by default, it is also too easy to leave exposed. SSH is usually open, the root user may still be accessible, firewall rules are often too permissive, logs are not always durable, and basic security updates depend on you remembering to apply them.
After working with my own VPS servers for self-hosted apps, Docker deployments, Dokploy, Coolify, experiments, and production-ish side projects, I started to repeat the same hardening checklist over and over again.
So I decided to turn that checklist into my own baseline recipe.
Not a perfect security solution. Not a replacement for a real audit. Just a practical, opinionated starting point that makes a new Debian/Ubuntu server safer from day one.
That recipe became vps-hardener.
The goal: a protected baseline from zero
The goal is not to make a VPS “impossible to hack.” That is not realistic.
The goal is simpler:
When I create a new server, I want to reduce the most common risks immediately:
default SSH exposure
root login
password-based authentication
missing firewall rules
missing automatic security updates
no brute-force protection
no private admin network
no persistent logs
weak kernel/network defaults
Most of these things are not complex. The problem is that they are easy to forget when you are moving fast.
A baseline script helps because it turns a manual checklist into a repeatable setup.
Why I focus on Debian/Ubuntu VPS servers
Most of my VPS work happens on Debian or Ubuntu-based servers.
They are common, well documented, supported by most providers, and compatible with the tools I usually use: Docker, Dokploy, Coolify, Tailscale, UFW, fail2ban, unattended-upgrades, and Chrony.
The first version of the script is intentionally focused there. Supporting every Linux distribution would make the tool more complex, and I wanted the first version to stay boring and reliable.
That is also why the script is opinionated.
It does not try to support every possible setup. It tries to cover the setup I actually use when I want to start a VPS safely.
1. System update and base packages
The first step is simple: update the server.
A fresh VPS image can still have outdated packages. Before installing anything else, I want the system to be current.
The script runs the usual update and upgrade flow, then installs common admin tools I normally want anyway: curl, wget, git, jq, htop, unzip, networking tools, and similar utilities.
The upside is practical: after the script finishes, the server is immediately more usable for debugging and administration.
This is not glamorous, but it matters. A secure server that is painful to inspect is not fun to operate.
2. A dedicated deploy user
One of the first things I want on a new VPS is a non-root user.
The script creates a deploy user by default, adds it to sudo, and copies available SSH keys into that user.
Why?
Because I do not want to operate day-to-day as root.
Using a dedicated user gives me a cleaner operational model:
root login can be disabled
deployments can happen through a predictable user
SSH access is easier to reason about
automation can target the same username across servers
The script also supports overriding the user with DEPLOY_USER, or using DEPLOY_USER=auto if you want to reuse the current sudo user.
The important part is that the server should not depend on direct root SSH access.
3. SSH hardening
SSH is usually the front door of the server.
So I want the basics locked down early:
disable root login
disable password authentication
require public key authentication
reduce authentication attempts
disable X11 forwarding
keep the SSH config isolated in a dedicated hardening file
Instead of editing the main SSH config directly, the script writes hardening rules into:
/etc/ssh/sshd_config.d/99-vps-hardening.conf
That makes the change easier to review and easier to remove if needed.
The biggest upside here is reducing brute-force risk. If password authentication is disabled and only SSH keys work, automated login attempts become much less useful.
But there is one important safety rule:
The script requires SSH keys to exist before continuing.
That is intentional. A hardening script should not lock you out of your own server.
4. UFW firewall with safer defaults
A new VPS should not expose every service by accident.
The script configures UFW with:
default deny incoming
default allow outgoing
Then it opens only what is needed.
By default, SSH remains available unless you explicitly configure a more locked-down setup. For web servers, ports 80 and 443 can be allowed, but the script also tries to avoid opening them unnecessarily when no web service is listening.
This is one of the parts I care about most.
A lot of self-hosted setups accidentally expose databases, Redis, admin panels, or internal services. A firewall baseline helps reduce that risk.
For example, Postgres and Redis should usually not be publicly reachable from the internet. They should live inside Docker networks, private networks, or trusted access paths.
The firewall is not the only layer of security, but it is a very useful guardrail.
5. Optional Tailscale for private access
For admin access, I like using Tailscale.
Tailscale gives me a private network between my machines and servers without having to manually manage VPN servers.
In this setup, Tailscale can be used to make SSH private. Instead of exposing SSH publicly to the internet, the server can allow SSH only through the tailscale0 interface.
That gives a cleaner model:
Public internet:
80/443 only when needed
Private Tailscale network:
SSH
admin access
internal server-to-server communication
The script supports this through TAILSCALE_AUTHKEY and USE_TAILSCALE.
One design choice I added is auto-detection:
If you provide a TAILSCALE_AUTHKEY, the script assumes you want Tailscale enabled.
And if the Tailscale join succeeds, public SSH can be closed automatically unless you explicitly keep it open.
That makes the secure path easier.
6. fail2ban when public SSH remains open
If public SSH remains open, I want fail2ban installed.
fail2ban watches authentication logs and bans repeated failed login attempts.
It is not magic, and it does not replace SSH keys or firewall rules, but it is a useful extra layer when a server still accepts SSH traffic from the public internet.
In my baseline, fail2ban is especially useful for setups where I am not using Tailscale yet, or where public SSH needs to remain available temporarily.
The upside is simple: fewer repeated brute-force attempts hitting the SSH service over and over.
7. unattended-upgrades for security updates
I do not want every small security update to depend on my memory.
That is why I enable unattended-upgrades.
For a VPS that runs long-lived services, automatic security updates are a practical baseline. They help close known vulnerabilities faster, especially for system packages.
Of course, this is still not a replacement for maintenance. You still need to monitor your server, update Docker images, patch application dependencies, and reboot when required.
But enabling unattended security updates is a good default.
It reduces the chance that a forgotten VPS stays vulnerable for weeks or months.
8. Chrony and timezone
Time matters more than people think.
Logs, TLS, distributed systems, cron jobs, database timestamps, monitoring, and debugging all depend on correct time.
That is why the script installs Chrony and sets a predictable timezone.
By default, I use UTC because it is easier to reason about across servers and deployments. But the timezone can be overridden with TIMEZONE.
This is one of those small decisions that prevents confusion later.
When something breaks, having consistent timestamps helps a lot.
9. sysctl hardening
The script also applies a small set of kernel/network hardening defaults using sysctl.
The goal is not to tune the kernel aggressively. The goal is to apply sensible security-oriented defaults, such as:
These settings are not a silver bullet, but they improve the default posture of the server.
The key here is balance.
I do not want a script that applies hundreds of obscure kernel settings and then breaks normal workloads. I want a small, understandable baseline that is safe for common VPS usage.
10. Persistent journald logs
By default, logs can be less durable than you expect.
For troubleshooting, I want system logs to survive reboots.
So the script enables persistent journald logs by creating:
/var/log/journal
Then it restarts systemd-journald.
The upside is simple: when something goes wrong, you have a better chance of seeing what happened before the reboot.
This is especially useful when debugging SSH, Docker, firewall behavior, system crashes, or service failures.
Profiles and auto-detection
One thing I wanted to avoid was forcing people to remember a large set of environment variables.
So the script supports profiles and auto-detection.
Examples:
PROFILE=web for a web server setup
PROFILE=minimal to avoid opening HTTP/HTTPS
PROFILE=lockdown to restrict SSH to your current IP
TAILSCALE_AUTHKEY to automatically enable Tailscale
The priority is:
explicit environment variable > profile > auto-detection
That means you can use a simple command most of the time, but still override behavior when needed.
For example:
curl -fsSL https://raw.githubusercontent.com/aiherrera/vps-hardener/main/hardener.sh | sudo bash
Or with Tailscale:
curl -fsSL https://raw.githubusercontent.com/aiherrera/vps-hardener/main/hardener.sh | sudo TAILSCALE_AUTHKEY=tskey-... bash
Or for a web server:
curl -fsSL https://raw.githubusercontent.com/aiherrera/vps-hardener/main/hardener.sh | sudo PROFILE=web bash
The idea is to make the safe path easy, but not completely rigid.
What this does not solve
I want to be clear about this part.
A VPS hardening script does not make a server fully secure forever.
It does not replace:
It also does not protect you if you expose a database publicly with weak credentials, run untrusted containers, leak environment variables, or deploy vulnerable applications.
The script is only the baseline.
But a baseline matters.
Because starting from a better default reduces the number of obvious mistakes.
Why I built the repo
I built vps-hardener because I wanted my own repeatable server setup.
Every time I created a new VPS, I had to remember the same things:
create the deploy user
copy SSH keys
disable root login
disable password login
configure UFW
decide whether to use Tailscale
install fail2ban
enable unattended upgrades
configure time sync
persist logs
apply basic sysctl hardening
Doing this manually once is fine.
Doing it repeatedly is annoying.
Forgetting one step is risky.
So I turned it into an open-source script.
The repo is here:
https://github.com/aiherrera/vps-hardener
I also created a small page with docs and a script builder so you can pick the right setup for your use case:
https://harden.aiherrera.com
The script builder is useful because not every VPS needs the same setup. Some are web servers. Some are private workers. Some should use Tailscale. Some should not expose HTTP or HTTPS at all.
Instead of manually editing environment variables, you can choose the setup and generate the right command.
Final thoughts
Server hardening does not need to be complicated to be useful.
The best baseline is the one you actually apply every time.
For me, that means something simple, repeatable, and opinionated enough to prevent the most common mistakes.
vps-hardener is my current recipe for that.
It is not perfect, and I will keep improving it as I use it more.
But now, when I spin up a new VPS, I no longer start from a blank checklist.
I start from a safer baseline.
