Deployment Stamp Strategy
A deployment stamp is a self-contained, repeatable unit of infrastructure plus application, so scaling out is stamping a new copy and scaling in is deleting one, with no per-instance configuration.
Definition
A deployment stamp is an infrastructure-as-code template that packages the application with all its dependencies — network, storage, config — into a self-contained unit, so that scaling out is stamping a new copy with a unique identifier and scaling in is deleting the stamp, with no per-instance manual configuration.
Context and scope
Applied in multi-region, multi-tenant, and any system where the deployment unit must be repeatable and the infrastructure must be disposable.
Common misconceptions
- A stamp is just a microservice — a stamp contains the application and its infrastructure; a microservice is just the application
- Stamps require IaC — they require IaC to be repeatable; a hand-built stamp is not a stamp, it is a snowflake
Anti-patterns
- Building each stamp with manual steps, so each is a snowflake and scaling out is not repeatable
- Sharing state across stamps through a shared database, so deleting a stamp corrupts the shared state
Related concepts
Authoritative source
https://learn.microsoft.com/en-us/azure/architecture/guide/multitenant/app-stamps
What it is
A deployment stamp is an infrastructure-as-code template that packages the application with all its dependencies — network, storage, config — into a self-contained unit, so that scaling out is stamping a new copy with a unique identifier and scaling in is deleting the stamp, with no per-instance manual configuration. Applied in multi-region, multi-tenant, and any system where the deployment unit must be repeatable and the infrastructure must be disposable. The unit of delivery is the deployable artifact plus its configuration, and the goal is to move changes to production safely, quickly, and reversibly.
How it works
Safety comes from small batches (less change per deploy means less blast radius), automated canaries (a bad change is caught at 1% before it reaches 100%), and reversible deployments (rollback is the default escape, not a rewrite). Speed comes from pipeline parallelism and eliminating the manual gates that batch up changes. Every step produces evidence — test results, scan output, canary metrics — that the next step consumes.
When to apply and pitfalls
Apply whenever the cost of an incident exceeds the cost of the pipeline that prevents it. The pitfall is optimizing deploy speed without investing in the observability and rollback that make speed safe — fast deploys of broken code just reach the outage sooner. Another is treating the pipeline as a checklist rather than a feedback loop that improves with each deployment.