INFRASTRUCTURE CANVAS

Draw it. Read the Terraform. Then decide.

BETA

Design cloud infrastructure as a graph, let Talos generate the Terraform, and review exactly what a plan would create, change or destroy before anything is applied. One canvas for AWS, Azure, GCP and Oracle.

Terraform · AWS · Azure · GCP · Oracle Cloud · plan-then-apply

VPC
main-vpc
est. no charge
EC2 Instance
app-server
est. $15/mo
RDS Database
app-db
est. $187/mo
Application Load Balancer
app-lb
est. $23/mo
≈ $225/mo ± usage

SEE IT RUN

The infrastructure canvas2:08

THE MANUAL WAY

What happens between the whiteboard and the apply.

THE DIAGRAM THAT GOES STALE

The architecture diagram was drawn once, in a tool that knows nothing about Terraform. It was accurate for about a week. Nobody updates it, because updating it changes nothing.

THE PLAN NOBODY READS

Forty resource addresses scroll past in a terminal. Somewhere in there is the one line that says your database is being replaced. The review becomes a formality.

THE WRONG WORKSPACE

The command was right. The directory was not. The usual mistake is not the wrong button; it is the right button in the wrong environment.

Six things the canvas does that a text editor cannot.

Typed connections

Outputs and inputs carry meaning, not just a name. A network id cannot be dropped into a field that wants instance ids. The connection is refused while you are still dragging it.

Generated forms

Every field is generated from the Talos module catalogue. There is no hand-written form for any module, so a module that gains a variable gains a field.

Cost while you design

An estimate sits on the node itself, updating as you change an instance size. If a line item cannot be priced, the total is withheld rather than quietly understated.

Terraform you can read

The generated root module is shown in full, read-only, with sensitive values redacted. You edit the diagram; the Terraform code is generated from it.

Review per node

One node is often ten cloud resources. The review shows each node’s worst outcome, with the underlying addresses one click away.

A gate you cannot click through

A plan that replaces or destroys requires typing the canvas name. The affected nodes are named, not counted.

talos.internal/aws/canvas/prod-eu
prod-euPLANNEDAWS · us-east-1 · 4 resources

ADD RESOURCE

NetworkingComputeDatabasesLoad balancingKubernetes
VPC
main-vpc
EC2 Instance
app-server
RDS Database
app-db
Application Load Balancer
app-lb
IssuesTerraformPlan1HistoryCostAdoptBridges
createmain-vpc
createapp-server
replaceapp-db
createapp-lb
plan
$ canvas plan prod-eu
→ 4 to create · 1 to replace · 3 unchanged
✓ aws.network.manage · required by main-vpc, app-lb
✓ aws.ec2.create · required by app-server
✓ aws.rds.create · required by app-db
! app-db will be replaced: new endpoint, empty disk
→ confirmation required: type "prod-eu"

A plan you can review clearly is worth more than a faster apply.

Many tools focus on applying changes quickly. Talos focuses on the review that comes first. The canvas exists so that the review step has something to review against: a drawing you made, a generated file you can read, a per-node summary of what is about to happen, and a computed answer to whether you are allowed to do it. Applying is the simple final step.

The permission verdict is computed from the plan, not from the canvas, using the same code the apply endpoint enforces, so the screen and the gate cannot disagree.

One canvas is one Terraform workspace, so it applies as a unit. There is no partial apply, and the product says so rather than implying one.

Resources in the workspace that belong to no node on the canvas are surfaced, so nothing outside the canvas changes without you seeing it.

plan · by node

main-vpc
aws_vpc · 2 subnets · route table
CREATE
app-server
aws_instance · security group
CREATE
app-db
aws_db_instance · subnet group
REPLACE
app-lb
aws_lb · target group · listener
CREATE

Bring the infrastructure you already have onto the canvas.

Point the canvas at a resource somebody built by hand three years ago. Talos runs a real terraform import, then shows you what the next plan would do to it, and refuses outright if adopting it would change something. Nothing is claimed until you accept it as a second, separate step. Where the module owns a secret that an import cannot recover, Talos asks for it, so the next plan leaves the live credential unchanged.

ALLOW: no changes

The import matched the module exactly. Adopting it would change nothing, so it is safe to accept.

CONFIRM: needs review

The next plan would alter the resource. You are shown what, and nothing is claimed until you accept.

BLOCK: refused, rolled back

Adoption would have destroyed or replaced the resource. The import was reverted before you saw the result.

AWSSUPPORTED

VPC · EC2 · RDS · ALB · EKS

AzureSUPPORTED

VNet · VM · Flexible Server · App Gateway · AKS

GCPSUPPORTED

VPC · VM · Cloud SQL · HTTPS LB · GKE

OracleSUPPORTED

VCN · VM · MySQL · Autonomous DB · LB · OKE

Same canvas, same review, same gate. The module names differ because the clouds do.

RELATED CAPABILITIES

Cloud managers

Accounts, inventory, stacks and cost across all four providers.

/capabilities/cloud →

Kubernetes

A cluster you draw here becomes a Kubernetes project in one step.

/capabilities/kubernetes →

Servers

An instance you apply here becomes a managed host with an audit trail.

/capabilities/servers →

Draw one canvas. Review the plan first.

A plan reads your cloud account and changes nothing. Start there.

Install itRead the docs →