Self-Hosted Server Maintenance Checklist: A Weekly, Monthly, and Quarterly Routine

Overview

Self-hosting maintenance is easier when it is treated as a scheduled operating routine rather than an emergency response. Whether you run a home server, homelab, or VPS for self-hosting, the same principle applies: check the components that can quietly degrade, record what changed, and test the recovery process before you need it.

This checklist assumes a Linux server running one or more services, possibly through Docker Compose, with a reverse proxy and automated TLS certificates. Adapt the commands to your distribution, deployment method, and backup tooling. Before changing production services, confirm that you have a recent backup and a way to access the server if the application becomes unavailable.

For a broader security baseline, use this server hardening checklist for self-hosted apps. If you run several applications on one machine, also review how to run multiple self-hosted apps on one server safely.

What to track

Operating system and security updates

Record pending package updates and identify whether any update requires a reboot. On Debian or Ubuntu, a read-only review can begin with:

sudo apt update
apt list --upgradable
needs-restarting -r 2>/dev/null || true

Apply updates during a planned window, especially if the server hosts databases, file sync, or other stateful services. Check application logs afterward and confirm that the expected ports and URLs still respond. Do not assume that a successful package update means every self-hosted app is healthy.

Docker containers and application releases

Review the applications managed by Docker Compose and compare the deployed image versions with the versions you intend to run. A safe update should be deliberate: read the application release notes, check for configuration or database migration requirements, pull the new image, recreate the service, and inspect its logs.

docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=100

Run these commands from the relevant Compose project directory, not from an unrelated location. Avoid automatically updating every image on a server without a rollback plan. Pinning image tags or recording the current image digest can make it easier to identify what changed.

Backups and restore readiness

A backup checklist should cover both application data and the information needed to rebuild the service: Compose files, environment variable templates, reverse-proxy configuration, database dumps, encryption keys, and documented DNS or certificate settings. Never treat a mounted Docker volume as a backup by itself.

Each week, verify that backup jobs completed and that the destination is reachable. Check the age and size of recent backup files; an unexpectedly small archive can indicate a failed export. Keep at least one copy separate from the server, and protect sensitive backups with appropriate access controls and encryption.

At a scheduled interval, restore a representative backup into a temporary directory or isolated test service. A backup that has never been restored is an assumption, not a confirmed recovery option.

Storage, memory, and system health

Disk usage often becomes a reliability problem before it becomes an obvious outage. Check filesystem capacity, inode usage, Docker image layers, container logs, and database growth:

df -h
df -ih
docker system df
free -h
sudo journalctl --disk-usage

Do not delete Docker volumes or prune images until you understand what they contain. Review large directories with tools such as du, and define retention rules for logs and backups. Track trends rather than focusing only on one reading: steadily increasing storage use deserves attention even when there is still free space.

Certificates, DNS, and reverse proxy routing

Confirm that public hostnames resolve to the intended endpoint and that certificates are renewing successfully. Check the reverse proxy dashboard or logs for failed challenges, expired certificates, upstream errors, and routes that point to retired services. If you use Traefik, follow a documented configuration and review its logs after application changes; this Traefik Docker Compose guide provides a useful deployment reference.

Where possible, test both HTTPS access and the application’s health endpoint. A valid certificate does not prove that the backend is available, and a reachable backend does not prove that the intended hostname is protected.

Accounts, access, and monitoring

Review administrator accounts, SSH keys, API tokens, service accounts, and shared credentials. Remove access that is no longer required and rotate secrets when a team member, device, or integration changes. Check that SSH is using key-based access where appropriate, that privileged access is limited, and that management interfaces are not unnecessarily exposed to the public internet.

Finally, review alerts from your self-hosted monitoring system. Confirm that checks are still pointed at the correct hostnames and that notifications reach a person who can respond. An uptime check that never triggers during a known test is not providing much assurance. See this comparison of self-hosted uptime monitoring tools if your current monitoring needs improvement.

Cadence and checkpoints

Weekly self-hosted server maintenance checklist

• Review operating system and security updates.
• Check Docker container status and recent error logs.
• Confirm that scheduled backups completed.
• Inspect backup age, destination availability, and available storage.
• Review monitoring alerts, failed login notifications, and unusual resource usage.
• Confirm that critical applications, login flows, and public HTTPS endpoints work.

A weekly check should be short enough to complete consistently. If it repeatedly takes hours, split investigation work into a separate maintenance task and improve the monitoring or documentation that caused the delay.

Monthly maintenance checkpoints

• Apply planned application and container updates after reviewing release notes.
• Test a restore of at least one important application or database backup.
• Review disk, memory, CPU, and database growth trends.
• Audit users, SSH keys, tokens, exposed ports, and reverse-proxy routes.
• Verify certificate renewal, DNS records, and alert delivery.
• Update the server inventory and record configuration changes.

Monthly work is a good time to update a Docker backup strategy and verify that the recovery instructions match the current deployment. If you use a management panel such as Portainer or Coolify, record which tasks are performed in the panel and which are performed directly on the host so another administrator can reproduce them.

Quarterly reliability review

• Perform a documented disaster-recovery exercise on isolated infrastructure or a temporary host.
• Confirm that you can restore the operating system, application configuration, databases, and secrets.
• Review the purpose and exposure of every running service.
• Rotate credentials that require periodic rotation and remove obsolete secrets.
• Review provider, domain, DNS, and backup-account access.
• Check whether the server still has adequate capacity and an appropriate failure plan.

The quarterly review should answer a practical question: if this server disappeared today, could you rebuild the important services from documented steps and available backups? If the answer is uncertain, prioritize documentation and restoration rather than adding more applications.

How to interpret changes

Maintenance is not just a list of green check marks. Compare current observations with previous entries and investigate changes in context.

• Storage rises steadily: identify growing logs, media, databases, image layers, or backup retention before the filesystem becomes full.
• A container restarts repeatedly: inspect logs, health checks, memory limits, dependency availability, and recent configuration changes. Do not hide the symptom by simply restarting it.
• Backups complete unusually quickly or produce smaller files: verify that the expected directories, database tables, and volumes were included.
• Login failures increase: check exposed services, SSH logs, account activity, firewall rules, and token usage. Preserve relevant logs before rotating or deleting them.
• Certificate or health checks fail: distinguish a DNS, reverse-proxy, certificate, network, or application problem. Test each layer separately.
• Updates change behavior: record the version, configuration change, error message, and rollback action. This creates useful operational history for the next incident.

Use a maintenance log rather than relying on memory. A simple format is enough:

Date | Host/service | Task | Result | Change or issue | Follow-up | Operator
2026-08-03 | files.example | Backup restore | Passed | Restored test copy | Repeat next quarter | admin

Keep the log separate from the only copy of the server. It may contain operational details, so restrict access and avoid recording plaintext passwords or private keys.

When to revisit

Use this checklist weekly for routine checks, monthly for updates and access reviews, and quarterly for recovery testing. Revisit it immediately after a major change: moving from a home server to a VPS, adding a database-backed application, changing reverse proxies, exposing a new public service, or switching backup destinations.

Update the checklist whenever your architecture changes. Add each new service, data source, credential, hostname, backup job, and monitoring check to the inventory. Remove retired items so the routine stays usable. If a task fails twice, turn the failure into a documented improvement: add an alert, automate a safe check, clarify the runbook, or redesign the recovery process.

For the next maintenance session, create a calendar reminder, copy the checklist into your preferred notes or issue tracker, and complete the first restore test. A modest routine followed consistently will do more for self-hosted server security and reliability than an elaborate plan that is never reviewed.