Declared vs running inventory
Capture Compose declarations, running image references and digests so drift can be identified before maintenance changes anything.
Platform Engineering Case Study
Make container changes controlled, observable and reversible.
This project closes the gap between declared and running container versions across Docker and Kubernetes. The same Git ownership model now also protects critical DietPi operational source, while runtime databases and plaintext secrets remain deliberately outside Git. A non-destructive rehearsal reconstructed all 38 managed DietPi files. Stage 2 then established four-host SOPS and age recovery, protected live delivery, plaintext retirement and a successful detached-media recovery rehearsal.
The Challenge
A running container is not the same thing as a controlled deployment.
Routine maintenance exposed a version-control gap: a container could be running a newer image than the version still declared in Compose. Recreating that service could therefore introduce an unexpected downgrade even though the running platform appeared healthy.
Update tooling such as WUD was already useful for identifying newer images, but update detection alone does not provide an authoritative desired state, validation gate, audit trail or guaranteed rollback point. The project was created to add those controls end to end.
Target Architecture
One controlled path from declaration to runtime.
Each tool has one clear role. Runtime discovery and update signals do not bypass the Git-controlled desired state.
01Git + Compose
Defines the intended image tag and digest.
→
02Renovate
Proposes image changes through pull requests.
→
03Jenkins + Trivy
Validates configuration, downgrade risk and image security.
→
04Guarded deploy
Stages the change with health checks and rollback metadata.
→
05Docker hosts
Runs the approved image on TestServer and ids-01.
→
06Prometheus + Grafana
Reports compliance, drift and deployment health.
Independent signal: WUD continues to report available updates from the running estate, but it does not become the source of truth or an automatic production deployment mechanism.
Engineering Controls
Version management is more than choosing a tag.
Pull-request updates
Renovate proposes controlled image changes in Git rather than changing running containers directly.
Validation gate
Jenkins checks rendered Compose configuration, architecture support, downgrade risk and Trivy findings before deployment is permitted.
Secrets foundation
SOPS + age now protects recovery sources across four hosts. Two approved identities, protected file delivery and detached-media recovery have all been validated.
Rollback-first deployment
The current image and known-good state are recorded before a change, and health checks determine whether the deployment is accepted.
Runtime compliance
Prometheus and Grafana will expose drift, floating versions and compliance exceptions instead of relying on manual inspection.
Staged Go-Live
Automation only earns more authority after the controls are proven.
The delivery plan uses explicit go/no-go gates. A failed secrets, validation or rollback test blocks progression even if the calendar says the next stage should have started.
Complete — 23 Aug
Complete — 23 Aug
Complete — 25 Aug
12–18 Sep
19–25 Sep
26 Sep–2 Oct
3–9 Oct
10–16 Oct
Design Principles
The process is intentionally conservative around production change.
Git is authoritative. Runtime state can inform the process, but it does not silently redefine desired state.
Secrets are a go-live dependency. Encryption, protected delivery, two-identity recovery and detached-media rehearsal are proven before deployment automation gains authority.
Rollback is designed before rollout. A deployment is not considered safe if the previous known-good state cannot be restored.
Critical services move last. DNS, security and core monitoring services are introduced only after lower-risk pilots prove the process.
Engineering Outcome
Turn container maintenance into a reproducible operating model.
The project is still in delivery, so the outcome is deliberately framed as the target operating model rather than a completed claim. Success means every production image change can be traced from an approved Git declaration to validation evidence, deployment health, runtime compliance and a tested rollback point.
It also brings version control, secrets management, vulnerability scanning and observability into one workflow instead of treating them as separate maintenance activities.