Container Deployment

Requirement A release image MUST use multi-stage builds and pinned base-image digests.

Rationale Staged builds isolate build tooling, and pinned digests identify the reviewed base image.

Requirement A release image MUST run its application with a non-root runtime user.

Rationale A non-root process limits the effect of an application compromise.

Requirement A runtime image MUST contain only files required to run the deployed application.

Rationale A small runtime layer reduces attack surface and image transfer cost.

Requirement A runtime image MUST NOT contain source, tests, package caches, or local configuration.

Rationale Build-only material has no production runtime purpose. Secrets stay out under litespec/quality/security#keep-secrets-out-of-tracked-and-observable-data.

Requirement A deployment platform MUST supply connection strings, OIDC settings, exporter endpoints, and secrets outside the image.

Rationale Deployment-owned configuration can differ by environment without rebuilding the application image.

Requirement A release image MUST NOT contain environment-specific configuration.

Rationale An immutable image remains deployable only when environment values stay external.

Requirement A release job MUST apply reviewed schema changes before traffic shifts to new application replicas, under litespec/backend/persistence#control-production-schema-changes.

Rationale The release job is the container platform's form of the reviewed step the baseline rule requires.

Requirement An application replica MUST NOT alter the production schema during startup, under litespec/backend/persistence#control-production-schema-changes.

Rationale Replica startup can occur concurrently and lacks release-job control.

Requirement A deployment controller MUST start new replicas and wait for readiness before shifting traffic.

Rationale Readiness proves the new application can receive traffic before it becomes active.

Requirement A release deployment MUST run the release's recorded end-to-end suite after traffic reaches the new version.

Rationale The test verifies the deployed path rather than only an image build. The release record names the suite.

Requirement A release owner MUST record the rollback procedure as a Runbook record identifying the previous image digest, under litespec/quality/operations#keep-rollback-executable.

Rationale The digest identifies one immutable image. The Runbook carries the tested command.

Requirement A deployment MUST use a read-only filesystem when the application permits it and drop unnecessary capabilities.

Rationale Runtime filesystem and capability limits reduce available compromise actions.

Requirement A deployment MUST declare writable paths and record CPU and memory bounds as Limit records.

Rationale Explicit limits protect node capacity and document required mutable storage.

Requirement A container MUST run the application as its entry process.

Rationale The application then receives the deployment platform's termination signals.

Requirement A deployment MUST set a shutdown grace period longer than measured request or Worker stop time.

Rationale In-flight work needs enough time to finish or record safe interruption.

Requirement A containerized application MUST write logs to standard output or standard error.

Rationale The deployment platform owns log collection for the immutable process.

Requirement A containerized application MUST keep mutable data outside its container filesystem.

Rationale Recreated replicas cannot rely on local mutable filesystem state.

Requirement A release image MUST include OCI source, revision, version, and created-time labels.

Rationale Standard labels connect the image to source and release records.

Requirement A release record MUST store the deployed image digest rather than only an image tag.

Rationale A tag can move, while a digest identifies one immutable image.

Requirement A published OpenAPI document or generated client MUST NOT contain a build timestamp.

Rationale Build timestamps create nondeterministic generated output without application meaning. A generated-at field and a build-time comment are both build timestamps.

Requirement A frontend image build MUST distinguish public build-time configuration from server-only runtime secrets.

Rationale Browser bundles can contain only public values, while server secrets remain private.

Requirement A frontend image build MUST use secret mounts or runtime injection for secrets.

Rationale Protected delivery keeps secrets outside persistent image history.

Requirement A frontend image build MUST NOT use ARG, copied environment files, or image layers for secrets.

Rationale Build arguments, copied files, and layers can retain a secret in image history. Secrets stay out of layers under litespec/quality/security#keep-secrets-out-of-tracked-and-observable-data.