The Go-Live Checklist
Before Any Container Faces Users
Everything in this track compresses into one reviewable list:
| ✔ | Item | Module that taught it |
|---|---|---|
| ☐ | Pinned image tag (version/SHA, never latest) | Images & Registries |
| ☐ | .dockerignore in place; no secrets in layers | Writing Dockerfiles |
| ☐ | Multi-stage build; minimal base | Writing Dockerfiles |
| ☐ | Runs as non-root (USER), cap-drop ALL, read-only rootfs where possible | Security |
| ☐ | --memory, --cpus, --pids-limit set | Debugging / Observability |
| ☐ | Restart policy unless-stopped (or orchestrator-managed) | Containers Day-to-Day |
| ☐ | HEALTHCHECK probing a real dependency-aware endpoint | Observability |
| ☐ | Log rotation (max-size/max-file) or shipping configured | Observability |
| ☐ | State on named volumes; volumes in the backup plan | Volumes & Persistent Data |
| ☐ | User-defined networks; ports bound to 127.0.0.1 unless truly public | Networking |
| ☐ | Secrets file-mounted or vault-fetched - never env/baked | Security |
| ☐ | Image scanned in CI; version labels stamped | Docker in CI/CD |
Tip: Turn this into a PR template or a CI policy gate. Checklists beat memory at 2 AM, and they turn "tribal knowledge" into something a new hire enforces on day one.
Scenario: Re-read the checklist and notice: nearly every line exists because of an incident you've now debugged in the labs - the OOM kill, the 40GB log file, the wiped volume, the leaked .env, the privileged payments container. Production readiness is just incident memory, written down.