AdminsForum
Guide 15 Things to Do After Buying a New VPS - Printable Version

+- AdminsForum (https://adminsforum.com)
+-- Forum: Servers and infrastructure (https://adminsforum.com/Forum-servers-and-infrastructure)
+--- Forum: Linux administration (https://adminsforum.com/Forum-linux-administration)
+--- Thread: Guide 15 Things to Do After Buying a New VPS (/Thread-guide-15-things-to-do-after-buying-a-new-vps)

15 Things to Do After Buying a New VPS - DEV - 10-07-2026

What should you do first after buying a VPS?
Confirm recovery-console access, update the OS, create a named administrator with SSH keys, allow only the required ports, and set up off-site backups. Verify a fresh login and a restore before installing a hosting panel or moving a live website.

Review status: Documentation reviewed on 9 October 2026. Fresh-VPS walkthrough testing and original screenshots are pending; no OS or panel version is claimed as hands-on tested. Record your exact release with cat /etc/os-release before using these examples.

Scope: Commands below target a fresh, systemd-based Ubuntu/Debian VPS. AlmaLinux/Rocky use different package and firewall tools; do not paste these commands there. Use a supported OS release. If a control panel is already installed, follow its supported update, firewall and backup procedures.

Before you start: Keep your current SSH session open and confirm the provider's web/serial console works. Replace YOUR_SERVER_IP and adminuser with your own values. Run sudo commands as a sudo-capable user; on an initial root session, omit sudo. Never paste passwords, private SSH keys or access tokens into a forum post.

1. Check what you actually bought
Verify the IP addresses, RAM, storage, bandwidth allowance, virtualization type, renewal cost and backup options in the provider dashboard. Check that the guest matches the plan:
Code:
cat /etc/os-release uname -r nproc free -h lsblk df -hT
A disk advertised by the provider and the usable filesystem size can differ. Investigate an unexpectedly small filesystem before storing data; do not resize partitions blindly.

2. Establish a recovery path
Open the provider console before changing SSH or firewall settings. Know how rescue mode works and record the server ID and support contact in a private runbook. Take a baseline snapshot if available. Snapshots on the same provider are convenient rollback points, but they are not an independent backup.

3. Verify the SSH host key
On first connection, compare the host-key fingerprint with one obtained through the provider console or another trusted provider channel. In the server console:
Code:
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
From your own computer:
Code:
ssh root@YOUR_SERVER_IP
Use the initial username specified by your provider if it is not root. A changed host-key warning may follow a reinstall, but can also indicate an attack. Investigate it before accepting a replacement key; do not simply erase the warning.

4. Patch the fresh operating system
Code:
sudo apt update apt list --upgradable sudo apt upgrade
Read the proposed changes and configuration-file prompts. Do not force an unattended upgrade on a server you have not inspected. If the system reports a required reboot, schedule one while the console is available, then reconnect and check services. Do not treat a routine package upgrade as a distribution upgrade.

5. Create a named administrator
Use a personal account for daily work and sudo for privileged tasks:
Code:
sudo adduser adminuser sudo usermod -aG sudo adminuser
Set a strong, unique local password when prompted. Log in as that user in a second session and verify:
Code:
whoami sudo -v sudo id
Do not remove the original access method until the new account and sudo both work.

6. Set up an SSH key from your own computer
On a computer with OpenSSH installed, generate a key only if you do not already have a suitable one. Choose a new filename if prompted about overwriting an existing key, and protect it with a passphrase:
Code:
ssh-keygen -t ed25519 -C "vps-admin"
On Linux/macOS, if ssh-copy-id is available:
Code:
ssh-copy-id adminuser@YOUR_SERVER_IP ssh adminuser@YOUR_SERVER_IP
Use -p with the actual SSH port if it differs from 22. If ssh-copy-id is unavailable, install only the public .pub key in the user's ~/.ssh/authorized_keys through your trusted console/login. The .ssh directory should be owned by that user with mode 700, and authorized_keys with mode 600. The private key stays on your computer.

7. Harden SSH without locking yourself out
Do this only after a fresh key-based login and sudo have succeeded. Back up the SSH configuration, including any snippets, and inspect /etc/ssh/sshd_config and /etc/ssh/sshd_config.d/. Provider/cloud-init snippets and Match blocks can affect the result.

Use sudoedit to update the configuration file that actually controls these settings:
Code:
PermitRootLogin no PubkeyAuthentication yes PasswordAuthentication no KbdInteractiveAuthentication no
The last setting disables keyboard-interactive authentication; do not disable it if your planned MFA uses that method. Validate syntax and inspect effective settings before reloading:
Code:
sudo /usr/sbin/sshd -t sudo /usr/sbin/sshd -T | grep -E '^(permitrootlogin|pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|port) ' sudo systemctl reload ssh
If syntax validation fails, correct it before reloading. sshd generally uses the first obtained value for a setting, so adding a later snippet may not override an earlier one. For Match rules, also check the intended user/client context with sshd -T -C (see man sshd). Open another fresh connection to confirm the intended authentication policy. Keep the original session until that works. A custom port reduces log noise; it is not a substitute for keys and access controls.

8. Configure both firewall layers
Check the provider/cloud firewall as well as the guest firewall. Allow your actual SSH port before enabling either. The following UFW example assumes SSH really listens on TCP 22 and a fresh server without Docker or a panel-managed firewall:
Code:
sudo apt install ufw sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow 22/tcp sudo ufw enable sudo ufw status verbose
For a web server, add TCP 80 and 443 only when required. Avoid exposing database, Redis or panel ports to the whole Internet; prefer loopback, a VPN or restricted source addresses. Apply and test IPv6 rules too if IPv6 is enabled. Docker-published ports need separate attention because their traffic may bypass normal UFW expectations. After every change, test a new SSH connection. If locked out, use the provider console to repair the relevant rule; repeatedly reconnecting will not fix a blocked port.

9. Set a useful hostname and verify time
Pick a hostname you control, such as vps1.example.com:
Code:
sudo hostnamectl set-hostname vps1.example.com hostnamectl timedatectl status
Check /etc/hosts and provider/cloud-init behavior if the name reverts after reboot. A hostname change does not create a DNS record. UTC is convenient for servers; use sudo timedatectl set-timezone UTC if that suits your operations. Verify an NTP service is actually synchronizing rather than assuming the displayed time is correct. Bad time can break TLS checks, authentication and useful log correlation.

10. Plan DNS before moving traffic
Create an A record for the public IPv4 address. Add AAAA only after IPv6 routing, firewall rules and the service have been tested. Check resolution from your workstation and an external network:
Code:
dig +short A vps1.example.com dig +short AAAA vps1.example.com
If dig is missing on Ubuntu/Debian, it is supplied by dnsutils. Allow for DNS caching. Reverse DNS (PTR) is usually set in the provider dashboard and matters especially for mail. Do not deploy a mail server before checking outbound port restrictions and SPF/DKIM/DMARC requirements.

11. Inspect listening services before adding more
Code:
sudo ss -lntup systemctl --failed systemctl list-unit-files --state=enabled
Understand every public listener. Bind internal services to loopback/private networks and remove unneeded software only after checking dependencies. Install a control panel only on an OS and clean-server setup supported by its vendor. Verify installers against the vendor's official instructions; do not run a random downloaded script as root. Keep SELinux/AppArmor enabled and troubleshoot policy denials instead of disabling protection as a shortcut.

12. Configure automatic security updates deliberately
Ubuntu commonly includes unattended-upgrades, but provider images vary. Check your own configuration:
Code:
sudo apt install unattended-upgrades sudo dpkg-reconfigure -plow unattended-upgrades sudo unattended-upgrade --dry-run --debug
Review /etc/apt/apt.conf.d/50unattended-upgrades and the periodic-update configuration. Confirm which repositories are covered, how failures are reported and whether automatic reboot is enabled. Third-party repositories are not automatically covered just because they were added. For panel-managed systems, check vendor compatibility first and schedule required reboots.

13. Add monitoring and actionable alerts
Monitor external availability, disk space and inodes, memory pressure, CPU, failed services, certificate expiry and backup failures. Start with a baseline:
Code:
uptime free -h df -h df -i systemctl --failed sudo journalctl -p err -b --no-pager
Test the alert delivery path. An alert stored only on the failed VPS is not useful. Low "free" RAM alone is not a problem: Linux uses memory for cache, so examine available memory, swap activity and application symptoms. Sustained resource pressure needs investigation, not an automatic reboot or blind tuning.

14. Build off-site backups and prove a restore
Back up application data, database dumps, configuration and the information needed to rebuild. Store an encrypted copy outside this VPS/provider account, protect backup credentials and define retention. Database backups need application-consistent dumps or a supported snapshot/quiescing process; copying live database files can produce an unusable backup.

Restore into an isolated temporary environment. Verify files, ownership, database contents and that the application starts. Record the recovery point objective (how much data you can lose) and recovery time objective (how long recovery may take). A successful upload or a provider snapshot alone does not prove recoverability.

15. Reboot, retest and write a private runbook
Once access and backups are ready, do a planned reboot from the console or with sudo reboot. Confirm SSH, firewall policy, DNS, expected services, monitoring and backup schedules survive it. Record the OS version, purpose, ports, update schedule, backup location and recovery steps. Store secrets in a password manager, not in the runbook or forum.

Useful troubleshooting shortcuts
  • SSH times out: Check the correct IP/port, provider firewall, UFW, routing and service listener through the console. Test IPv4 and IPv6 separately.
  • Connection refused: Check sudo systemctl status ssh and sudo ss -lntp. The host may be reachable but nothing is listening on that port.
  • Permission denied (publickey): Check the username, chosen key, ownership/modes and server logs. Use ssh -v from your computer; redact identifying details before sharing output.
  • Updates fail: Check disk/inodes, DNS, clock and repository errors. Wait for legitimate package jobs to finish; do not delete package-manager lock files to force access.
  • Website fails only on some networks: Check stale DNS and a broken AAAA record before changing the web server.

Done means verified: a fresh key-based administrator login works, only intended ports are reachable, updates are covered, alerts arrive, and an off-site backup has been restored successfully.

Official references
What OS and workload are you setting up? Share the non-sensitive details if you need help adapting this checklist.

Final verification checklist
  • Provider recovery console opens and the server identity is verified.
  • A fresh SSH-key login as your named administrator works, with sudo access.
  • Only intended services are reachable through both firewall layers.
  • OS update policy, DNS and time synchronization are checked.
  • Monitoring alerts reach you outside the VPS.
  • An off-site backup has been restored in an isolated environment.
  • The access, services and scheduled jobs still work after a planned reboot.

Common questions
Should I install aaPanel before doing this checklist?
Prepare and verify the fresh VPS first. Then check aaPanel's current OS requirements and use its supported installation and firewall procedures.

Is a provider snapshot enough as my only backup?
No. Keep an independent copy outside the VPS and test a restore. A snapshot is useful for rollback but can share the same account or provider failure.

Do I need to change SSH port 22?
Changing the port can reduce log noise, but keys, tested access controls and a recovery path matter more. Allow and verify the actual port before changing firewall rules.

Continue with aaPanel