Axum: document Docker, Kubernetes, and managed-cloud deployments #400

Description

PR #401 now supplies Docker/Compose guidance and packaging smoke, plus internal Kubernetes/Envoy Gateway and AWS deployment designs. It selects stateless ECS/Fargate as the first managed target. Runnable Kubernetes manifests and authorized cloud/runtime acceptance remain outstanding; the older description of no implementation or unselected target is obsolete.

Steps to reproduce

Follow the Docker/Compose instructions using the generated fixture, then validate/run plain Kubernetes manifests in a disposable kind cluster with Envoy Gateway. For the selected managed target, record prerequisites and run an authorized disposable ECS/Fargate deployment with restart/upgrade/rollback checks.

Expected behavior

Operator recipes match proven packaging, runtime and architecture contracts. They cover TLS/proxy boundaries, config/secrets, UID/mounts, probes, shutdown, storage/replica constraints and digest-based upgrades/rollback; unverified targets remain explicit.

Impact

Preparation docs cannot establish a supported deployment. Generic examples must not silently assume application readiness, stateless operation or multi-writer embedded redb.

Proposed fix

Complete the #401 documentation preparation against #398 packaging/#399 architecture evidence and accepted runtime #275/#392/#396. Separate process liveness from application-owned dependencies/readiness. Show single-writer durable redb rollout without overlapping writers; stateless replicas use separately supported remote state. Deliver plain Kubernetes examples before adding Helm/operator complexity. Keep actual app manifests, credentials, releases and ts up downstream; no all-cloud support claim.

Done when

• Docker documentation uses the tested packaging recipe and covers non-root/read-only execution with explicit writable mounts.
• Kubernetes examples validate and run in a disposable cluster, with tested startup/readiness, failed initialization, SIGTERM/draining, restart, and the documented rollout behavior.
• The guide distinguishes app-owned readiness/dependencies from process liveness and documents TLS/proxy trust boundaries.
• Storage/replica assumptions are explicit; examples do not imply redb supports concurrent writers or that all apps are stateless.
• The selected stateless ECS/Fargate target has recorded rationale and is exercised in an authorized test deployment; remaining cloud candidates are clearly unverified.
• Architecture, HTTP protocol, stream/deadline, and BestEffort/Unsupported constraints match the accepted runtime evidence.
• Upgrade and rollback examples use retained image digests and explain configuration/secret compatibility.
• Downstream application responsibilities and links to Trusted Server's self-hosting work are clear.

Related

• Parent Make the Axum adapter production-ready for self-hosted deployments #391; preparation PR Scaffold hardened Axum application Docker recipes #401. Dependencies Axum: scaffold hardened production application Dockerfiles #398/Axum: validate multi-platform containers and provide an application publishing workflow #399 and accepted Implement portable outbound HTTP and request lifecycle contracts #436 / PR feat: implement portable outbound HTTP and request lifecycle contracts #275 with Axum: define a production server lifecycle with bounded graceful shutdown #392–Axum: add safe production diagnostics and trusted-proxy handling #397 runtime behavior.
• Trusted Server #897 owns its deployable image and installer.
• Managed-target status: ECS/Fargate selected in Scaffold hardened Axum application Docker recipes #401 designs; deployment acceptance still unperformed.