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. AWS, Azure, GCP and Oracle — the same canvas.

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

THE MANUAL WAY

What happens between the whiteboard and the apply.

THE DIAGRAM THAT ROTS

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 was a formality and everybody knows it.

THE WRONG WORKSPACE

The command was right. The directory was not. The failure mode is never 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 wire is refused while you are still dragging it.

Generated forms

Every field comes from the module catalogue the backend serves. 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. The graph is the source of truth; the HCL is the artefact.

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 actually review is worth more than a plan you can run faster.

Most infrastructure tooling optimises the distance between an idea and an apply. Talos optimises the moment in between. 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. The apply is the least interesting part.

The permission verdict is computed from the plan, not from the canvas — by 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, because applying over something the canvas cannot show is how infrastructure disappears quietly.

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

The infrastructure you already have can move in.

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, because the alternative is a plan that silently resets a live credential.

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.

AWSFULL

VPC · EC2 · RDS · ALB · EKS

AzureFULL

VNet · VM · Flexible Server · App Gateway · AKS

GCPFULL

VPC · VM · Cloud SQL · HTTPS LB · GKE

OracleFULL

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. Do not apply it.

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

Install itRead the docs →