Architecture canvas
Every workload, database and queue, on one canvas.
The canvas is not a diagram you maintain. It is read from the infrastructure Kapten provisions inside your account — so it is correct by construction, and editing a node changes the infrastructure rather than a picture of it.
- Read from
- Your AWS account, live
- Objects
- Services, data stores, queues, routes
- Interaction
- Pan, zoom, inspect, connect
- Underneath
- Kubernetes, Helm, Terraform
- Live
- Deploying
- Queued
- Sleeping
- Failed
What it gives you
A map that cannot be out of date.
Architecture diagrams rot because they are documents. This one is a read of the account, so the only way for it to be wrong is for production to be wrong.
Read, never drawn
The graph is derived from what is actually running in your VPC. There is no diagram file to keep updated, and no way for it to quietly drift from production.
Inspect any node
Open a service and get its image, its replica count, its environment bindings and the deployment that put it there — the same inspector the dashboard uses.
Edges are real routes
A line between two nodes means a security group rule and an internal DNS name that exist. Draw one and it is provisioned; remove it and it is revoked.
Data stores are first class
Managed Postgres, Redis and queues are nodes with their own health and their own connection strings, not boxes drawn around something the diagram cannot see.
Health rides on shape
Status is carried by the node silhouette as well as its colour, so a degraded service is legible at a glance — and stays legible to the ~8% of men who lose the green/amber/red axis.
One canvas per environment
Production, staging and every preview environment get their own. Nobody reasons about staging while looking at a picture of production.
Ready when you are
Your cloud. Our ergonomics.
Connect a cloud account and watch a production-grade environment come up in your own VPC. If it isn’t serving traffic in fifteen minutes, we want to hear why.