← Blog

What to do after buying a VPS: first-hour checklist

The first hour after buying a VPS sets the tone for everything that comes next. If you rush straight into installing apps, you can leave a public server with weak access, no firewall, no backup plan, and no notes about how to recover it later. This checklist keeps the first hour calm: save access, update the system, secure SSH, open only the ports you need, and make the server recoverable before it becomes important.

1. Save the access details

Before changing anything, write down the basics somewhere safe. A surprising number of VPS problems start with "I do not remember which key I used" or "I do not know which account owns this server." For a normal host, that might mean email recovery. For a no-KYC host, your account token may be the only way back in.

2. Update the operating system

A fresh image is not always fully patched by the time you boot it. Update first, reboot if required, then continue.

# Debian / Ubuntu
sudo apt update
sudo apt upgrade -y
sudo reboot

# RHEL family
sudo dnf upgrade -y
sudo reboot

After reboot, reconnect and confirm the machine is healthy:

uptime
df -h
free -h

3. Create a non-root sudo user

If the server gives you root access, do not use root for daily work. Create a normal user, give it sudo, and log in with that account instead.

# Debian / Ubuntu
adduser deploy
usermod -aG sudo deploy
rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy/

# test from a second terminal before closing the root session:
ssh deploy@YOUR_SERVER_IP
sudo -v

That second-terminal test matters. Keep the original root session open until the new login works. If you mistype the SSH config later, the open session can still fix it.

4. Secure SSH before installing apps

SSH is the front door. Lock it before installing Docker, a web panel, a database, or public services. The minimum sane setup is: key-only login, no root login, and only the user you actually use.

sudo tee /etc/ssh/sshd_config.d/99-first-hour.conf >/dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AllowUsers deploy
EOF

sudo sshd -t && sudo systemctl reload ssh

If your distro uses sshd as the service name, reload that instead:

sudo systemctl reload sshd

Changing the SSH port is optional. It reduces log noise, but it is not a replacement for key-only login. If you change it, open the new port in the firewall before reloading SSH.

5. Enable a default-deny firewall

A default-deny firewall protects you from accidental exposure. If a package starts a database or admin service later, the internet cannot reach it unless you explicitly open the port.

# Debian / Ubuntu
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
# Optional web ports:
# sudo ufw allow 80/tcp
# sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

For a website, open only 80 and 443. For a private WireGuard VPN, open the WireGuard UDP port. For a database, usually open nothing publicly and connect through SSH tunneling or a private network.

6. Take a clean baseline snapshot

After updates, SSH hardening, and firewall setup, take your first snapshot if your provider supports it. This gives you a clean restore point before app installs and experiments. A snapshot is not a full backup strategy, but it is useful when you break a config and want to go back to a known-good state.

Name the snapshot clearly, for example 2026-07-07-clean-hardened-baseline. Future you will know exactly what it contains.

7. Add simple monitoring and logs

You do not need a complex monitoring stack on day one. Start with a few basic checks:

• Disk space: df -h should have comfortable free space.
• Memory: free -h should not show constant swap pressure.
• Listening ports: sudo ss -tulpn should show only what you expect.
• SSH logs: check failed logins occasionally with journalctl -u ssh or /var/log/auth.log.

If the server hosts a public website or API, add an external uptime check. It is better to hear about downtime from a monitor than from a user.

8. Set the backup habit now

Backups are easiest to design before the server becomes messy. Ask one question: if this VPS disappeared tonight, what would you need to restore?

• For a static site, it may be enough to keep the source repo and deployment notes.
• For a web app, you need code, environment variables, uploads, and database dumps.
• For a personal service, you may need config files, keys, and volumes.

Keep at least one copy off the VPS. Snapshots are useful, but encrypted off-server backups are safer for important data. See the Restic VPS backup guide for a practical setup.

9. Document what you changed

Documentation does not need to be fancy. A small README.md in your project or a private note is enough. Include:

• How to SSH in
• Which ports are open and why
• How the app starts and stops
• Where logs live
• How backups are created and restored
• How to safely destroy or resize the server

This is especially useful with prepaid VPS billing. If a test server is no longer needed, clean notes make it easy to delete it and stop charges.

10. Copy-paste first-hour checklist

• Saved IP, hostname, region, plan, OS, token, and SSH key location
• Updated the operating system and rebooted if needed
• Created a non-root sudo user
• Confirmed a second SSH session works before closing the first
• Disabled root SSH login and password authentication
• Enabled a default-deny firewall and opened only required ports
• Checked listening services with ss -tulpn
• Took a clean baseline snapshot
• Decided what must be backed up and where the off-server copy lives
• Wrote a short server note so the setup is recoverable later

After this, you are ready to install apps. For the deeper security version, follow How to harden a new VPS. If you are still choosing specs, read How to choose a VPS for self-hosting. If privacy is the reason you are using a crypto VPS, start with Anonymous VPS hosting: the complete no-KYC guide.

FAQ

GhostVPS is an anonymous, no-KYC VPS host on real DigitalOcean infrastructure. Pay with Bitcoin, Monero or USDT (TRC20); deploy in minutes from $9/mo. See pricing or open the panel.