VPS hosting security checklist for 2026: practical hardening for WordPress, LAMP, and Nginx servers

Your VPS rarely gets compromised because of one “clever hack.” Most incidents still start with boring gaps: an SSH port open to the world, weak passwords, stale packages, writable web directories, or backups that were never tested.

This VPS hosting security checklist is written for 2026 reality. It targets WordPress, typical LAMP stacks, and Nginx + PHP-FPM.

It also assumes you’re busy and can’t afford to skip fundamentals.

This is a guide, not a strict runbook. You’ll get a prioritized set of controls, what “good” looks like, and fast ways to confirm you’re actually there.

If you need a baseline build-out first, start with our Linux VPS setup checklist, then come back here to tighten things up.

What this VPS hosting security checklist covers (and what it doesn’t)

This checklist assumes a single VPS running Ubuntu 24.04 LTS / Debian 12 / AlmaLinux 9 or 10 / Rocky Linux 9, hosting one or more websites. It fits common setups: Apache + PHP, Nginx + PHP-FPM, OpenLiteSpeed/LiteSpeed, plus MySQL/MariaDB or PostgreSQL.

It skips enterprise patterns that don’t translate well to small hosting environments. No service mesh. No Kubernetes.

Instead, you get controls that cut risk quickly. You also get practices that keep the server stable through updates and traffic spikes.

• Goal: reduce attack surface, prevent trivial takeovers, and detect problems early.
• Constraint: you can’t babysit a server daily.
• Tradeoff: prefer predictable, boring defaults over clever custom setups.

Priority 1: lock down SSH so it stops being your biggest risk

If you do only one thing this week, do this. SSH is your front door, and internet-wide scanning runs 24/7.

The goal isn’t “no brute force attempts.” The goal is “brute force doesn’t matter.”

Use key-based login only, then turn off passwords

On Ubuntu/Debian, SSH config lives in /etc/ssh/sshd_config. Optional overrides live in /etc/ssh/sshd_config.d/*.conf.

Use an override file so package updates don’t turn into merge work.

# /etc/ssh/sshd_config.d/99-hardening.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
AuthenticationMethods publickey

Reload safely:

sudo sshd -t && sudo systemctl reload ssh

Keep admin access, but reduce exposure

• Create a non-root admin user and grant sudo.
• Restrict who can log in with AllowUsers or AllowGroups.
• Limit SSH to trusted IPs if you have stable office/home IPs (best), or at least rate-limit with a firewall.

Quick verification commands:

ss -tulpn | grep ':22'
sudo sshd -T | egrep 'passwordauthentication|permitrootlogin|authenticationmethods'

If you’re starting from scratch and want a clean base without spending a weekend on server chores, a HostMyCode VPS gives you full control for proper hardening (firewall rules, SSH keys, monitoring) without shared-host limits.

Priority 2: firewall rules that match how your server actually works

A firewall is table stakes on a VPS. For most web servers, the right default is simple: allow outbound, and allow only required inbound ports.

Recommended inbound policy for a typical web server

• Allow: 80/tcp (HTTP)
• Allow: 443/tcp (HTTPS)
• Allow: 22/tcp (SSH) from your IPs if possible
• Block everything else inbound

On Ubuntu, UFW is a practical front-end. Example:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw enable
sudo ufw status verbose

On AlmaLinux/Rocky, you’ll usually use firewalld:

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10" service name="ssh" accept'
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

Two common mistakes to avoid

• Accidentally exposing databases. MySQL (3306) and PostgreSQL (5432) should not be open to the public internet on a single-node web stack.
• Opening “temporary” admin ports and forgetting them for months. If you must open something briefly, set a calendar reminder and remove it the same day.

Priority 3: patching that doesn’t take your site down

Most “security work” outages come from risky upgrades, not from installing security fixes. You can stay current and stay predictable.

Pick a stable OS release. Then automate updates with guardrails.

What “good” looks like in 2026

• Regular security updates installed automatically.
• Reboots controlled (not random) and communicated if you run a business site.
• Kernel live patching is a nice-to-have, not a substitute for maintenance.

If you want a production-friendly approach, see our write-up on Linux VPS automated patch management. It covers unattended updates, reboot windows, and how to avoid surprise downtime.

Quick checks you can run today

# Debian/Ubuntu
apt-cache policy openssl | head
sudo unattended-upgrades --dry-run --debug | tail -n 30

# RHEL family
sudo dnf check-update | head

Priority 4: web stack hardening that stops common takeovers

Attackers rarely start at the kernel. They usually start in the app layer: WordPress, PHP settings, or a writable directory that lets them drop a web shell.

The fix is unglamorous, but effective. Tighten permissions, disable unsafe behavior, and stop your web server from oversharing.

File ownership and permissions: boring, effective, and often wrong

For WordPress, a common secure pattern is: files owned by a deploy user (or root), web server has read access, and only wp-content/uploads is writable by the web server.

Avoid making the entire webroot writable by www-data (or apache).

• Typical webroot paths: /var/www/example.com (manual), /home/USER/public_html (cPanel/DirectAdmin)
• Nginx config: /etc/nginx/sites-available/, enabled via /etc/nginx/sites-enabled/
• Apache vhosts: /etc/apache2/sites-available/ (Debian/Ubuntu) or /etc/httpd/conf.d/ (RHEL family)

Quick diagnostic: look for writable PHP files. This catches a lot of “I didn’t know we set it up like that” installs.

sudo find /var/www -type f -name "*.php" -perm -0002 -print

PHP hardening that doesn’t break real sites

In 2026, PHP 8.2/8.3/8.4 are common depending on the distro and control panel. Specific settings vary, but the goal stays the same.

• Disable risky functions where possible (careful: some plugins require them).
• Set correct limits to reduce abuse: memory_limit, max_execution_time, post_max_size, upload_max_filesize.
• Prevent path traversal surprises with sane open_basedir in shared environments.

If you run multiple client sites, a control panel with per-site PHP settings can save you time. For buyer guidance, our comparison of cPanel, Plesk, and DirectAdmin breaks down licensing, isolation features, and the ongoing maintenance cost.

HTTP security headers: small effort, real protection

Headers won’t fix a vulnerable plugin. They can still limit damage when something slips, especially with XSS.

For most sites, start with:

• Strict-Transport-Security (HSTS) once HTTPS is stable
• X-Content-Type-Options: nosniff
• Referrer-Policy (a conservative value is fine)
• Content-Security-Policy only if you’re ready to test thoroughly

Priority 5: TLS/SSL you can renew without thinking about it

Certificates still expire because people treat TLS as “set it once and forget it.” Make renewals automatic.

Then make the automation visible.

• Use ACME automation (Let’s Encrypt) for public sites.
• Confirm renewals with a monitoring check, not a hope.
• Keep your private key readable only by root and the web server group if needed.

If you run apps behind a reverse proxy, our older guide to Nginx + Let’s Encrypt is still useful for layout and troubleshooting patterns, even if you’ll likely do this on newer Ubuntu today: Nginx SSL reverse proxy configuration.

Quick certificate expiry check:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

Priority 6: backups that actually restore (plus the 3-2-1 reality for hosting)

Security isn’t only about blocking access. It’s also about getting back to normal after something goes wrong.

Ransomware, bad updates, plugin meltdowns, and accidental deletes end the same way: you need a clean restore path.

A practical 3-2-1 approach for a VPS website

• 3 copies: live data + 2 backups
• 2 media/types: disk snapshot + file-level backup, for example
• 1 off-server: object storage or a separate backup VPS

Two layers work well together:

• Snapshots for fast rollback before risky changes. See snapshot backups for deployments.
• File/database backups for clean, selective restores and long retention. Our guide to restic + S3 backup strategy includes verification and restore drills.

Restore testing: the part everyone skips

Do a monthly restore test to a staging directory or a small second VPS. You don’t need a perfect production clone.

You need proof that credentials, permissions, and database imports work end-to-end.

If you run revenue sites and want less operational overhead, managed VPS hosting is a sensible middle ground. You keep VPS-level performance and control, but you’re not on your own for patching, backups, and recovery planning.

Priority 7: monitoring and logs that catch the “quiet” failures

Security incidents don’t always look like a defacement. More often, it’s a slow leak.

Watch for CPU spikes at night, strange outbound connections, 404 storms probing /wp-admin, or disk usage creeping toward 100% until the database falls over.

Minimum monitoring set for a hosting VPS

• CPU steal/time and load average (spot noisy neighbors and runaway processes)
• RAM pressure and swap activity (catch PHP-FPM or MySQL tuning issues)
• Disk space and inode usage (prevent “disk full” outages)
• HTTP 5xx rate and response times (find broken deploys fast)
• SSH auth failures and sudo usage (basic security signal)

For a clean, low-noise setup, use our Linux VPS performance monitoring post as a reference for alerts and thresholds that won’t spam you.

Log hygiene: the simplest uptime win

Outages caused by a full disk are preventable. Logrotate mistakes and chatty access logs can take down an otherwise healthy server.

Use our guide on log rotation with logrotate + systemd to keep Nginx/Apache, system logs, and application logs from filling the volume.

Quick check for “where did my disk go?”

sudo df -h
sudo du -xhd1 /var | sort -h
sudo journalctl --disk-usage

Priority 8: WordPress-specific safety rails (because plugins are the real perimeter)

WordPress holds up well when you keep it maintained. The real risk comes from old plugins/themes, leaked admin credentials, and overly-permissive files.

The goal is simple: make updates routine, and limit what a single compromised plugin can do.

Non-negotiables for WordPress on VPS

• Auto-update minor core releases and consider auto-updating trusted plugins.
• Use a WAF layer if your site is a frequent target (even basic rules help).
• Disable file editing in wp-admin: define('DISALLOW_FILE_EDIT', true);
• Protect wp-admin with rate limiting and, if feasible, IP allowlisting.

If performance and stability matter as much as security, our WordPress hosting performance optimization article covers caching, PHP workers, and database tuning choices that also reduce DoS-style pain.

Running a single WordPress site and you’d rather not manage PHP, caching, and updates yourself? HostMyCode WordPress hosting keeps the setup simpler while still giving you a stable, security-minded platform.

Priority 9: DNS, email, and the “brand trust” side of security

A lot of real-world damage is reputational, not purely technical. DNS takeovers, spoofed email, and phishing using your domain erode trust fast.

The fixes are mostly operational: tight access and clean DNS records.

DNS hardening basics

• Lock down registrar access with strong MFA and unique passwords.
• Minimize DNS editor access (no shared logins).
• Use sensible TTLs: 300–900 seconds during migrations, longer when stable.

For domains and DNS management, keep everything under one account you control and can audit. You can register and manage records via HostMyCode Domains, which also simplifies renewals and ownership tracking.

Email authentication: SPF, DKIM, DMARC

If your domain sends email (contact forms, WooCommerce receipts, newsletter tools), set SPF and DKIM. Then enforce DMARC.

That reduces spoofing and usually improves deliverability.

If you self-host email on a VPS, our deep-dive on Postfix + Dovecot with SPF/DKIM/DMARC and TLS walks through the records and the common failure points.

Priority 10: migrations and changes without self-inflicted incidents

Security work often happens during change: moving to a new VPS, switching a control panel, or enforcing HTTPS everywhere.

That’s also when easy mistakes sneak in. Common ones include wrong DNS records, incorrect permissions, or a firewall rule left behind.

Two habits prevent most of the self-inflicted damage:

• Do changes with a rollback plan (snapshot first, document what you changed).
• Lower DNS TTL before migration, then raise it after stability returns.

If you’re planning a move, keep this open while you work: VPS migration checklist for near-zero downtime. It’s built for real hosting migrations, with verification steps you can follow.

Quick “one afternoon” audit checklist (copy/paste)

If you need a fast review, walk through this list and write down what you find. It’s meant to be blunt so nothing slips through.

• SSH: root login disabled; password auth disabled; keys only; limited users/groups.
• Firewall: only 80/443 and restricted 22 open; no public DB ports.
• Updates: security updates automated; reboot policy defined.
• Web permissions: webroot not writable; uploads writable only where needed.
• TLS: auto-renew enabled; expiry check in monitoring.
• Backups: off-server copy exists; last restore test date known.
• Monitoring: disk alerts configured; auth failures visible; 5xx alerts exist.
• WordPress: plugins updated; file edit disabled; admin protected.
• DNS/email: registrar locked; SPF/DKIM/DMARC present if you send mail.

Summary: treat security like uptime work

The best hosting security work looks like reliability work: fewer exposed services, safer defaults, controlled updates, and fast recovery.

The checklist above is practical on purpose. It targets the failures that actually show up on VPS-hosted sites.

If you want a platform that supports these habits—clean Linux VPS access, predictable performance, and room to add monitoring and backups—start with a HostMyCode VPS.

If you’d rather hand off routine patching and baseline hardening, managed VPS hosting is the calmer option for production sites.

FAQ

Do I need a firewall if I only run WordPress and HTTPS?

Yes. HTTPS only protects traffic in transit. A firewall limits exposed services and blocks accidental ports (databases, admin tools) that often get opened during troubleshooting.

Should I change the SSH port from 22?

It reduces some background noise, but it doesn’t replace key-only authentication and IP restrictions. If you change it, treat it as a minor improvement, not a primary control.

What’s the fastest backup setup that’s still safe?

Pair a snapshot before risky changes with a nightly off-server backup (files + database). Then do a monthly restore test so you know it works.

How do I know if my VPS is already compromised?

Look for new admin users, unexpected cron jobs, unfamiliar SSH keys, persistent high CPU, and strange outbound connections.

Also review web server logs for repeated probes and new PHP files in uploads directories.

Is shared hosting secure enough for business sites in 2026?

For small, low-risk sites, quality shared hosting can be fine. If you need custom firewall rules, per-site isolation, or advanced monitoring, a VPS is the better fit.