Your First Hour on a Hostlas VPS: Hardening and Baseline Setup

A freshly provisioned VPS is a blank, internet-facing server with root access and nothing hardened yet. What you do in the first hour determines whether that server stays yours or becomes a target. This guide walks through the exact baseline setup every Hostlas KVM VPS should get before you deploy anything real on it.

Why the first hour matters

Hostlas VPS plans include full root access, which is exactly what gives you the flexibility to run any stack you want — but it also means you, not a shared-hosting control panel, own patching, firewall rules, and account hygiene from the moment the server boots. Automated scanners on the internet start probing new IP addresses within minutes of them coming online, so the sooner you complete baseline hardening, the smaller your exposure window.

Step 1: Connect and confirm access

• Retrieve your root credentials or SSH key from the Hostlas VPS dashboard
• Connect via SSH: ssh root@your-server-ip
• Confirm the OS image and version match what you selected at provisioning
• Run a basic system update immediately (apt update && apt upgrade on Debian/Ubuntu, or the equivalent for your distro) before doing anything else

Step 2: Create a non-root sudo user

Operating as root for daily tasks is unnecessary risk — a single mistyped command has no safety net. Instead:

• Create a new user: adduser yourusername
• Grant sudo privileges: usermod -aG sudo yourusername
• Log out and reconnect as the new user to confirm access works before disabling anything on the root account
• From this point forward, use sudo for privileged commands rather than staying logged in as root

Step 3: Lock down SSH access

• Generate an SSH key pair locally if you don't already have one, and copy the public key to the server (ssh-copy-id or manual ~/.ssh/authorized_keys setup)
• Test key-based login in a new terminal session before disabling anything, so you don't lock yourself out
• Once key-based login is confirmed working, disable password authentication in /etc/ssh/sshd_config (PasswordAuthentication no)
• Disable direct root SSH login (PermitRootLogin no) now that you have a sudo user
• Restart the SSH service and reconnect in a fresh session to confirm the new settings work correctly

Step 4: Enable a firewall

A firewall that only allows the ports you actually need is one of the single highest-impact security steps available:

• Install and enable a firewall tool (ufw is a straightforward option on Debian/Ubuntu)
• Allow SSH explicitly first — on a non-default port if you've changed it, so you don't cut off your own access
• Allow only the ports your application actually needs (commonly 80/443 for a web server)
• Deny everything else by default
• Enable the firewall and immediately test that you can still connect via SSH before closing your current session

Step 5: Set up basic monitoring and alerts

• Enable automatic security updates for critical patches where your distro supports it, so known vulnerabilities get patched without manual intervention
• Set up a basic intrusion-prevention tool (such as fail2ban) to automatically block IPs after repeated failed login attempts
• Check the Hostlas VPS dashboard for built-in resource monitoring (CPU, RAM, disk, bandwidth) and note the baseline usage while the server is idle, so future spikes are easy to spot

Step 6: Take a snapshot before real experimentation

Once the baseline above is complete and confirmed working, take a snapshot from the Hostlas VPS dashboard. This gives you a clean, known-good restore point before you:

• Install your application stack (web server, database, runtime)
• Experiment with configuration changes
• Deploy anything untested

Snapshotting again before any major change (a risky upgrade, a new service, a config overhaul) is a habit that turns "I broke the server" into a five-minute rollback instead of a rebuild from scratch.

Common first-day mistakes to avoid

• Skipping the firewall because "I'll do it later." Later is often after the first scan finds an open port.
• Disabling password SSH before confirming key-based login works. Test the new method in a separate session before removing the old one.
• Running everything as root out of convenience. A sudo user with a properly locked-down root account is a small extra step with a large safety payoff.
• Never snapshotting. Without a restore point, a bad config change or failed upgrade can mean rebuilding the server from zero.
• Ignoring update notifications. Unpatched software is one of the most common ways VPS instances get compromised.

Quick checklist for the first hour

• [ ] System packages updated
• [ ] Non-root sudo user created and tested
• [ ] SSH key-based login confirmed working
• [ ] Password authentication and root SSH login disabled
• [ ] Firewall enabled with only necessary ports open
• [ ] Automatic security updates and basic intrusion prevention configured
• [ ] Clean snapshot taken before installing your application stack

Choosing the right VPS size

If you're not sure which plan fits your workload, see Hostlas VPS for the full range of plan sizes and specs, and compare against your expected CPU, RAM, and storage needs before committing to a tier — you can typically resize later, but starting close to right saves a migration step down the line. Broader hosting comparisons are available on the pricing page if you're deciding between VPS and a managed hosting plan.

Getting help

If anything in this checklist doesn't go as expected — SSH won't connect after a config change, or the firewall blocks something unexpectedly — Hostlas support can assist with VPS-level troubleshooting. Since you have full root access, support can guide you through fixes, but you retain control of the server throughout.

A disciplined first hour is the cheapest security investment you'll make on a VPS. Everything after this point is easier to build correctly on a hardened foundation.