Server Hardening Checklist for Self-Hosted Apps on Public VPS Infrastructure

Overview

A good server hardening checklist does two things: it lowers the chance of avoidable compromise, and it makes your operating assumptions visible. For self-hosting, that matters because most incidents do not begin with exotic exploits. They usually start with a forgotten port, a stale admin account, weak SSH exposure, an unpatched image, missing backups, or logs that no one reviews.

This article focuses on a realistic baseline for self-hosted apps on a public VPS. The assumption is that you are running Linux, exposing some services to the internet, and managing apps directly or through a control panel such as Portainer, Coolify, or CapRover. If you are still building your initial host, pair this checklist with How to Set Up a Secure Ubuntu Server for Self-Hosting.

The goal is not perfect security. The goal is a repeatable standard you can track. If you can answer these questions at any time, your setup is already in better shape than many public self-hosted servers:

• What ports are exposed right now, and why?
• Who can log in to the host and with what method?
• Which apps are public, internal-only, or access-gated?
• When were host packages, container images, and TLS settings last reviewed?
• Are logs, backups, and alerts tested often enough to be useful?

Think of hardening in layers:

• Host layer: operating system, users, SSH, firewall, packages, kernel defaults.
• Network layer: open ports, reverse proxy, DNS, VPN, tunnels, segmentation.
• Application layer: admin accounts, secrets, update policy, container runtime settings.
• Recovery layer: logging, monitoring, backups, restore testing, incident response notes.

That layered approach is especially useful when you host multiple app types. A self hosted password manager and a photo gallery should not automatically inherit the same exposure model. If you are comparing tools for sensitive services, see Best Self-Hosted Password Managers Compared and Best Self-Hosted Photo Management Apps Compared.

What to track

The easiest way to keep a server hardening checklist useful is to track a small set of variables consistently. Below is a practical baseline for a vps hardening guide that supports ongoing review rather than one-time setup.

1. Public exposure

Start with the simplest question: what is reachable from the internet?

• Document every open port on the VPS.
• Record the reason each port must remain open.
• Close direct access to app ports that can sit behind a reverse proxy.
• Prefer exposing only the minimum public entry points, commonly SSH, HTTP, and HTTPS, or fewer if using a tunnel or VPN model.
• Review whether admin panels are unintentionally public.

Many self-hosted setups gradually accumulate exposure. A test Grafana port, a temporary database port, a container dashboard, or a direct app bind to 0.0.0.0 can remain internet-facing long after it was needed. For remote access patterns that reduce exposed services, compare options in Cloudflare Tunnel vs Tailscale vs WireGuard for Secure Remote Access.

2. SSH and host access

For most Linux server hardening work, SSH is the first control plane to verify.

• Use key-based authentication instead of password login where possible.
• Disable direct root login over SSH.
• Limit SSH access to known users or a small admin group.
• Consider moving SSH behind a VPN, private network, or access layer if practical.
• Confirm sudo access is limited to accounts that truly need it.
• Remove stale keys and retired admin accounts promptly.

A common failure mode is not weak cryptography but account drift. Someone helped with setup months ago. A laptop was replaced. A CI key no longer has a clear owner. Track who has shell access and why.

3. Firewall rules and network policy

Your firewall should mirror your documented exposure model.

• Set a default deny posture for inbound traffic.
• Allow only required ports and protocols.
• Restrict administrative services to trusted IPs when possible.
• Review any broad allow rules created for troubleshooting.
• Make sure Docker or container networking has not bypassed your intended policy.

This is particularly important for Docker-based self-hosting. Publishing a port in Compose may create exposure that is broader than expected. If you use a control panel, review whether it automatically maps ports publicly. For broader stack decisions, see Portainer vs Coolify vs CapRover: Which Self-Hosting Control Panel Fits Best?.

4. Operating system updates

Patch management should be visible and boring. That is a good sign.

• Track when host package updates were last applied.
• Review security-related updates separately from routine package churn.
• Check whether unattended update settings match your risk tolerance.
• Plan for reboots when kernel or critical system components are updated.
• Keep notes on any packages intentionally pinned and why.

In a self hosted security checklist, the key is not patching instantly at all times. It is knowing what is pending, what is deferred, and what operational risk that creates.

5. Container image hygiene

Many public self-hosted apps are updated less through the host OS and more through container images.

• List running images and tags.
• Avoid vague habits such as updating only when something breaks.
• Review whether any apps still use outdated or abandoned images.
• Prefer a defined update workflow over ad hoc pulls on the production host.
• Remove unused images and stopped containers that no longer serve a purpose.

Do not confuse “containerized” with “isolated enough.” Containers can reduce mess, but they do not remove the need for version review, secret management, and minimal privilege.

6. Secrets and credentials

Secrets management is one of the most overlooked parts of running secure self hosted apps.

• Audit environment files, Compose files, and shell histories for embedded secrets.
• Rotate default credentials immediately after deployment.
• Use unique admin passwords per service.
• Review API keys, webhook secrets, SMTP credentials, and database passwords on a schedule.
• Store recovery codes and admin credentials in a secure password manager.

If your current process is “the token is in an old .env file on my laptop,” the system is due for cleanup.

7. Reverse proxy and TLS settings

Reverse proxies often become the security boundary for a self-hosted server.

• Confirm which apps are directly exposed versus proxied.
• Redirect plain HTTP to HTTPS where appropriate.
• Remove hostnames that no longer map to active services.
• Protect admin routes with additional access controls if supported.
• Check certificate issuance, renewal behavior, and failure notifications.

Any reverse proxy, whether you prefer an Nginx-based setup or Traefik, deserves its own periodic review because configuration sprawl is common.

8. Application-level access control

The host may be hardened while the apps remain overly permissive.

• Disable public signup if the app does not need it.
• Review which users have admin roles inside each service.
• Enable multi-factor authentication where the app supports it.
• Separate personal testing apps from production data services.
• Revisit sharing links, guest access, and embedded public endpoints.

This matters for services such as file sync, project management, and read-later platforms. If you are evaluating exposure and sharing behavior, see Best Self-Hosted Google Drive Alternatives for File Sync and Sharing, Best Self-Hosted Project Management Tools Compared, and Best Self-Hosted RSS Readers and Read-Later Tools.

9. Logging, monitoring, and alerting

You cannot interpret risk changes if you have no history.

• Track authentication failures, privilege escalation attempts, and unusual service restarts.
• Monitor disk usage, memory pressure, and filesystem errors.
• Collect reverse proxy access logs and error logs.
• Set basic alerts for downtime, certificate expiry risk, backup failures, and low disk space.
• Make sure logs persist long enough to help investigate incidents.

If your current monitoring is minimal, start small and build from there. A modest baseline is far better than an elaborate system no one reviews. For tools, see Best Self-Hosted Monitoring Tools for Small Servers and Homelabs.

10. Backups and restore readiness

Hardening is incomplete without a recovery plan.

• Define what gets backed up: configs, databases, volumes, secrets, and infrastructure notes.
• Record backup frequency and retention.
• Store backups separately from the production server.
• Test restores, not just backup jobs.
• Document recovery order for critical apps.

For a deeper operational checklist, use Self-Hosted Backup Strategy Checklist for Docker and VPS Servers.

Cadence and checkpoints

A checklist only becomes evergreen when it is tied to a schedule. The right cadence depends on exposure, app sensitivity, and how often your stack changes, but a simple rhythm works well for most public VPS deployments.

Weekly quick check

• Review failed login activity and unusual log spikes.
• Verify backups completed successfully.
• Check disk space, memory pressure, and container restarts.
• Confirm TLS certificates are healthy and domains still point where expected.

This should take minutes, not hours.

Monthly hardening review

• Audit open ports and public hostnames.
• Review package updates and pending reboots.
• Inspect container images and outdated services.
• Remove stale users, keys, tokens, and test deployments.
• Review firewall exceptions and reverse proxy routes.

Monthly is a good default for small teams and solo operators running a few important services.

Quarterly deeper checkpoint

• Test a restore for at least one critical app.
• Review all admin accounts across host, proxy, and apps.
• Rotate selected secrets and validate where they are stored.
• Confirm monitoring and alerts still map to your current stack.
• Re-check whether some internet-facing services should move behind a VPN or tunnel.

A quarterly review is where your vps hardening guide becomes operational rather than theoretical.

Change-based checkpoints

Do not wait for the calendar if one of these events occurs:

• You deploy a new public-facing app.
• You add a new domain or reverse proxy route.
• You change your remote access method.
• You grant admin access to another person.
• You migrate to a new VPS provider or base image.
• You suspect compromise, credential exposure, or unexpected traffic patterns.

How to interpret changes

Tracking is useful only if you know what a change means. Not every difference is a problem, but every unexplained difference deserves attention.

More open ports than last month

This often signals stack sprawl. It may be intentional, but if a new port appeared without a documented reason, close it or place the service behind your existing reverse proxy. Public exposure should expand deliberately, not incidentally.

More failed login attempts

On a public VPS, internet noise is normal. What matters is trend and context. A steady baseline of probes is expected; a sudden increase tied to a newly exposed service, weak admin route, or direct app login page is worth investigating. Consider additional access controls rather than relying on obscurity.

Updates keep getting deferred

This usually points to process friction. Maybe updates break a custom setup, or maybe there is no staging habit at all. The answer is not necessarily “update faster.” It may be to simplify the stack, standardize deployment, or retire apps that are too costly to maintain securely.

Backups succeed but restores are untested

This is one of the most common false signals of safety. A green backup job means very little without confidence in recovery steps, integrity, and timing. If restore tests keep slipping, treat that as a reliability gap, not a future task.

Admin access keeps expanding

That usually suggests hidden operational complexity. The more people, keys, tokens, and dashboards that can control the environment, the more likely account drift becomes. Consolidate where possible and document ownership clearly.

You are relying on one defensive layer

If your only story is “the SSH port is non-standard” or “Cloudflare is in front of it,” that is not a layered posture. Good hardening assumes one control may fail and limits damage through the others.

When to revisit

Return to this checklist on a monthly or quarterly cadence, and immediately after any meaningful infrastructure change. The practical test is simple: if you cannot describe your current exposure, auth model, update state, and recovery path from memory or notes, it is time for a review.

For a working routine, keep a one-page hardening register for each public VPS with these fields:

• Server purpose and critical apps
• Public ports and hostnames
• SSH access owners and last review date
• Firewall policy summary
• Host update status
• Container update status
• Backup target, last success, and last restore test
• Monitoring and alert destinations
• Known exceptions and accepted risks

Then use this action-oriented sequence each time you revisit the server:

1. Enumerate exposure: list open ports, domains, tunnels, and admin panels.
2. Verify access: confirm active users, keys, sudo permissions, and app admins.
3. Patch and prune: apply appropriate updates, remove stale services, delete unused credentials.
4. Check observability: review logs, alerts, certificate status, and resource pressure.
5. Confirm recovery: inspect backups and schedule or run a restore test.
6. Record changes: update your notes so the next review starts from facts, not memory.

This is what makes a self hosted security checklist useful over the long term. It turns hardening from a one-time setup task into a maintenance habit. Public self-hosting can be dependable and private, but only if you keep the baseline current. Revisit the checklist whenever the stack changes, whenever recurring checks slip, or whenever a service becomes important enough that you would regret losing control of it.