What is it? #
This is the final lesson of the track: everything covered, in one list, in the order you should verify it.
A checklist is not a substitute for understanding. It is what stops you forgetting the boring item at eleven at night, which is exactly when the forgetting happens.
The items are grouped by category, and each one is verifiable — you can demonstrate it rather than believe it.
Items marked as essential should be done before real users arrive. The rest can follow shortly afterwards.
Think of it like this #
The list a pilot reads aloud before taking off, even after a thousand flights.
Experience does not remove the checklist. It is precisely because the items are routine that they get skipped without one.
Simple example #
An application is ready to launch. Before pointing the domain at it, you work through each item and record the evidence that it passes.
Code #
SECURITY (all essential)
[ ] SSH: key-only, root login disabled, AllowUsers set
[ ] firewall: default deny, only 22/80/443 open
[ ] database and app ports bound to localhost or a private address
[ ] application runs as an unprivileged user, not root
[ ] secrets in a 600 env file, owned by the service user
[ ] .env and keys confirmed absent from git history
[ ] automatic security updates enabled, with a reboot window
[ ] fail2ban active
[ ] HTTPS with a valid certificate covering every name served
[ ] security headers set in NginxRELIABILITY
[ ] application runs as a systemd service with Restart and a start limit (essential)
[ ] graceful shutdown works: TimeoutStopSec exceeds the app's own timeout (essential)
[ ] memory limit set per service
[ ] health endpoint verifies real dependencies (essential)
[ ] service confirmed to start automatically after a reboot (essential)
[ ] log rotation configured, journal size bounded (essential)
[ ] disk has headroom; growth understood
[ ] tested behaviour when the database is briefly unavailableDEPLOYMENT
[ ] deployment is a script, not a sequence of manual commands (essential)
[ ] releases directory with an atomic symlink switch
[ ] shared env file and uploads outside release directories (essential)
[ ] health check after deploy, failing the script if unhealthy (essential)
[ ] rollback script written AND tested (essential)
[ ] migrations are backwards compatible
[ ] queue workers restarted on deploy, if applicable
[ ] old releases cleaned up automaticallyMONITORING AND RECOVERY
[ ] external uptime check on a real endpoint (essential)
[ ] disk space alert at 85% (essential)
[ ] service-down alert
[ ] certificate expiry alert at 14 days (essential)
[ ] error tracking receiving application exceptions
[ ] database backup automated, encrypted, offsite (essential)
[ ] backup failure alerts on a missing check-in (essential)
[ ] restore tested, with the restore time recorded (essential)
[ ] uploads and configuration included in the backup plan
[ ] a written runbook: how to restart, roll back and restore# Verification commands — demonstrate, do not assume
ssh -o PasswordAuthentication=yes -o PubkeyAuthentication=no deploy@server # must fail
sudo ufw status verbose
sudo ss -tulpn | grep -v 127.0.0.1 # only 22/80/443 expected
ps aux | awk '<span class="katex-error" title="ParseError: KaTeX parse error: Expected '}', got 'EOF' at end of input: …= "root" {print" style="color:#cc0000">1 == "root" {print</span>11}' | sort -u
curl -sI https://example.com | head -1 # 200 over HTTPS
curl -sI http://example.com | head -1 # 301 to HTTPS
sudo certbot certificates # expiry dates
systemctl is-enabled myapp nginx # enabled at boot
sudo reboot # then verify everything returnedHow it works #
The list is ordered by how much damage skipping an item causes. Security items are all essential because their failure mode is a compromise rather than an inconvenience.
Each item is phrased so it can be demonstrated. "Backups configured" is a belief; "restore tested, time recorded" is evidence.
The reboot test at the end of the verification commands is the single most revealing check. It confirms that every service starts automatically, that mounts persist, and that nothing was left running only because someone started it by hand.
The password authentication test is worth running explicitly. It proves the configuration took effect rather than assuming the file was read.
Checking what runs as root and what listens publicly turns two abstract concerns into concrete lists you can act on.
The runbook is the item most often missing. During an incident, at an unsociable hour, possibly with someone else on call, the response should not have to be derived from scratch.
Nothing here is difficult. The value is in doing all of it, and in being able to show that you did.
Real-world use #
Most production incidents trace back to a skipped item on a list like this one: no backup test, no rollback path, a missing alert, an exposed port.
Teams that automate the checklist — with configuration management and a deployment pipeline — get the same result reproducibly, which matters when the server needs rebuilding.
The checklist should be revisited periodically, not only at launch. Servers drift, and an item that passed six months ago may not pass now.
Adapt it to your situation. A hobby project does not need every item; a system handling payments or personal data needs more than is listed here.
Finally, the reboot test deserves repeating on a schedule. A machine that has not been restarted in a year may not come back cleanly, and finding that out during a forced reboot is the worst possible time.
Common mistakes #
- Treating the checklist as documentation rather than something to verify.
- Never rebooting, so nobody knows whether the server comes back cleanly.
- Backups configured but never restored.
- No rollback path, discovered during the first bad deployment.
- No runbook, so incident response is improvised.
Practice #
Work through the full checklist on a server you manage and record evidence for each item. Then reboot it and verify everything returns automatically. Finally, write a one-page runbook covering restart, rollback and restore, and store it somewhere reachable without the server.