![9 VPS Hosting Mistakes That Kill Uptime [Solved]](/images/blog/9-vps-hosting-mistakes-that-kill-uptime-solved.jpg)
People upgrade from shared hosting to a VPS for the same reasons: they hit resource limits, need root access, or want isolation from noisy neighbors. The jump makes sense on paper. In practice, most first-time VPS users skip critical setup steps and end up with a server that costs more but performs worse or gets compromised within days.
I've handled hundreds of tickets where a client moved to VPS hoping for better performance and instead got a hacked server, a surprise overage bill, or a site that went down because nobody configured monitoring. The technology itself is solid. The mistakes are human and fixable.
Mistake 1: Skipping OS-level security hardening
Shared hosting comes with guardrails. VPS does not. When you deploy a fresh Ubuntu or AlmaLinux instance, SSH runs on port 22 with password auth enabled. Bots find it in minutes.
The correct approach:
- Change the SSH port to something above 1024.
- Disable password authentication; use SSH keys only.
- Install and configure
fail2banto block brute-force attempts. - Enable a firewall (ufw on Ubuntu, firewalld on RHEL-based) and close everything except your application ports.
Example for Ubuntu:
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp # your custom SSH port
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
In support tickets I handled, the usual culprit was a server provisioned by a developer who intended to "lock it down later" and forgot. Later never comes. Do it during initial setup.
Mistake 2: Running everything as root
Shared hosting forces you into a restricted user. VPS hands you root access, and new admins use it for everything—running web servers, installing packages, editing configs. One compromised script can then wipe the entire filesystem.
Create a non-root user with sudo privileges for day-to-day tasks. Run application processes under service accounts that own only the directories they need. For example, your web server should run as www-data or nginx, not root.
sudo adduser deploy
sudo usermod -aG sudo deploy
Then log in as deploy and use sudo only when required. If you're running Node.js, Python, or PHP apps, create dedicated service users:
sudo adduser --system --group appuser
sudo chown -R appuser:appuser /var/www/myapp
This limits the blast radius if something breaks or gets exploited.
Mistake 3: Not monitoring resource usage or setting up alerts
Shared hosting caps your CPU and RAM. Hit the limit and the host throttles you. VPS plans let you burst higher, but once you exceed your allocation the kernel starts killing processes. I've seen MySQL get OOM-killed during a traffic spike because nobody checked free -h or set up monitoring.
Install a lightweight monitoring agent. Options include:
- Netdata (real-time dashboard, easy install)
- Prometheus + Grafana (more complex, better for multiple servers)
- Cloud provider built-in tools (AWS CloudWatch, DigitalOcean Monitoring)
At minimum, configure email or Slack alerts for:
- Disk usage above 80%
- CPU load average > number of cores
- Memory usage above 90%
- Service restarts or crashes
A cron job that checks disk space and emails you if / or /var exceeds a threshold costs nothing and catches the most common issue:
#!/bin/bash
USAGE=$(df / | tail -1 | awk '{print $5}' | sed 's/%//')
if [ $USAGE -gt 85 ]; then
echo "Disk usage on / is ${USAGE}%" | mail -s "Disk Alert" [email protected]
fi
Run it daily via crontab. Adjust the threshold to your comfort level.
Mistake 4: Choosing the wrong plan size
People either under-provision ("the cheapest plan should be fine") or over-provision ("I'll take 16 GB just in case"). Both waste money or cause downtime.
Before you order, profile your current usage on shared hosting if the control panel exposes it. If not, make an educated guess:
- Static sites or small WordPress: 1 GB RAM, 1 vCPU
- WordPress with caching and moderate traffic: 2 GB RAM, 2 vCPU
- E-commerce, multiple sites, or database-heavy apps: 4 GB+ RAM, 2+ vCPU
Start one tier above your minimum estimate. It's easier to scale up than to troubleshoot an undersized server under load. Most VPS providers let you resize with a reboot; some charge pro-rated differences.
If you're moving from shared hosting because you kept hitting resource limits, the smallest VPS plan may still be too small. Check your current PHP memory limit and concurrent visitor count. A shared plan "unlimited" bandwidth at 100 Mbps can still saturate a 1 vCPU instance if you get a traffic spike.
Mistake 5: Forgetting to configure automated backups
Shared hosts usually include daily backups. VPS providers offer backups as an add-on or leave it entirely to you. I've restored sites for clients who assumed backups were automatic and then lost everything to a bad rm -rf or a ransomware infection.
Set up at minimum two layers:
- Snapshot-based backups through your provider (weekly or daily, retained for 7-30 days). These are fast and let you restore the whole server.
- File-level backups to offsite storage (S3, Backblaze, or a second VPS in another region). Use rsync, restic, or borg. Encrypt them.
Example rsync cron job to a remote backup server:
0 2 * * * rsync -avz --delete /var/www/ [email protected]:/backups/www/
Test your restore process quarterly. Backups you've never restored are theoretical.
Mistake 6: Not patching the OS and installed software
Shared hosting handles patches for you. On VPS you own the entire stack. An unpatched kernel, OpenSSH, or PHP version is an open door.
Enable automatic security updates. On Ubuntu:
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
On RHEL-based systems, configure yum-cron or dnf-automatic. This won't catch application-layer software like WordPress plugins or custom code, but it keeps the base OS and system packages current.
For web applications, subscribe to security mailing lists or RSS feeds for your stack (PHP, MySQL, Apache, Nginx). When a CVE drops, patch within 48 hours if it's remotely exploitable.
If you're running a control panel (cPanel, Plesk, CyberPanel), those usually have their own update mechanisms. Use them. A six-month-old control panel version likely has known exploits.
Mistake 7: Misconfiguring DNS during migration
Moving a site from shared to VPS means updating DNS. People either:
- Change the A record too early (before the new server is ready), causing downtime.
- Forget to update MX records, breaking email.
- Set TTL to something high (86400 seconds) and then wait a day to roll back a mistake.
The correct sequence:
- Build and test the site on the new VPS using the server's IP address or a temporary hosts file entry.
- Lower the DNS TTL for the domain to 300 seconds (5 minutes) at least 24 hours before the switch.
- Once the new server is confirmed working, update the A record to the new IP.
- Wait for propagation (usually under an hour with a low TTL).
- Verify email (MX), subdomains, and CDN integrations still point correctly.
- After a week of stability, raise the TTL back to 3600 or 7200.
Test email delivery separately. A misconfigured MX record or missing SPF/DKIM records can send your domain reputation into spam folders for weeks.
Mistake 8: Installing unnecessary services and leaving ports open
A default VPS image often includes services you don't need—Postfix listening on port 25, or a database server exposed to the internet. Every open port is an attack surface.
After your initial install, audit running services:
sudo systemctl list-units --type=service --state=running
sudo ss -tuln | grep LISTEN
Disable anything you don't recognize or don't need:
sudo systemctl stop postfix
sudo systemctl disable postfix
If you need a database, bind it to 127.0.0.1 so it only accepts local connections unless you're running a separate DB server. In MySQL or MariaDB:
[mysqld]
bind-address = 127.0.0.1
Restart the service and confirm:
sudo systemctl restart mysql
sudo ss -tuln | grep 3306
You should see 127.0.0.1:3306, not 0.0.0.0:3306.
Mistake 9: Not understanding the shared responsibility model
Shared hosting is managed. VPS is unmanaged unless you pay extra. People assume their provider will fix a hacked server or restore a deleted database. They won't.
Your provider is responsible for:
- Physical hardware and network uptime
- Hypervisor security
- Replacing failed drives
You are responsible for:
- OS and software patches
- Firewall and SSH configuration
- Backups
- Application security
- Performance tuning
If you're not comfortable with command-line Linux administration, either:
- Pay for managed VPS (the provider handles OS updates, security, and monitoring).
- Hire a sysadmin on retainer.
- Use a control panel that abstracts common tasks.
Managed VPS costs more but saves you from the mistakes in this article. Unmanaged VPS is cheaper but demands time and knowledge. Know which you signed up for.
So when does VPS make sense over shared?
Choose VPS when:
- You consistently max out shared hosting resource limits.
- You need root access to install custom software or modify system configs.
- You're running multiple sites and want isolation.
- You need a dedicated IP for SSL or application requirements.
- You've outgrown the CPU, RAM, or I/O performance of shared hosting.
Stay on shared hosting if:
- You're running a single low-traffic WordPress site.
- You don't have Linux sysadmin skills or budget for management.
- Your host offers enough resources and you're not hitting limits.
Shared hosting is easier and cheaper until it isn't. VPS is more powerful and flexible but demands more from you.
What about managed WordPress hosting vs VPS?
Managed WordPress hosts (WP Engine, Kinsta, Cloudways) give you VPS-like resources with the simplicity of shared. You get isolation, staging environments, and automatic updates without touching the command line. The tradeoff is cost and WordPress-only. If you need non-WordPress apps or prefer full control, VPS is still the better pick.
Can I run a VPS without a control panel?
Yes, and you'll save the license cost and RAM overhead. Pure command-line management is common for developers. If you need a GUI, open-source panels like Webmin, VestaCP, or HestiaCP work fine. Paid options like cPanel or Plesk add support and polish but cost monthly.
How do I migrate from shared to VPS without downtime?
Build the entire site on the VPS while DNS still points to the old shared host. Test thoroughly. Lower DNS TTL. Switch the A record and monitor. Keep the old shared hosting active for a billing cycle in case you need to roll back. Once stable, cancel the old plan.
What's the biggest single mistake to avoid?
Leaving SSH open with password auth and no firewall. That's how most compromises start. Fix that first, then work through the rest of this list.
What to check first
Most VPS failures trace to skipped basics—hardening SSH, enabling a firewall, setting up monitoring, and understanding that nobody will manage your server for you unless you paid for that service.
Shared hosting is training wheels. VPS is a real bike. You can go faster and farther, but you can also crash hard if you skip the safety checks. Walk through each mistake in this list during your first week on a new VPS and you'll avoid the tickets I see most often.
If you make one mistake from this list, you'll probably recover. If you make three or four, you'll spend more time fixing problems than you saved by moving off shared hosting. Take the time upfront.