Security
VPS security checklist for a new Linux server
A new VPS is usually reachable from the public internet before it contains anything valuable. That makes the first configuration decisions disproportionately important.
Patch before building on top
Install current security updates before deploying the application stack. Reboot when core components require it while the server is still easy to interrupt.
Use controlled administrative access
Prefer SSH keys over reusable passwords, protect private keys, and remove accounts that do not need access. Where the operating model allows it, use a normal administrative user with privilege escalation instead of treating direct root login as the everyday workflow.
Expose only the services users need
A public web server commonly needs HTTP and HTTPS; it does not automatically need a public database, cache service, metrics endpoint, or management interface.
Use host and provider firewalls deliberately. Binding an internal service to every interface creates unnecessary exposure.
Separate applications and secrets
Run services with appropriate non-root identities and keep application secrets out of public repositories and web-accessible directories. Rotate credentials that were exposed during development or copied through insecure channels.
Make backups independent of the server
A backup stored only on the same VPS is vulnerable to the same disk failure, compromise, deletion, or provider incident. Keep recoverable copies elsewhere and test a restore process.
Monitor the things that fail quietly
Track disk space, memory pressure, service health, certificate expiry, backup success, unusual authentication activity, and availability from outside the server.
Common questions
Is changing the SSH port enough to secure SSH?
No. A non-default port can reduce background noise, but authentication policy, key protection, patching, firewall rules, and account controls are the important security boundaries.