After running test workloads across five VPS providers over six months, I saw the same configuration and management mistakes repeated across customer setups. These errors don't just slow things down—they break deployments, expose security holes, and turn a $10/month VPS into a liability.
Here's what actually goes wrong and how to fix it.
Mistake 1: Running production without a firewall
The default VPS image ships with every port open to the internet. SSH on 22, MySQL on 3306, Redis on 6379—everything visible to anyone scanning your IP block.
I've handled tickets where attackers found exposed databases within hours of deployment. The correct approach: enable a firewall before you install anything else.
On Ubuntu or Debian with UFW:
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
On CentOS or AlmaLinux with firewalld:
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
Whitelist only the ports your application actually needs. Database ports, cache servers, and admin panels should never face the public internet directly.
Mistake 2: Skipping automated backups
Provider snapshots aren't backups. A snapshot lives on the same infrastructure as your VPS—if the provider has an outage or your account gets compromised, you lose both.
Set up automated offsite backups to a different provider or region. Here's a daily backup script that copies critical files and databases to S3-compatible storage:
#!/bin/bash
BACKUP_DATE=$(date +%Y%m%d)
BACKUP_DIR="/tmp/backup-${BACKUP_DATE}"
mkdir -p "${BACKUP_DIR}"
# Dump all MySQL databases
mysqldump --all-databases -u root -p"${DB_PASSWORD}" > "${BACKUP_DIR}/databases.sql"
# Copy web root and configs
tar -czf "${BACKUP_DIR}/www.tar.gz" /var/www
tar -czf "${BACKUP_DIR}/configs.tar.gz" /etc/nginx /etc/apache2 /etc/php
# Upload to S3
aws s3 sync "${BACKUP_DIR}" "s3://your-bucket/vps-backups/${BACKUP_DATE}/"
# Clean up
rm -rf "${BACKUP_DIR}"
Run it via cron at 2 AM daily. Test restoration at least once a quarter—I've seen teams discover their backup scripts broke months earlier only after data loss forced a restore attempt.
Mistake 3: Ignoring swap configuration
Most VPS images ship without swap or with a tiny swap file. The moment your application's memory usage spikes above available RAM, the kernel OOM killer starts terminating processes.
Your web server dies. Your database dies. Your monitoring agent dies so you don't even get an alert.
Create a swap file sized to your workload—typically 1-2 GB for a 2 GB VPS:
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/fstab
Set swappiness lower than the default to prefer using RAM:
sudo sysctl vm.swappiness=10
echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf
Swap won't fix an undersized VPS, but it buys you time to investigate before everything crashes.
Mistake 4: Using root for everything
Logging in as root for daily tasks means every command, script, and typo runs with full system privileges. One misplaced rm -rf can wipe your entire filesystem.
Create a regular user with sudo access:
adduser yourname
usermod -aG sudo yourname
Then disable root SSH login. Edit /etc/ssh/sshd_config:
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
Reload SSH:
sudo systemctl reload sshd
Before you disable root login, confirm you can SSH as your regular user and run sudo commands. I've locked people out of their own VPS by applying this change without testing first.
Mistake 5: Not monitoring disk space
Log files, package caches, and database binlogs will fill your disk. When you hit 100% usage, nothing works—SSH hangs, databases refuse writes, systemd can't start services.
In support tickets I handled, the usual culprit was a full disk that looked fine a week earlier. Set up monitoring before you need it:
sudo apt install mailutils
Add this script to /usr/local/bin/check-disk.sh:
#!/bin/bash
USAGE=$(df -h / | awk 'NR==2 {print $5}' | sed 's/%//')
if [ "$USAGE" -gt 80 ]; then
echo "Disk usage is ${USAGE}% on $(hostname)" | mail -s "Disk Alert" [email protected]
fi
Run it hourly:
sudo chmod +x /usr/local/bin/check-disk.sh
(crontab -l 2>/dev/null; echo "0 * * * * /usr/local/bin/check-disk.sh") | crontab -
Or use a proper monitoring stack like Netdata or Prometheus. The specific tool matters less than having alerts configured before the disk fills.
So what if you've already hardened SSH but attacks keep coming?
Mistake 6: Leaving SSH on port 22
Changing the SSH port doesn't improve security in theory. In practice, it drops automated bot traffic by 90%+.
Your auth logs stop filling with failed login attempts from Chinese IP blocks. Your server spends fewer cycles rejecting garbage connections.
Edit /etc/ssh/sshd_config:
Port 2222
Update your firewall:
sudo ufw delete allow 22/tcp
sudo ufw allow 2222/tcp
sudo ufw reload
Reload SSH:
sudo systemctl reload sshd
Connect with ssh -p 2222 user@your-vps-ip. Pick any unused port above 1024. Don't lock yourself out—test the new port in a second terminal before closing your current session.
Mistake 7: Running outdated software
Unpatched packages contain known vulnerabilities that show up in automated scans. Attackers use public exploit databases to compromise systems running old versions of OpenSSL, PHP, or kernel modules.
Enable automatic security updates. On Ubuntu:
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
On CentOS/AlmaLinux:
sudo yum install yum-cron
sudo systemctl enable yum-cron
sudo systemctl start yum-cron
Edit /etc/yum/yum-cron.conf and set:
apply_updates = yes
You'll still need to manually reboot for kernel updates, but automatic patching closes the window where your VPS runs vulnerable software between releases.
Mistake 8: Misconfiguring DNS or reverse DNS
Forward DNS points your domain to the VPS IP. Reverse DNS (PTR record) points the IP back to your domain. Email servers check both—if they don't match, your outbound mail gets flagged as spam.
Check your current rDNS:
dig -x YOUR_VPS_IP +short
If it returns a generic hostname like vps-123456.provider.com, set it to your actual mail domain. Most VPS control panels have a "Reverse DNS" or "PTR Record" setting. Enter your FQDN (like mail.yourdomain.com).
Wait an hour, then verify:
dig -x YOUR_VPS_IP +short
# Should return: mail.yourdomain.com.
Make sure the A record for that hostname points back to the same IP. Forward and reverse must agree.
Mistake 9: No rate limiting or fail2ban
Bots will hammer your SSH port, web forms, and API endpoints until something breaks or they brute-force a password. Without rate limiting, a single attacker can exhaust your connection limits.
Install fail2ban to automatically block IPs after repeated failures:
sudo apt install fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban
Create /etc/fail2ban/jail.local:
[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
[sshd]
enabled = true
port = 2222
[nginx-limit-req]
enabled = true
filter = nginx-limit-req
logpath = /var/log/nginx/error.log
Restart fail2ban:
sudo systemctl restart fail2ban
Check active jails:
sudo fail2ban-client status
This setup bans IPs for one hour after five failed attempts in ten minutes. Adjust the thresholds for your traffic patterns, but don't skip this step—it's the difference between manageable log files and constant attack noise.
What I learned testing five providers
The provider you choose matters less than how you configure what they give you. A cheap VPS locked down correctly will outlast an expensive one left at default settings.
Every mistake here showed up across multiple providers—none ship secure by default because they don't know your use case. The five minutes you spend enabling a firewall and setting up backups prevents hours of emergency recovery work later.
Start with the firewall and backups. Add monitoring and automated updates. Test your SSH hardening before you close your root session. Check your reverse DNS if you're sending email.
Those nine items will handle the bulk of what breaks in production.
Common questions
Do I need swap if I have enough RAM?
Yes, even as a safety buffer. Swap prevents the OOM killer from terminating processes during temporary spikes. Size it to 50-100% of your RAM.
Will changing the SSH port stop determined attackers?
No, but it stops the automated scanning noise that fills your logs and wastes CPU cycles. Combine it with key-based auth and fail2ban.
How often should I test backups?
Quarterly at minimum. Restore to a test VPS and confirm your application actually runs from the backup data.
Can I automate all security updates?
Security patches, yes. Major version upgrades need manual testing—they can break application dependencies. Review the changelog before applying large updates.
What's the minimum monitoring I need?
Disk space, memory usage, and service uptime. Everything else is optional until you know what metrics matter for your workload.
What to check first
If your VPS is already running, audit these nine items today. Fix the firewall and backups before anything else—they're the foundation.
After that, tackle SSH hardening, swap configuration, and monitoring. The rest can happen over the next week as you schedule maintenance windows.
Most of these fixes take under ten minutes each. The cumulative effect is the difference between a stable server and one that requires constant firefighting.