Axum: make production configuration and local storage explicit #396

Description

Main can run a standalone binary without edgezero.toml, but local KV/config paths remain cwd-derived and malformed local config can be dropped with a warning; crates/edgezero-adapter-axum/src/dev_server.rs:397 and crates/edgezero-adapter-axum/src/dev_server.rs:449. PR #406 implements strict production startup/paths with lifecycle #392, on #275 fallible application assembly.

Steps to reproduce

Start the release binary from an unrelated cwd with read-only config and a writable data mount. Try missing/malformed required config, invalid bind inputs, unreadable mounts and a locked database; then restart and restore backed-up state using the intended runtime UID.

Expected behavior

Configured locations and application-declared required inputs govern startup; required failures occur before readiness with redacted diagnostics. Development defaults remain documented. Embedded storage has explicit single-writer ownership and recovery behavior.

Impact

Implicit paths and permissive missing/malformed configuration can start the wrong deployment state. Treating redb as shared multi-writer storage risks unsupported deployment/recovery assumptions.

Proposed fix

Review/integrate #406 with accepted #275 fallible App::build/configuration reads. Reuse validated production locations and strictness settings, maintain startup snapshots/restart-based updates, and document backup/restore, permissions, expiry/capacity maintenance and replica limits. Applications choose required keys and signing/feature policy; no adapter inference of mandatory secret names or distributed-store implementation.

Done when

• Re-audit the accepted PR feat: implement portable outbound HTTP and request lifecycle contracts #275 implementation and record which checks are already covered. Add only residual changes and missing production acceptance evidence.
• A standalone release binary starts from an unrelated working directory using only configured paths and required environment inputs.
• Missing or malformed required config, unreadable mounts, invalid bind values, and locked KV files fail before readiness with a non-zero exit and redacted diagnostic.
• Development mode retains its documented permissive behavior.
• Tests prove KV values survive a stop/restart on the same mounted data directory and that a second process cannot silently share the file.
• A backup/restore check reads stored values back; the guide never recommends deleting production data as ordinary lock recovery.
• Read-only config and writable-data mounts work with the runtime UID used by the Docker image.
• Config snapshot behavior, secret update behavior, and replica limitations are documented.

Related

• Parent Make the Axum adapter production-ready for self-hosted deployments #391. Implementation PR Add Axum production startup and bounded shutdown #406 (also Axum: define a production server lifecycle with bounded graceful shutdown #392), foundation feat: implement portable outbound HTTP and request lifecycle contracts #275 / Implement portable outbound HTTP and request lifecycle contracts #436.
• Make ordinary config values readable consistently on Fastly #324 raw config semantics; Implement local provisioning across all adapters #288 local provisioning; Add a secrets CLI for typed application configuration #284 secret CLI; Axum: scaffold hardened production application Dockerfiles #398–Axum: document Docker, Kubernetes, and managed-cloud deployments #400 container/operator integration.
• Downstream Trusted Server #1141, #1139, #843.