Every time I provision a new VPS — whether it's for a client project or another one of my own products — I run through the same sequence. Writing it down once means I stop reinventing it, and it means the server ends up reasonably hardened instead of "we'll secure it later."
This assumes a fresh Ubuntu 22.04 or 24.04 droplet/instance from any provider (DigitalOcean, UpCloud, Vultr, Worldstream — the steps are identical) and aaPanel as the control panel.
Before you start
Have these ready: the server's IP address, root password or SSH key, and the domain name you plan to point at it (you can do this step later, but DNS propagation takes time, so starting it early saves waiting at the end).
Step 1: First login and updates
ssh root@your_server_ip
apt update && apt upgrade -y
Reboot if the kernel was updated. This alone closes a surprising number of known vulnerabilities that exist purely because a base image sat unpatched for months in a provider's template library.
Step 2: Create a non-root user
adduser deploy
usermod -aG sudo deploy
You'll still use root for the initial aaPanel install, but every day-to-day task afterward should go through a sudo user. Running everything as root is how one mistyped command turns into a full reinstall.
Step 3: Lock down SSH
Copy your public key to the new user, confirm you can log in as deploy, and only then edit /etc/ssh/sshd_config:
PermitRootLogin no
PasswordAuthentication no
Port 2222
Changing the default port doesn't stop a targeted attacker, but it eliminates well over 90% of the automated scanning noise that fills your auth logs. Restart SSH after editing, and test the new connection before closing your existing session — locking yourself out is the single most common self-inflicted VPS disaster.
Step 4: Install aaPanel
Run the official install script from aaPanel's documentation site (always fetch it fresh rather than reusing an old copy, since the URL and script are updated periodically). The installer will print your panel URL, port, username, and password at the end — save these immediately, ideally in a password manager, not a text file on your desktop.
Step 5: Firewall and panel port
Inside aaPanel, enable the built-in firewall (or use ufw directly) and allow only the ports you need: 80, 443, your custom SSH port, and the aaPanel port itself. Better still, restrict the panel port to your own IP address if it's static, or put it behind a VPN. The admin panel is the single juiciest target on the box — treat it that way.
Step 6: Install your stack
From the aaPanel "App Store," install whatever your application needs — Nginx, MySQL or PostgreSQL, PHP, or Node.js via the PM2 manager module. Resist the urge to install everything "just in case." Every extra running service is another thing to patch and another potential attack surface.
Step 7: Point your domain and get SSL
Create an A record pointing your domain to the server's IP, add the site inside aaPanel's website manager, then request a free Let's Encrypt certificate from the SSL tab. Enable "force HTTPS" once it issues. See our Let's Encrypt auto-renewal guide if the certificate doesn't renew cleanly the first time — it's almost always a DNS or port-80 accessibility issue.
Step 8: Basic backups before you go live
Before you put anything real on the server, set up at least one automated backup destination (aaPanel supports pushing backups to cloud storage directly from the panel). Do this now, not after the first incident — see our backup strategy guide for a setup that won't need daily babysitting.
Frequently asked questions
Do I need a static IP before starting this checklist?
Most VPS providers assign a static IP to your instance by default, so you typically don't need to request anything extra. Confirm it in your provider's dashboard before pointing DNS at it — a small number of budget plans use dynamic IPs, which would break this setup.
What if my domain's DNS hasn't propagated by the time I try to issue SSL?
Let's Encrypt's HTTP validation requires your domain to already resolve to the server. If DNS hasn't propagated yet, wait — propagation is usually done within minutes to a few hours — and retry the SSL request rather than troubleshooting the server itself, since the server side is almost never the actual problem in this scenario.
Can I follow these same steps on a provider other than the ones mentioned?
Yes — every step here is Ubuntu and aaPanel behavior, not provider-specific behavior, so it applies identically on any VPS provider that offers a plain Ubuntu image, which is effectively all of them.