The Deployment Harness
One contract between applications and infrastructure stacks
How It Works
One application manifest: services, build recipe or image, CPU and memory, health checks, paths, and backing services requested by logical name
An estate registry names every deployment stack and the adapter that serves it
Each stack turns intent into its native form and keeps its own deployment catalog
Shared identity and entitlements, a public application catalog, and one estate-wide dashboard
What Every Stack Guarantees
- Service marketplace and broker: applications ask for postgres/small or user-registry; each stack maps that to a service instance or claim
- Explicit binding: provisioning a database never hands its credentials to every container, only to the ones that bind it
- Secrets out of every repository: the manifest classifies each value as config or secret; values are supplied out of band per stack (Secrets Manager, a user-provided service, a Kubernetes Secret)
- Blue/green by declaration: each colour always answers on its own host, and the live host follows
live: truein the manifest. Cutover is the same on every container stack: move the flag, apply the newly live colour first, then the old one. In between, both colours answer. Degraded, never dark - Target guards: refuse the wrong context, such as AWS account, Kubernetes namespace, etc. before anything changes
- Deployments never depend on running services: catalogs represent Infrastructure as Code in source files, so an application outage can't block deploying its own fix
- Preview before acting: every stack shows what it will do before doing it: a Terraform plan, a dry-run deploy, or a rendered manifest before any push executes