I0909 — The production image is a generated projection of the build specification

BLOCKED wave 3 · p0 · deep-work profile · parallel safe

Part of fly-deployment — A deployment is a projection of the repository model, and a reachable URL is its evidence.

Objective

Generate a multi-stage container build and its ignore file from the deployment object's build specification: a pinned Alpine runtime holding the binary, the runtime assets and nothing else, executed by an unprivileged user.

Why

A hand-written Dockerfile is a second description of the binary, the assets and the port. Generating it keeps one description; pinning the base by digest keeps the image reproducible; keeping the runtime stage minimal keeps the attack surface and the bill small.

Current state

No Dockerfile exists anywhere in the repository.

Desired state

The generated Dockerfile is idiomatic and reviewable, carries a header naming its source and its regeneration command, and is refused by generate --check when edited by hand.

Scope

• deploy/fly
• apps/majordomus-cli/src/deploy/container.rs

Out of scope

• Buildpacks, Nixpacks or a second container implementation
• Any build argument, layer or file carrying a credential
• A shell entrypoint, or any shell in the runtime stage

Dependencies

• I0902BLOCKED The deployment object becomes typed Rust that refuses nonsense
• I0904BLOCKED The listen address is one fact with two projections
• I0905BLOCKED Liveness and readiness are registered capabilities, not router hacks

What waits on this

• I0910BLOCKED The release profile is chosen by measurement, not by folklore
• I0911BLOCKED A source change does not rebuild the world, and the context stays small
• I0912BLOCKED The image serves the site the canonical pipeline produced
• I0914BLOCKED One deployment core, one command, and a dry run that mutates nothing
• I0919BLOCKED Nothing secret and nothing local leaves in the image
• I0920BLOCKED The image's dependencies are known and its advisories are policy
• I0930BLOCKED The real image runs under the real limits before anything is deployed

Acceptance criteria

• The base image is pinned to an explicit current stable Alpine version and, where obtainable, its digest; no floating tag appears in the production build
• The runtime stage contains the binary, the declared runtime assets, certificates if they are required, and nothing else — no compiler, no toolchain, no source tree, no history, no caches, no tests
• The process runs as a dedicated unprivileged user and a test proves its user id is not zero
• The entrypoint invokes the executable directly in exec form with no shell wrapper
• The musl and static-linking decision is made against the actual native dependency graph, and any remaining dynamic runtime dependency is named, justified, installed deliberately and tested
• The generated file states its source and its regeneration command without breaking the format, and generate --check fails on a manual edit

Validation

• majordomus generate --check
• cargo test --workspace --all-features

Evidence required

• generated_dockerfile
• pinned_base
• non_root
• musl_decision

Evidence

None recorded. Every token above needs a command or an artifact behind it before this issue can be completed; narrative is refused.

Risk

Generation can make the Dockerfile unreadable, which is worse than duplication. The source describes intent, the output describes mechanics, and the output has to survive review by someone who has never seen the generator.

Timeline

started

—

verified

—

completed

—

Those three fields, the evidence above and the state of the dependencies are all the status is made of. There is no status field to disagree with them.

Canonical record: .ai/repo/project/issues/I0909.yaml. Read it back with majordomus plan show I0909.