Make your next deployment repeatable

Collect identifiable inputs

Use an application you can build in a non-production environment, access to source and its artifact registry, a versioned configuration schema and an external secret store. Keep a known working release. These are inputs to your automation; PrivacyNodes does not provide a deployment API or pipeline runner through this website.

Pin the artifact instead of relying on a mutable label such as latest. Docker documents digest pinning to identify an exact base image, with the need to review updates deliberately. Reproducibility and patching are both responsibilities: keeping an old vulnerable image forever is not a maintenance plan.

Technical reference: Docker build best practices.

Write a release record before changing traffic

This is a document format, not an executable script. Populate the placeholders from the reviewed artifact. A source revision alone does not describe environment changes. Include the observed migration duration, expected lock behavior, configuration differences and last working artifact.

# Illustrative release record — no credentials
release: reports-api-review-01
source_revision: REVISION_TO_REVIEW
artifact_digest: DIGEST_FROM_YOUR_REGISTRY
configuration_schema: config-v3
migration: add-export-state
old_code_can_read_new_schema: yes
verification:
  - authenticated-read
  - enqueue-and-complete-test-export
  - failed-dependency-behavior
rollback_decision: keep-additive-schema-and-previous-artifact
operator_and_result: TO_BE_RECORDED

Store the record somewhere reachable when the application is down. Reference protected recovery credentials without including their values. Name the maintainer who can stop promotion and the point after which the planned rollback is no longer valid.

Separate preparation from promotion

Build and inspect the artifact first. Validate configuration and secret references before starting the new process. Apply only the schema step reviewed for this release. Start the new version in the intended environment and check dependencies before moving traffic; avoid combining an unreviewed destructive migration with an ordinary image update.

With Compose, a started container does not establish readiness. A meaningful health check and condition: service_healthy can make dependency waiting useful, but cannot verify a customer workflow. The application must still handle a dependency becoming unavailable after startup.

Technical reference: Docker Compose startup order.

Verify more than a green port

For the reporting API, check an authenticated test request, a read against the intended schema, one small queued export and access to its file. Use a dedicated test namespace and suppress production notifications. Check that overlapping versions cannot accidentally duplicate scheduled work.

Write expected outputs before the check: correct account scope, the expected example record, one completed export and no unauthorized cross-account data. Record actual outputs and timing afterward. A home page returning HTTP 200 is insufficient if a worker repeatedly fails or a migration left the API reading stale values.

Make the recovery decision explicit

If the process fails to start, keep traffic on the working version. If a workflow check fails, stop promotion and preserve redacted evidence. An additive schema compatible with the old artifact may permit application rollback. After an incompatible transformation, old code can be unsafe; follow the reviewed forward-fix or data-recovery plan.

Do not repeat a failing migration indefinitely. Determine what committed, whether retry is safe and whether users wrote under the new schema. The migration guide develops this boundary with a column change. Do not treat the existence of a rollback button as proof that data can be reversed.

Leave a record another maintainer can follow

Compare deployed artifact and configuration identifiers with the planned record. Preserve checks, failed attempts and the chosen recovery action. Keep the last working artifact under an explicit retention policy; do not remove it while validation is incomplete.

A useful rehearsal lets another authorized maintainer explain the inputs, repeat the checks and find recovery instructions without searching your shell history. It does not prove zero downtime or future success. Revisit it when schema, worker behavior or dependencies change. Next, narrow the deployment identity's permissions.