A calmer first day with your Linux VPS.

A self-managed server gives you useful control. It also makes your choices about users, software and network access part of the service’s security. This guide is a planning checklist, not a universal hardening script.

Establish a recovery route first

Before changing remote access, confirm how you would recover from a mistake. Keep a working session open while testing changes through a second session. Do not disable the only access method you have before its replacement is confirmed.

Keep access personal and limited

Use individual accounts where practical so access can be changed without sharing credentials. Set up SSH keys according to your distribution’s documentation. Protect private keys and review who needs administrative privileges.

Review unexpected host-key changes before connecting. A replaced server can have a different key, but you should verify the reason through a trusted channel instead of accepting the change automatically.

Update with an understanding of the application

Keep the operating system and application dependencies current. Read upgrade notes when a change can affect compatibility. Choose a maintenance process that includes testing and a way to recover if the application does not start as expected.

Know which services are reachable

Only expose the network services your application needs. Check operating-system firewall rules and application bindings. Verify access from the places that should be allowed, and verify that private services are not reachable from elsewhere.

If you run containers, review the container platform’s networking and firewall behaviour too. Docker’s Ubuntu installation documentation specifically discusses firewall considerations; container port publishing needs attention alongside host rules.

Keep secrets out of the wrong places

Do not store production credentials in public repositories or support screenshots. Apply suitable permissions to configuration files. Rotate credentials if they have been exposed, and consider where copies may remain in logs or backups.

Observe and recover

Monitor authentication events, unexpected service changes and resource pressure. Have a plan to isolate a suspected compromise and restore from a known-good state. Backups need their own access controls and should not all share the server’s credentials.