Hardening in one sentence
Hardening is reducing a server's attack surface: fewer services listening, fewer credentials that work, fewer things an attacker can do after getting in. On a VPS this is your responsibility from minute one — a fresh instance with password SSH and an open firewall is scanned within minutes of boot.
The checklist that matters
SSH: key-only authentication, no root login, ideally a non-standard port or VPN/bastion. Firewall: default-deny inbound, allow only 80/443 and your management path. Updates: unattended security patches for the OS. Services: remove or disable everything not serving the app. Users: least privilege, no shared accounts. TLS: automated certificates, no legacy protocols. Logs: shipped somewhere an attacker cannot erase. Backups: automated, tested by restoring.
Everything on that list is table stakes, none of it differentiates your product, and all of it fails silently when neglected.
The part nobody puts on the checklist
The biggest risk is drift: hardening is a process, not a one-time setup. The server hardened in January runs unpatched software by June unless someone owns it continuously.
Where SimDeploy fits
On SimDeploy there is no server for you to harden: builds run on your machine, only static output and functions are published, user code never executes on the platform's own servers, secrets are encrypted at rest, and the serving layer is the provider's hardened edge. The checklist above stays valid for the machines you still operate — and disappears for the projects you deploy here.
FAQ
What is the first thing to do on a new VPS?
Before anything else: create a non-root user, switch SSH to key-only authentication, and enable a default-deny firewall allowing only SSH and 80/443. Then enable automatic security updates.