Deploy safety for Docker on VMs.
Every release ships the build you tested.

CI is green and production looks fine, until someone notices it is not running the new code.

• The previous build comes back. Images carry one moving tag per environment, and Docker Swarm can restart a service on the image a node already holds under that tag. We diagnosed exactly this in a medical-device company's production, with CI green on both deploys.
• The deploy reports success whatever happens. A webhook call succeeds when the platform accepts the request, whether or not the service takes the new image. A clinical platform we took on had about a dozen of them.
• CI races the deploy. The hosting platform deploys every push to the main branch while the tests are still running, so a failing run can still ship.
• CI holds the keys. Host addresses, ports and SSH keys sit in CI secrets so that a job can copy files to production over SSH.

Build once, deploy that exact image

The pipeline builds the image once and pushes it, and the deploy hands Swarm the image digest it pulled, so production runs the build that passed your checks. After we fixed this on the medical-device platform, a live deploy confirmed the new build. The method is in our article Pin the digest: why Swarm ran the previous build.

Deploys that fail when the update fails

We run the deploy job on a self-hosted runner inside each environment. It pulls and updates each service itself, so if Swarm rejects the update, the job goes red. On a clinical platform in three regions we moved 12 production targets off webhooks this way in three days. The runner dials out to GitHub, so nothing calls into production, and CI holds no host address, port or SSH key.

One gated path to production

Production deploys come from one workflow, and only after the checks pass: unit and browser tests, a dependency audit and lint. The platform's own auto-deploy of the main branch is switched off. On an events platform the audit gate went on once we had brought 21 high and 3 critical advisories to zero, and every production deploy since has passed it. We also check that the gate still runs: path filters and runners that never start can quietly stop CI from seeing a change.

Database migrations the old code can live with

Within a release, migrations add or relax and never remove, so rolling back means redeploying the previous build. On a multi-tenant ticketing platform, eight migrations applied in under 20 seconds, and the old code then served the new schema for about 2.5 minutes with zero errors. The previous commit was tagged and the rollback was written down before the release.

Infrastructure changes on a reviewed plan

For Terraform, a pull request produces a plan, a merge produces only a plan, and an apply uses the plan file that was reviewed. Any plan that deletes or replaces a resource needs an explicit approval for that stack.

Most engagements start with the Production Reliability Check, which reviews your release path and alerting in about two weeks. If you would rather talk first, book a 30-minute discovery call. For the alerting side, see observability.