New VPS from SkyServer? Your First-Hour Setup Checklist

The email just landed: your new SkyServer VPS is provisioned, root password included. Before you install WordPress, Docker, or whatever brought you here, spend the next hour doing this checklist. Skip it and you'll almost certainly be back within a week fighting a hacked box, a full disk, or a firewall you forgot to open — we've seen all three happen in the first 48 hours more times than we can count.

None of this is complicated. It's just easy to skip when you're excited to get your app running. Do it in order and you'll have a server that's actually ready for production traffic, not just a server that boots.

Step 1: Log In and Update Everything

SSH in with the root credentials from your welcome email:

ssh root@your-server-ip

First command, always:

apt update && apt upgrade -y   # Debian/Ubuntu
yum update -y                  # AlmaLinux/CentOS/RHEL

Fresh VPS images are built from a base template that might be weeks or months old. Running unpatched packages on a box with a public IP is how you end up on a botnet by Friday. If the kernel gets updated, reboot once before moving on:

reboot

Step 2: Set the Hostname and Timezone

Small thing, saves confusion later when you're reading logs at 2 a.m. and every timestamp is in UTC while you're in IST.

hostnamectl set-hostname yourdomain-vps
timedatectl set-timezone Asia/Kolkata

Check it stuck with timedatectl and hostnamectl.

Step 3: Create a Non-Root User with SSH Keys

Never run your day-to-day work as root. Create a sudo user first:

adduser deploy
usermod -aG sudo deploy   # Debian/Ubuntu
usermod -aG wheel deploy  # AlmaLinux/CentOS

From your local machine, copy your public key over — don't type a password-based login into muscle memory:

ssh-copy-id deploy@your-server-ip

No key pair yet? Generate one locally first: ssh-keygen -t ed25519 -C "your-email". Then test that ssh deploy@your-server-ip logs you in without a password prompt before you touch anything else.

Step 4: Lock Down SSH

Once key-based login for your new user works, edit /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no
Port 2222

Changing the port isn't a real security boundary, but it does cut down on the constant noise from automated scanners hitting port 22. Restart the service and open a second SSH session before you close the first — if something's wrong with the config, you want a live session to fix it instead of being locked out.

systemctl restart sshd

Step 5: Turn on the Firewall

A VPS with no firewall is answering every port a scanner throws at it. Start with UFW (Ubuntu/Debian) or firewalld (AlmaLinux/CentOS) and allow only what you actually need:

ufw allow 2222/tcp   # your new SSH port
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Confirm the SSH rule is in before you enable it — enabling UFW with the wrong port allowed is the single most common way people lock themselves out of a brand-new VPS.

Step 6: Install Fail2Ban

Fail2Ban watches your auth logs and temporarily bans IPs that fail login attempts repeatedly. It's a five-minute install that quietly kills off brute-force attempts:

apt install fail2ban -y
systemctl enable --now fail2ban

The default jail for SSH is usually enough to start. You can tune ban times and retry thresholds later in /etc/fail2ban/jail.local.

Step 7: Add Swap (Especially on Smaller Plans)

If you're on a 1-2 GB RAM VPS, a swap file is cheap insurance against an out-of-memory kill during a package install or a traffic spike:

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab

Check it's active with free -h.

Step 8: Point DNS and Confirm It Resolves

While the server settles, update your domain's A record to the new VPS IP in your DNS zone (SkyServer's DNS panel, or wherever your nameservers point). Propagation is usually quick but can take a few hours depending on your previous record's TTL. Confirm with:

dig yourdomain.com +short

Step 9: Set Up Monitoring and Enable Backups

Don't wait for a disk-full alert from your users. At minimum:

• Enable automated snapshots or backups from your SkyServer control panel — a scheduled daily snapshot costs you nothing until you need it, and then it's the only thing that matters.
• Set up basic disk and memory alerting, even something as simple as a cron job that emails you when df -h crosses 80%.
• Note your server's baseline resource usage (htop, df -h) now, while it's idle, so you have something to compare against later when it feels slow.

Step 10: Only Now, Install Your Actual Stack

Web server, PHP, MySQL, Docker, whatever your project needs — install it last, on top of a server that's patched, firewalled, and backed up. It's a lot easier to layer an application onto a hardened box than to go back and harden a box that's already running production traffic and half-remembered config changes.

Quick Reference Table

Frequently Asked Questions

Do I really need to do all of this before installing my app?

You don't have to, but the order matters less than making sure it all gets done. Most of the incidents we see in the first week come from people who installed their app first and never circled back to secure the box.

What if I get locked out after changing the SSH port or disabling root login?

This is exactly why you keep a second SSH session open while making these changes. If you do get locked out, SkyServer's VPS control panel includes a browser-based console (VNC/serial) that bypasses SSH entirely so you can fix the config.

Is changing the SSH port actually necessary?

It's not a strong security measure on its own — treat it as noise reduction, not protection. The real protection comes from key-based auth, a firewall, and Fail2Ban. Skip the port change if it adds confusion to your workflow.

How much swap should I add?

A common rule of thumb is swap equal to your RAM for VPS plans under 2 GB, and a fixed 2-4 GB for anything larger. Swap is a safety net for spikes, not a substitute for right-sizing your plan.

My VPS came with a control panel already installed — do I still need this checklist?

Yes. A control panel like cPanel or Plesk handles a lot of this for you (firewall rules, backups), but you should still update packages, lock down root SSH login, and confirm backups are actually scheduled rather than assuming they are.