Context

Small production systems still need disciplined release paths. The goal is not process for its own sake; the goal is to make deployment boring, observable, and reversible. This work describes a release system pattern for web apps behind Docker and Nginx.

Product Goals

• Build the candidate locally or in CI before traffic changes.
• Start the new service beside the existing one on an internal port.
• Verify the canary directly before touching the public route.
• Change only the intended Nginx location.
• Keep a rollback script and previous config before reload.
• Verify unrelated services after the switch.

Engineering Shape

The release flow uses standalone application artifacts, timestamped release directories, a versioned container name, and a route-level Nginx update. That keeps the live service and the candidate service separate until the public switch. It also makes rollback concrete: restore the old route, test Nginx, reload, and verify.

Decisions

• Prefer additive deployment over replacing a running service in place.
• Treat production routing as drift-prone and verify it live.
• Avoid touching databases or unrelated subdomains for frontend-only releases.
• Record the rollback path before the route is changed.

What This Shows

Good deployment work is quiet. It reduces surprise, limits blast radius, and makes the next release easier to trust.