Draw the architecture.
Get the infrastructure code.

Drag real cloud and on-premises components onto a diagram. It is checked as you draw, and turns into Terraform, Ansible and a deployment pipeline you can run. The diagram itself is stored as code, so every change to your architecture is reviewed and on the record.

Open the editor See how it works

AWS · Azure · Google Cloud · Alibaba Cloud · On-premises

→

# main.tf
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "app_a" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.11.0/24"
}

resource "aws_instance" "app_1" {
  subnet_id = aws_subnet.app_a.id
  ...
}

How it works

1
Draw

Drag components from the library onto the canvas: accounts, networks, subnets, servers, load balancers, databases, Kubernetes, functions, storage, DNS. Connect them and set their properties.
2
Check

The diagram is validated as you work. Overlapping address ranges, a server in the wrong kind of network, a subnet that is already in use: you see the problem when you make it, not at deploy time.
3
Generate

You get the code for every account in the diagram, the order to deploy it in, and a pipeline that does it. Commit it beside the diagram it came from.

The architecture is code too

The diagram is not a picture in a drawing tool. It is a plain YAML file: people can read it, tools can read it, and it lives in source control beside the infrastructure code it produces.

Readable by people and by machines

Every component, property and connection is a few lines of YAML. Edit it on the canvas or in a text editor; scripts and other tools can read and check it too.
Every change is a reviewed diff

Opening a port or resizing a server shows up as a line in a pull request. The design change and the code it generates are reviewed and merged together.
An audit trail you already have

Your source control history records who changed the architecture, when, and who approved it. Nothing extra to maintain, and any version can be brought back.

orders.yaml

kind: Diagram
metadata:
  name: orders
spec:
  components:
    - id: app-1
      type: aws-ec2-instance
      parent: app-subnet
      properties:
        instanceType: t3.small
        privateIp: 10.0.11.10
  connections:
    - { from: app-1, to: orders-db, port: 5432 }

Pull request · Let the app reach the batch server

       properties:
-        instanceType: t3.small
+        instanceType: t3.large
   connections:
     - { from: app-1, to: orders-db, port: 5432 }
+    - { from: app-1, to: batch-server, port: 8443 }

Reviewed, approved and merged. It stays in the history.

What you get

Code you can read

Terraform for the clouds and Ansible for on-premises servers, one self-contained folder per account. Connections on the diagram become the firewall rules between components.

Hybrid by design

One diagram can span several clouds and your own data centre, joined by VPNs. Each side gets its own code, and the deployment order between them is worked out for you.

A pipeline, not just scripts

Ready-made pipelines for Azure DevOps and GitHub Actions, plus Bash and PowerShell scripts for anything else. A pull request plans; a merge applies.

Terraform state, set up properly

Place a Terraform State component and each account gets a remote backend, plus a one-off bootstrap script that creates the storage for it.

Dependencies, derived

You never draw deployment order. It comes from what contains what and what talks to what, and you can see it as a graph before anything is deployed.

Migration assistant

Map a design from one cloud to another, or from on-premises to cloud. Components are swapped for their equivalents and you are told what still needs a decision.

Made for small teams

Architecture as Code is built for organisations where one architect, or a small team, owns the design and the deployment. The diagram is the single place the design lives: what is drawn is what gets built.

Open the editor

Draw the architecture.Get the infrastructure code.

How it works

Draw

Check

Generate