Your First 30 Minutes on a New VPS: The Setup Checklist

The moment a VPS finishes provisioning, you get an email with an IP address and not much else. There is no dashboard walking you through what to do next and no setup wizard, just a blank Ubuntu server with root access and a public IP that anyone on the internet can already see and probe. What you do in the first half hour determines whether that server becomes a stable place to run a site or a security incident waiting to happen.

On Arcadia's VPS plans, the server itself is ready within minutes of checkout: KVM virtualisation, dedicated NVMe storage, and no other customer's traffic spike eating into your CPU allocation. What happens after that confirmation email lands is still on you, and doing it in the right order matters more than doing it fast. This is the checklist, in the order that actually holds up once you start layering software on top.

Confirming What You Actually Have

SSH in for the first time using the root credentials from the setup email, and check what you are working with before changing anything else on the server.

nproc
free -h
df -h

Confirm the vCPU count, RAM, and disk allocation actually match the plan you ordered. A mismatch is far easier to sort out ten minutes after provisioning, before anything depends on the current setup, than a month later once cron jobs and a live database are running on top of it.

Locking Down Access Before Anything Else

Root login over a password is the single biggest risk sitting on a fresh VPS, and it is the first thing worth fixing. This means creating a non-root user with sudo privileges, generating an SSH key pair, copying the public key across, confirming key-based login works, and only then disabling both root login and password authentication entirely. The [Ubuntu 24.04 initial setup guide](https://arcadiaservers.com/guides/how-to-set-up-ubuntu-24-04-vps) walks through this whole sequence from first login onward, and the [SSH key authentication guide](https://arcadiaservers.com/guides/ssh-key-authentication-ubuntu) goes deeper on the key generation and troubleshooting side if anything does not connect on the first try.

Do not skip testing the new login before closing your original root session. If key-based access does not actually work and you have already disabled the fallback, you are locked out with no way back in short of a rebuild.

Putting a Firewall in Front of the Server

A default Ubuntu install accepts connections on every open port with no firewall in front of it. UFW takes a few commands to configure and closes off everything except the ports you actually intend to use, typically SSH and, once a web server is installed, HTTP and HTTPS. Pairing it with Fail2Ban adds automatic banning for IPs that repeatedly fail SSH logins, which matters more than it sounds like it should; a fresh server's SSH port gets scanned by bots within hours of going live, not weeks. The [UFW and Fail2Ban guide](https://arcadiaservers.com/guides/securing-vps-ufw-fail2ban) covers both.

Adding Swap So a Memory Spike Does Not Kill a Process

A VPS with 4GB of RAM has exactly 4GB of RAM, not an elastic pool that quietly expands under pressure. A brief spike from a backup running, a plugin update, or a traffic burst can push memory usage past what is physically available, and without swap space the kernel starts killing processes to recover, sometimes MySQL, sometimes PHP-FPM, sometimes the process you least want it to pick. A swap file gives the server room to absorb that spike instead of failing outright. The [guide to adding swap space on Ubuntu](https://arcadiaservers.com/guides/add-swap-space-ubuntu-vps) sizes it correctly for the RAM you have and sets swappiness so it does not get used more aggressively than intended.

Pointing Your Domain While the Rest Finishes

DNS propagation can take anywhere from a few minutes to a few hours depending on the registrar and the previous TTL on the record, so it is worth starting this early rather than leaving it until the server is fully configured and you are ready to go live. Create an A record pointing your domain at the VPS's IP address now, and by the time you have finished the rest of this checklist, it will likely have already propagated. The [guide to pointing a domain at your VPS](https://arcadiaservers.com/guides/point-domain-to-vps-dns-a-records) covers creating the record and verifying it resolves correctly with dig.

Deciding What You Are Actually Deploying

With access locked down, a firewall in place, swap configured, and DNS already propagating, the server is ready for whatever you are actually putting on it. For WordPress specifically, the [guide to deploying WordPress with Nginx and PHP-FPM](https://arcadiaservers.com/guides/deploy-wordpress-nginx-php-fpm) takes you from a bare server to a working install on Ubuntu 24.04, and if you are weighing Nginx against Apache first, [LAMP vs LEMP](https://arcadiaservers.com/blog/lamp-vs-lemp-wordpress-vps) breaks down which stack actually fits a resource-constrained VPS better.

What Can Wait

Not everything needs to happen in the first thirty minutes. Object caching with Redis, PHP-FPM pool tuning, automated security updates, and disk space monitoring all matter, but none of them are the difference between a server that is safe to leave running unattended and one that is not. Access control, a firewall, and swap are the three things that turn a blank VPS into something you can safely build on; everything else is optimisation that can happen once there is actually a site running to optimise.

Frequently Asked Questions

Do I need to do all of this before installing WordPress?

Access control and the firewall should come first; installing WordPress on a server that is still using root-over-password login just means the site is exposed the moment it goes live. Swap and DNS can technically happen in parallel with the WordPress install itself, but doing them first means one less thing to remember once you are focused on getting the site configured correctly.

How long should initial VPS setup actually take?

Following the checklist above end to end, excluding DNS propagation time, takes most people 30 to 45 minutes on a server they have set up before, and closer to an hour the first time through if you are reading each guide as you go. That is a reasonable amount of time to spend once, since a rushed setup that skips the firewall or leaves root login open is the kind of shortcut that tends to cost far more time later.

What is the biggest mistake people make with a new VPS?

Leaving root SSH login enabled with password authentication because the server feels new and low-priority, then installing a site on it before coming back to security later. Automated scanning bots do not care how new the server is or how little is running on it yet; an exposed SSH port gets probed within hours, and "later" has a way of never quite arriving once a working site is running on top.