Production Deployment and Recovery Capstone
A production-ready self-hosted deployment is not complete when the page loads. It is complete when another authorised operator can identify the version, verify health, restore data, rotate access, apply a tested update, and roll back.
What You Will Be Able to Decide
- Explain the role of production deployment and recovery capstone in a self-hosted system.
- Apply the procedure to a real open-source deployment.
- Recognise unsafe defaults and verify the resulting control.
- Record enough evidence for another operator to repeat or recover the work.
This capstone turns the previous lessons into one operating system. Choose a maintained open-source application with official container or Compose guidance and a consequence level suitable for learning.
A technically successful deployment returns a page. An operationally successful deployment also survives a container recreation, a failed release, a lost credential, and the loss of the original VPS.
The deliverable is an evidence pack, not a screenshot: source revision, architecture, data map, access register, configuration template, backup, restore record, monitoring checks, update procedure, rollback procedure, and named ownership.
Technical term
Recovery objective
An explicit target for how much data may be lost and how quickly a service should return after failure.
It is the promised destination and arrival time for an emergency route, not merely a note that a spare vehicle exists.
The Working Model
Select an application from a trustworthy upstream project and read its official deployment, upgrade, and backup guidance. Decide whether to deploy plain Compose or use Coolify or Dokploy. Do not improvise a different architecture until the documented path works.
Create a staging hostname first. Inject unique secrets, attach volumes, restrict network exposure, and verify application health. Then create an encrypted off-server backup and restore it into a clean temporary environment before calling the backup valid.
Add availability and resource monitoring, log retention, certificate-expiry awareness, and an update calendar. Test a pinned upgrade in staging, capture migration notes, deploy in a maintenance window, and retain a rollback path that accounts for database schema changes.
Implementation Procedure
- Choose a maintained open-source application and record the licence, upstream repository, stable release, resource requirement, and official deployment path.
- Provision the VPS; secure SSH; configure DNS, firewall, Docker, and either Compose or one selected deployment platform.
- Create a deployment repository with pinned versions, `.env.example`, storage map, access register, and runbook.
- Deploy to staging, verify TLS, login, email or OAuth integrations, AI or MCP dependencies if used, persistence, logs, and least-privilege access.
- Create an encrypted off-server backup, restore it to a clean environment, and measure data loss and recovery time.
- Promote or recreate the verified release for production, enable monitoring, and record the exact source and image versions.
- Perform one controlled update and rollback exercise, then hand the evidence pack to a second authorised operator.
# Pre-deployment checks
docker compose config --quiet
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=100
# Record immutable evidence
git rev-parse HEAD
docker compose imagesControlled Practice and Fragile Practice
Verification and Recovery Evidence
- A technically literate second operator can deploy the documented revision without private verbal instructions.
- The restored application contains the expected records, files, users, and configuration.
- Alerts reach a named owner and the runbook explains first response, rollback, and escalation.
Warning Signs
- The only administrator, DNS login, and decryption key belong to one person.
- Backups share the same failure domain and credentials as production.
- An upgrade cannot be associated with release notes, a change window, or a rollback decision.
Questions to Ask a Consultant
- Can the service be rebuilt if the current VPS disappears today?
- What is the acceptable data-loss window and measured recovery time?
- Can somebody other than the original deployer operate and recover it?
Key takeaway
Key Takeaway
Production means repeatable operation under change and failure. Finish with a deployed application, a tested restore, controlled access, observable health, and a runbook another person can use.