Production Release and Recovery on StackOnward

Automatic rollback for a failed deployment: transaction state, traffic switch, and rollback limits

Fri, 11 Sep 2026 05:00:00 +0800

Automatic rollback for a failed deployment is not docker compose down after the script dies. Recovery depends on three facts: whether the candidate already took public traffic, whether the previous upstream can still be restored, and whether business checks finished. If the previous version is still serving, stop only this candidate. If the traffic switch may be half-done, restore the previous upstream. If the new version is still in the observation window, switch back. Recovery should finish the commit records only when the release has already entered the commit phase.

Docker Compose Blue-Green: Health Check, Switch, Drain

Fri, 11 Sep 2026 05:00:00 +0800

A Docker Compose blue-green deployment on one server starts the candidate, waits until the app is ready, validates and switches the Caddy upstream, proves the public hostname, drains old connections, then stops the old version. Do not delete the old container before the candidate is taking traffic.

That sequence can shrink the unavailable window. The host, disk, Docker daemon, and shared database are still single points of failure, so measure the window instead of calling the result zero downtime.

The gateway switch is the only public cutover. Candidate startup and warmup happen before that switch.

Docker Compose blue-green only works under these constraints

Run two app instances on one host only when the service meets all of these conditions:

Why Pin a Docker Image Digest: Reproducible Deploys and Rollbacks

Fri, 11 Sep 2026 05:00:00 +0800

Pin a Docker image digest by writing the production image as repository:tag@sha256:digest. The version tag shows which release you planned. The digest is the content Docker must pull. latest, stable, or a movable version tag cannot guarantee that a rebuild or rollback returns the original image.

Pinning the index digest freezes the platform set. Each node still pulls the manifest that matches its architecture.

Why pin a Docker image digest instead of a moving tag

Docker’s image digest documentation(opens in a new tab) defines a digest as a SHA-256 identifier of image content. A registry maintainer can retarget the same tag to a patched image. The original digest does not move with the tag.

OneDev Tutorial: Docker Compose, Git, and CI/CD on One Server

Fri, 11 Sep 2026 04:24:00 +0800

A OneDev tutorial starts with one instance that can host Git, review, issues, CI/CD, artifacts, and packages. Keep code on a server you operate, and skip running a separate Git service, CI, and package registry, when that trade-off is worth the ops work. The official single-node baseline is also lower than full GitLab.

The environment is one 64-bit Linux host: OneDev and PostgreSQL run under Docker Compose, and Caddy terminates HTTPS. After the instance is ready, create a Go project and prove push, tests, image build, production deploy, backup, restore, and upgrade. A container in running is not enough. The repository, Git SSH, the pipeline, and restore still have to work.

When to Run Database Migrations: Expand, Migrate, Contract

Fri, 11 Sep 2026 04:10:00 +0800

When to run database migrations depends on whether the current schema can serve both the old and the new application. Add compatible structure first, ship the new app, then backfill data. Drop columns, finish renames, and tighten constraints in a later release after the old version has left.

Destructive DDL is not tied to the first rollout of new code.

When to run database migrations depends on compatibility

The same DDL can wait on a lock for seconds or for minutes depending on table size, PostgreSQL major version, and live writes. Confirm those facts, plus how old and new code touch the table, before choosing a stage.