September 10, 2026
11 min read
By Kokil Thapa | Last reviewed: September 2026
You provision a new droplet, spin up an EC2 instance, or click deploy on a Nepal hosting panel — and within hours bots start probing port 22. Initial Ubuntu Server Setup: Secure a Fresh VPS in 20 Minutes is the baseline every production stack needs before PHP, Nginx, or Laravel ever touch the box. I've run this exact sequence on shared EC2 hosts that power multiple Deployer 7 deployments for legal-tech and booking sites. The goal is not perfection on day one. The goal is closing the obvious holes fast, then layering monitoring and backups next.
Quick answer: Initial Ubuntu Server Setup: Secure a Fresh VPS in 20 Minutes means updating packages, creating a sudo user with SSH keys, disabling root login, enabling UFW and fail2ban, setting timezone and automatic security updates — before installing any application stack.
What Does Initial Ubuntu Server Setup Secure on a Fresh VPS?
A factory-fresh Ubuntu 22.04 or 24.04 VPS ships with root SSH access, every port open, and no intrusion detection. That is fine for five minutes. It is dangerous for production.
Your first pass should address four attack surfaces: authentication, network exposure, software currency, and audit visibility. Authentication means keys instead of passwords. Network exposure means a default-deny firewall. Software currency means patched packages. Audit visibility means knowing who changed what.
On client projects I maintain through Linux system administration, skipping this baseline is the single most common reason a small business gets compromised before launch. The apps on production Laravel booking systems depend on this layer holding steady underneath them.
The table below maps each baseline step to what it actually stops. Use it as your checklist when onboarding a new VPS for web application hosting.
| Setup step | Threat reduced | Typical time |
|---|---|---|
| Package updates | Known CVE exploitation | 2–4 min |
| Sudo user + SSH keys | Password brute force | 3–5 min |
| Disable root SSH | Direct root compromise | 1 min |
| UFW default deny | Port scanning, service exposure | 2 min |
| fail2ban | Repeated auth attempts | 3 min |
| Automatic security updates | Delayed patching | 2 min |
| Timezone + NTP | Log correlation failures | 1 min |
How Do You Run Initial Ubuntu Server Setup in 20 Minutes?
Log in as root once. Every step after that uses a sudo user. Keep a second SSH session open while editing SSH config — lock yourself out once and you will never forget this rule.
Step 1: Update the system (minutes 0–4)
Connect with your provider's root credentials or initial SSH key. Run a full update before anything else.
ssh root@YOUR_SERVER_IP
apt update && apt upgrade -y
apt autoremove -y
apt install -y curl wget git unzip software-properties-commonReboot only if the kernel was upgraded and your provider recommends it. On Ubuntu 24.04 LTS with PHP 8.3 or 8.5 workloads, a quick reboot after kernel updates prevents odd behaviour later. See the Ubuntu security updates guide for unattended upgrade options.
Step 2: Create a sudo user (minutes 4–8)
Never run daily work as root. Create a named user, add to the sudo group, and copy your public key.
adduser deploy
usermod -aG sudo deploy
rsync --archive --chown=deploy:deploy ~/.ssh /home/deployTest the new account in a separate terminal before closing root access.
ssh deploy@YOUR_SERVER_IP
sudo whoamiGenerate keys locally if you do not have them. Use strong passphrases on private keys — keys without passphrases are stolen-key incidents waiting to happen.
Step 3: Harden SSH (minutes 8–12)
Edit the server SSH daemon config. These settings match what I deploy on production hosts running Apache or Nginx with PHP-FPM.
sudo nano /etc/ssh/sshd_configSet these values (uncomment or add as needed):
PermitRootLogin noPasswordAuthentication noPubkeyAuthentication yesMaxAuthTries 3AllowUsers deploy(replace with your username)
Validate and reload:
sudo sshd -t
sudo systemctl reload sshdFull SSH hardening patterns are covered in Ubuntu server security best practices and the dedicated Nepal-focused server security article.
Step 4: Set timezone and hostname (minutes 12–14)
Nepal-hosted projects should use Asia/Kathmandu. Global clients may prefer UTC for log alignment across regions.
sudo timedatectl set-timezone Asia/Kathmandu
sudo hostnamectl set-hostname prod-web-01
timedatectlAccurate timestamps matter when correlating fail2ban bans with server monitoring alerts.
Step 5: Configure automatic security updates (minutes 14–16)
Install unattended-upgrades so security patches apply without manual intervention.
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgradesConfirm the config enables security origins:
cat /etc/apt/apt.conf.d/50unattended-upgrades | grep -i securityThe official Ubuntu Server package management documentation explains origin patterns if you run custom repositories.
Which Firewall Rules Secure a Fresh VPS After Ubuntu Server Setup?
UFW (Uncomplicated Firewall) wraps iptables with sane defaults. Enable it only after allowing SSH — otherwise you lock yourself out immediately.
Basic UFW profile for web servers
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verboseThat profile suits a standard LEMP or LAMP host. If you run a non-standard SSH port, allow that port instead of OpenSSH. Document the port in your runbook.
For deeper rule design, read server hardening for Ubuntu web servers. Restrict MySQL port 3306 and Redis 6379 to localhost only — never expose them on a public VPS.
Install and configure fail2ban
fail2ban watches auth logs and bans IPs after repeated failures. Install it right after UFW.
sudo apt install -y fail2ban
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.localMinimum settings under the [sshd] section:
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600sudo systemctl enable fail2ban
sudo systemctl start fail2ban
sudo fail2ban-client status sshdExtended jail configs for Nginx and Apache appear in the fail2ban configuration guide.
What Extra Steps Secure a Fresh VPS Beyond the First 20 Minutes?
The 20-minute window gets you safe enough to install software. Production readiness needs a second pass within the same day.
Swap and kernel limits
Small VPS plans (1 GB RAM, common at Rs 800–1,500/month or ~USD 6–11 from Nepal providers) need swap to survive Composer or npm builds. Add 1–2 GB swap on low-memory boxes.
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstabProvider firewall vs UFW
Cloud providers like DigitalOcean, Hetzner, and AWS offer network-level firewalls. Use both. Provider rules block traffic before it hits your VPS. UFW protects you if someone misconfigures the cloud panel.
If you register domains and VPS through a single vendor, domain and hosting setup should document which firewall layer owns which rules.
Backups before app deploy
Snapshot the VPS after baseline hardening. Configure nightly database dumps once MySQL or PostgreSQL is installed. Patterns are in Ubuntu server backup strategies and automated backup setup.
I treat backups as part of deployment, not a later chore. Several sister sites on shared EC2 use the same baseline plus Deployer 7 — documented in Symfony deployment on Ubuntu VPS and Laravel on Ubuntu with Nginx.
SSL with Let's Encrypt
Once Nginx or Apache serves a domain, issue certificates with Certbot. The Certbot official instructions cover Ubuntu 24.04 with Nginx plugin installs.
sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.comAuto-renewal is handled by a systemd timer. Verify with sudo certbot renew --dry-run.
How Do You Verify Initial Ubuntu Server Setup on a Fresh VPS?
Run this verification script mindset as a final gate. Every item should pass before you install Laravel 13, WordPress 7.1, or any customer-facing code.
- SSH as root fails with "Permission denied"
- SSH as deploy user works with key only — password prompt never appears
sudo ufw statusshows active, default deny incomingsudo fail2ban-client statuslists sshd jail runningapt list --upgradableshows no pending security-critical packages- Only ports 22, 80, and 443 appear in
sudo ss -tulpnexternally - Timezone matches your operational region
- Provider snapshot or backup job is scheduled
External port scans from another machine confirm what the world sees:
nmap -Pn YOUR_SERVER_IPExpect SSH, HTTP, and HTTPS open. Everything else should be filtered or closed.
For command reference during verification, keep essential Ubuntu terminal commands bookmarked. File permission mistakes after deploy are covered in Ubuntu file permissions explained.
Compare your results against CIS benchmarks for server hardening when compliance matters. Most SMB sites in Nepal do not need full CIS compliance on day one. They do need the baseline this article describes.
Key Takeaways
- Run Initial Ubuntu Server Setup: Secure a Fresh VPS in 20 Minutes before installing PHP, Nginx, MySQL, or any application code.
- Create a sudo user with SSH keys, disable root login, and disable password authentication — test in a second session before closing root access.
- Enable UFW with default deny, allow only SSH/HTTP/HTTPS, then install fail2ban with a 3-strike SSH jail.
- Enable unattended security upgrades so patch lag does not become your weakest link.
- Snapshot the hardened VPS, then install your stack using the Nginx and PHP install guides.
- Schedule backups and monitoring the same day — baseline security without recovery plans is half a job.
People Also Ask
Should I use Ubuntu 22.04 or 24.04 for a new VPS in 2026?
Ubuntu 24.04 LTS is the better default for new projects in 2026. It ships with newer kernels and longer support runway. Ubuntu 22.04 remains valid for existing stacks — especially Laravel 12 on PHP 8.2 — but new VPS instances should start on 24.04 unless a package pins you to 22.04.
Is changing the SSH port worth it?
Moving SSH off port 22 reduces log noise from automated scanners. It does not replace key-based auth and UFW. If you change the port, update UFW, fail2ban jail port settings, and your provider's cloud firewall in the same session. Document the port for every team member.
Do I need both UFW and the cloud provider firewall?
Yes, in practice. The provider firewall blocks traffic at the hypervisor edge. UFW protects the OS if someone opens a port in the cloud panel by mistake. Defense in depth costs ten extra minutes and prevents painful incidents.
What comes immediately after securing a fresh Ubuntu VPS?
Install your web stack: Nginx or Apache, PHP-FPM 8.3+, MySQL 8.4 or PostgreSQL 18, Redis 8.10 if needed. Issue Let's Encrypt certificates. Deploy your app with Git-based workflows. Then add monitoring, log rotation, and automated backups before sending live traffic.
Ship Production Workloads on a Hardened Base
Initial Ubuntu Server Setup: Secure a Fresh VPS in 20 Minutes is the foundation every Laravel, WordPress, and custom API deployment I maintain builds on. The sequence is boring by design — updates, sudo user, SSH keys, UFW, fail2ban, auto-patches. Boring keeps client sites online through Dashain traffic spikes and routine bot scans.
If you want this baseline configured, monitored, and handed over with deployment pipelines already wired, review support and maintenance services or contact us with your VPS provider and stack details. For background on how I work, see about me and the Notary Kathmandu portfolio entry — one of several sites running on the same hardened Ubuntu baseline.
Frequently Asked Questions
Updating packages, creating a sudo user with SSH keys, disabling root login, enabling UFW and fail2ban, setting timezone, and enabling automatic security updates before installing any application stack.
About 20 minutes when you follow the baseline sequence: package updates, sudo user creation, SSH hardening, timezone setup, unattended security upgrades, UFW, and fail2ban.
Plans with around 1 GB RAM often run Rs 800–1,500 per month, roughly USD 6–11, from Nepal hosting providers — enough for a hardened baseline before Laravel or WordPress.
Ubuntu 24.04 LTS is the better default for new projects in 2026 because it ships with newer kernels and a longer support runway. Ubuntu 22.04 remains valid for existing stacks, especially Laravel 12 on PHP 8.2, but new VPS instances should start on 24.04 unless a specific package pins you to 22.04. I've used both on production hosts running Apache or Nginx with PHP-FPM, and the hardening steps in this article apply identically to either LTS release.
A factory-fresh Ubuntu VPS ships with root SSH access, which is the most direct path to full server compromise. Bots probe port 22 within hours of provisioning. Disabling root login forces attackers through a named sudo account protected by key-based authentication instead of a well-known username. On client projects I maintain, skipping this step is one of the most common reasons a small business gets compromised before launch. Set PermitRootLogin no in sshd_config only after confirming your sudo user works in a separate terminal session.
UFW should use default deny incoming, default allow outgoing, then explicitly allow OpenSSH, port 80/tcp, and port 443/tcp before you run ufw enable. Allow SSH first or you lock yourself out immediately. That profile suits a standard LEMP or LAMP host. If you run SSH on a non-standard port, allow that port instead of OpenSSH and document it in your runbook. Restrict MySQL port 3306 and Redis port 6379 to localhost only — never expose database or cache ports on a public-facing VPS during baseline hardening.
Yes, in practice. Cloud providers like DigitalOcean, Hetzner, and AWS offer network-level firewalls that block traffic at the hypervisor edge before it reaches your VPS. UFW protects the operating system if someone misconfigures the cloud panel and opens a port by mistake. Defense in depth costs roughly ten extra minutes during setup and prevents painful incidents. If you register domains and VPS through a single vendor, document which firewall layer owns which rules so future changes do not create gaps or duplicate blocks that break legitimate traffic.
Moving SSH off port 22 reduces log noise from automated scanners, but it does not replace key-based authentication, UFW default-deny rules, or fail2ban. Treat port changes as a minor hardening layer, not a substitute for the core baseline. If you change the port, update UFW rules, fail2ban jail port settings, and your provider's cloud firewall in the same session. Document the port for every team member and anyone who needs emergency access. I've seen teams change the port without updating fail2ban and wonder why bans stopped working.
Install fail2ban immediately after UFW, copy jail.conf to jail.local, and enable the sshd jail with maxretry set to 3, bantime 3600 seconds, and findtime 600 seconds. Point the jail at /var/log/auth.log and enable the service on boot. These settings align with MaxAuthTries 3 in your SSH config, giving consistent lockout behaviour across both layers. Verify with fail2ban-client status sshd after starting the service. Extended jail configs for Nginx and Apache can follow once your web stack is installed, but the SSH jail alone closes the most common fresh-VPS attack vector during the initial 20-minute window.
Keep a second SSH session open while editing sshd_config — lock yourself out once and you will never forget this rule. Create and test your sudo user in a separate terminal before disabling root access or password authentication. Run sshd -t to validate config syntax, then reload sshd rather than restarting blindly. Only after confirming ssh deploy@YOUR_SERVER_IP works with your key and sudo whoami returns root should you close the root session. Provider console access is your last-resort recovery option, but fixing a broken SSH config through a web terminal under pressure wastes time you should spend deploying.
Nepal-hosted projects should use Asia/Kathmandu via timedatectl set-timezone. Global clients may prefer UTC for log alignment across regions. Accurate timestamps matter when correlating fail2ban bans with server monitoring alerts — if your VPS clock drifts or uses the wrong zone, tracing an intrusion attempt across auth logs and application logs becomes unreliable. Set the hostname at the same time with hostnamectl so your server is identifiable in multi-host deployments. I run this step on shared EC2 hosts powering multiple Deployer 7 deployments, and consistent timezone configuration saves hours during incident review.
Run through a final gate checklist before installing Laravel 13, WordPress 7.1, or any customer-facing code. SSH as root must fail with permission denied. SSH as your deploy user must work with keys only — no password prompt. sudo ufw status should show active with default deny incoming. fail2ban-client status must list the sshd jail running. apt list --upgradable should show no pending security-critical packages. Only ports 22, 80, and 443 should appear externally. Run nmap -Pn YOUR_SERVER_IP from another machine to confirm what the world sees. Schedule a provider snapshot before moving to application installation.
Install your web stack next: Nginx or Apache, PHP-FPM 8.3 or higher, MySQL 8.4 or PostgreSQL 18, and Redis 8.10 if your application needs caching. Issue Let's Encrypt certificates with Certbot once a domain points at the server — auto-renewal runs via a systemd timer, verifiable with certbot renew --dry-run. Deploy your application using Git-based workflows such as Deployer 7. Add monitoring, log rotation, and automated backups before sending live traffic. The 20-minute hardening window gets you safe enough to install software; production readiness requires TLS, backups, and monitoring within the same day.
No. MySQL port 3306 and Redis port 6379 should be restricted to localhost only and never exposed on a public VPS. UFW default-deny rules during Initial Ubuntu Server Setup should allow only SSH, HTTP, and HTTPS externally. Database and cache services bind to internal addresses and communicate with your application over the loopback interface. Exposing them invites automated scanning and direct data theft within minutes of provisioning. If you need remote database access for administration, use an SSH tunnel rather than opening port 3306 to the internet. This is basic network hygiene before any Laravel or WordPress installation touches the box.
Add 1–2 GB swap on low-memory VPS plans to survive Composer or npm builds without OOM kills. Snapshot the hardened VPS before installing application code, then configure nightly database dumps once MySQL or PostgreSQL is running. Enable both provider-level and UFW firewalls for defense in depth. Issue SSL certificates with Certbot after Nginx or Apache serves your domain. Schedule monitoring and log rotation the same day — baseline security without recovery plans is half a job. I treat backups as part of deployment, not a later chore, and several production sites on shared EC2 use this same baseline before Deployer 7 handles application releases.
0 Comments
Leave a comment
Your email is not published. Comments appear once they have been read. Sign in to have your details filled in.
