Web Application Blueprint
A containerized web application on Amazon EKS, released through GitOps.
BuiltForProd Blueprints
Build the solution
Production architectures for real workloads, deployed into the workload accounts of your Baseline. Each one is a working system, not a diagram.
What a Blueprint is
A BuiltForProd Blueprint is an opinionated, production-ready reference architecture for a real workload, delivered as repositories and deployed into the workload accounts of your BuiltForProd Baseline. It arrives as running infrastructure with its own pipelines, its own least-privilege deployer role, its own state and its own documentation — not as a diagram, a whitepaper or a starter template.
The distinction matters because the hard parts of a workload architecture are the ones a diagram leaves out: how a release is promoted, who can read which secret, what happens when a node dies, which findings block a deployment. A Blueprint answers those in code that is already running in your environment.
A working system, not a diagram.
How a Blueprint sits on the Baseline
It reads the foundation, it does not rebuild it
The Baseline owns the accounts, the address plan, the subnets, the hosted zones and the guardrails. A Blueprint reads those facts from Parameter Store at deploy time. There are no shadow VPCs, no duplicate identity, no second source of truth.
Its own role, its own state
Each Blueprint deploys through its own least-privilege deployer role and keeps its own state. The foundation and the workload move independently, so a workload change cannot reach into the landing zone.
Staged like the Baseline
The same stages the Baseline creates: sandbox, dev, staging and production. Staging and production are highly available; dev stays deliberately minimal, because paying production prices for a development environment is a decision, not a default.
Governed by the same pipeline
Every change is a pull request with a plan attached, reviewed under CODEOWNERS and applied by the pipeline. Production stays gated by required reviewers. The workload inherits the foundation’s change control rather than inventing its own.
The catalog
Three Blueprints today. More follow as the patterns that keep recurring get built.
Data & ETL Blueprint
A governed, event-driven data lake with no always-on compute.
Secrets Blueprint
Secrets encrypted in Git, decrypted only by the identities that should.
How a Blueprint is delivered
-
Scoped with your workload in mind
We agree the stages, the sizing and the options before anything is deployed. A Blueprint is opinionated, but the opinions are visible and the deployment-specific values are tagged in the code.
-
Repositories into your organization
The Blueprint repositories are customized and created in your own version control organization, as forks of the upstream repositories so later improvements arrive as pull requests you review.
-
Deployed by our engineers
Into the workload accounts of your Baseline, stage by stage, through the same pipeline your team will use. Nothing is applied from a laptop.
-
Handed over hands-on
Your engineers perform the real operations themselves — deploy a change, promote a release, rotate a secret, read the logs — before sign-off. Then it is yours.
Blueprints come with a new Baseline as a Full Deployment with any two Blueprints, or later as one or more additional Blueprints, each individually priced. What shapes a quote.
Questions about Blueprints
What is a BuiltForProd Blueprint?
A BuiltForProd Blueprint is an opinionated, production-ready reference architecture for a real workload, delivered as repositories and deployed into the workload accounts of your BuiltForProd Baseline. It is a working system, not a diagram.
Do we need a Baseline first?
Yes. A Blueprint deploys into the workload accounts of a BuiltForProd Baseline and reads account and network facts from it, so the foundation has to exist first. You can buy both together as a Full Deployment with Blueprints, or add Blueprints later.
How is a Blueprint different from a Terraform module or a sample repo?
A module is a component and a sample is a demonstration. A Blueprint is a complete workload architecture, deployed and running in your own accounts by our engineers, with its own pipelines, its own least-privilege deployer role, its own state and its own documentation set.
Will a Blueprint conflict with our landing zone?
No. Blueprints read the facts they need — account identifiers, subnets, hosted zones — from Parameter Store, and never recreate what the landing zone owns. Each Blueprint has its own deployer role and its own state, so the foundation and the workload change independently.
Can we change a Blueprint after handover?
Yes, and most teams do. The repositories are yours, the code is source-available under the PolyForm Internal Use License 1.0.0, and everything ships with the golden-path guides your engineers need to add a service the same way.
How many Blueprints can we add?
As many as you want. Existing Baseline customers can add one or more additional Blueprints at any time, each individually priced and deployed into the workload accounts that already exist.
Blueprints assume a foundation: start with the Baseline. They are built to the same eight properties as everything else: read the Standard. If you want engineers to keep operating them with you, there is Managed.
Find out what production would take.
Tell us what you are running and what is coming: a funding round, an audit, a first enterprise customer, a migration. We will tell you what we would build, what it costs, and whether we are the right fit.