Skip to content

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

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.

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

Part of fly-deployment — The container image is a projection of the repository model, and its smoke is its evidence.

Ready. Every dependency is done, so majordomus plan start I0909 will be accepted.

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

deploy/Dockerfile exists and is generated: apps/majordomus-cli/src/deploy/render.rs renders it and .dockerignore from the deployment object, and generate.rs owns them as targets; docker-image.yml and release.yml's image job build it into ghcr.io/korczis/prismatic-majordomus. fly.toml was rendered beside them until 2026-10-12, when Fly.io was ruled out as a target and the file left the tree. The statement this field used to carry -- that no Dockerfile exists anywhere -- was falsified before 2026-09-10 and never corrected. Measured on master 6042f4286, 2026-09-10; fly.toml removal on 722228ef3c, 2026-10-12.

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

What waits on this

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.

Searches the titles and descriptions of every page this site publishes.