Kubernetes is easy to start and expensive to finish
A cluster takes an afternoon. A platform takes a year: ingress, autoscaling, secrets delivery, network policy, image supply chain, promotion between environments, and the answer to what happens when a node disappears during a release. The Web App Blueprint is that year, already written.
Where Kubernetes projects actually stall
Not at the cluster. At the twenty decisions after it, each of which looks small and none of which can be skipped.
The team has decided to run on Kubernetes, or is already running on a cluster that nobody would call production-ready, and the platform work around it has no owner and no end date.
-
“Nobody deploys on Fridays. Honestly, nobody likes deploying at all.”
Deployment is a manual sequence with a person in the middle, so releases batch up and each one carries more risk than the last.
-
“Our launch got featured and the site fell over within an hour.”
Capacity was sized for the average day. Scaling behavior was discovered during the event rather than designed before it.
-
Secrets reach the cluster through a manual step or a CI variable.
Nobody can say which secrets are in which environment, and rotation is a project rather than a procedure.
-
Pods run as root with no network policy, because the defaults said so.
The first penetration test or customer security review turns into a rebuild of the workload layer.
-
The image that reaches production is not the image that was tested.
Rebuilds between environments make every promotion a new experiment, and make incident forensics guesswork.
What building it yourself costs
A platform team can absolutely build this. The question is the year, and what the product does not get during it.
- Time to a usable golden path
- Cluster, ingress, DNS, certificates, autoscaling, logging, secrets, policy and delivery all have to work together before the first product team benefits.
- The security layer that gets deferred
- Network policy, non-root containers, image scanning and per-workload identity are the parts most often left until an external reviewer asks about them.
- Capacity discovered in production
- Autoscaling configured after the first traffic spike is configured with a customer-facing incident as its test case.
- Divergent clusters
- Without a shared definition, each environment drifts, and "works in staging" stops meaning anything.
What we do about it
We deploy a Kubernetes platform that is already opinionated about every one of those decisions, into your accounts, on top of a landing zone that already handles identity, networking and logging.
-
A cluster designed for production, not for a demo
A private control plane endpoint, a managed node group with automatic provisioning for burst capacity, load-balancer ingress over HTTPS only with a web application firewall in front, and workload identity per service.
-
GitOps delivery with a real promotion path
The image is built once and promoted. Merge deploys to development automatically, a release promotes to staging, and production requires a manual approval and a deliberate sync.
-
Workload hardening by default
Default-deny network policy, non-root read-only containers with all capabilities dropped, seccomp profiles, instance metadata locked down and an image scan that blocks high and critical findings.
-
Secrets delivered, not copied
Secrets live encrypted in Git, are decrypted only by a cloud key the pipeline controls, and reach workloads through an operator instead of a manual step.
-
The supporting data services
A managed document database and a managed cache per stage, with production sized for high availability and development sized for cost.
The outcome: Your teams get a golden path: a repository layout, a chart, a pipeline and a promotion sequence that takes a commit to production through review gates rather than through a person's nerve.
What that is, in the portfolio
-
BuiltForProd Blueprints
Opinionated, production-ready reference architectures for real workloads, deployed into your Baseline. Each one is a working system, not a diagram.
-
BuiltForProd Baseline
A multi-account cloud foundation in OpenTofu and Terragrunt, customized for your organization, deployed into your accounts by our engineers, then handed over with the repositories and the documentation.
-
BuiltForProd Managed
Experienced engineers who operate, secure and evolve production as an extension of your team, working through your own access, pull requests and pipelines.
What you get
-
A running cluster per stage
Development, staging and production clusters defined in code, with production configured for high availability and development sized down deliberately.
-
GitOps delivery
Declarative delivery with a chart per application, automatic sync in development and approval-gated sync in production.
-
A worked example, end to end
A sample application and single-page front end that demonstrate the whole path: build, scan, publish, deploy, promote and observe.
-
Autoscaling that was designed before the spike
Horizontal scaling for the application and automatic node provisioning with a ceiling you set, so a traffic event is a configuration you chose rather than an incident.
-
A golden path for new services
Step-by-step guides for adding a new infrastructure repository and a new application repository, with the common mistakes documented in advance.
-
Logging and ingress wired in
Cluster log forwarding, DNS records managed from the cluster, certificates issued automatically, and ingress that terminates only over HTTPS.
Every repository and every cloud account stays yours. We keep no standing access after handover. See security and ownership for how that is enforced, and pricing for how an engagement is quoted.
What is in the Blueprint
A working system in three repositories, not a reference diagram.
| What | Figure | Where it comes from |
|---|---|---|
| Components per stage | 17 services, 8 components | The Web App Blueprint: 17 AWS services and 8 Kubernetes components deployed for each stage, on EKS 1.36. |
| Promotion gates | 3 | Web App Blueprint. Merge to development, release to staging, manual approval and sync to production, with the same immutable image. |
| Production scaling | 3 to 10 replicas | Web App Blueprint production sizing, with node autoscaling up to a ceiling you set and three nodes across availability zones. |
| Container hardening | Default-deny | Web App Blueprint. Default-deny network policy, non-root read-only containers, all capabilities dropped and seccomp profiles. |
| Image supply chain | Blocks high and critical | Web App Blueprint. Images are scanned in the pipeline and tags in the registry are immutable. |
| Code delivered | 14 modules, 16 units | The Web App Blueprint infrastructure repository, plus five application workflows. |
The same evidence is documented page by page in the product documentation and measured against the BuiltForProd Standard.
How it works
Four steps from the first conversation to a platform your team owns.
-
Check the foundation
The Blueprint deploys into workload accounts with identity, networking and logging already in place. If that foundation does not exist yet, it is deployed first.
-
Scope the platform
Stages, sizing, domains, data services, which optional controls earn their cost, and how your teams want the promotion gates to work. Fixed fee before work starts.
-
Deploy into your accounts
Our engineers deploy the cluster, the delivery pipeline, the supporting services and the sample application, and verify the whole path from commit to production.
-
Your team promotes a release
In the handover session your engineers ship a change through every gate themselves, including an approval and a production sync. Then the repositories are yours.
Yes, but…
The objections we hear on the first call, answered plainly.
Do we really need Kubernetes?
Often not. If you run a handful of services with steady traffic, simpler compute is cheaper and calmer, and we will say so. Kubernetes earns its complexity when you have many services, many teams or workloads that need a shared platform.
We already have a cluster. Can you work with it?
Sometimes. If the cluster is reachable from a landing zone with sane identity and networking, adopting it can be viable. If it was built by hand with public endpoints and no policy, rebuilding is usually faster than remediating.
Is this a managed platform we rent?
No. The cluster runs in your cloud accounts, the code and the charts are in your repositories, and there is no control plane of ours in the path. Not a black box you rent.
Will our developers have to learn Kubernetes?
Less than you fear. The golden path gives them a repository layout, a chart and a pipeline, so the day-to-day interaction is a pull request and a release, not cluster administration.
How does this stay current?
Cluster and component versions move forward through the documented upgrade flow with a risk matrix, and Managed engineers can run those upgrades through your own pull requests.
Questions
What is the Web App Blueprint?
The Web App Blueprint is a production-ready reference architecture for a containerized web application, delivered as three repositories — infrastructure, application code and GitOps configuration — and deployed into your own workload accounts. It is a working system, not a diagram.
Does it include our application?
It includes a working sample application and single-page front end that demonstrate the full path. Your own application follows the same golden path, and porting it is application work that we can help with separately.
How do secrets reach the cluster?
Encrypted in Git, decrypted by a cloud key the pipeline controls, written to parameter storage and delivered into workloads by an operator. No secret is typed into a cluster by hand.
What observability is included?
Cluster log forwarding to central logging, metrics and traces collected into an observability account, and documented attachment points for external monitoring and paging tools your team already uses.
Can we add more Blueprints later?
Yes. Additional Blueprints are deployed into the same workload accounts, read network facts from parameter storage and carry their own deployment role and state, so they do not touch the landing zone.
More answers are in the FAQ and the support center.
Get the year back.
Tell us what you run, how many services and teams you have, and where your cluster plans are stuck. We will tell you whether Kubernetes is the right answer and what a deployment would involve.