Importing & Exporting Infrastructure-as-Code

Already have infrastructure described as code? Instead of redrawing it by hand, import it and Strata renders it as a typed diagram — across AWS, Google Cloud and Azure — with containment (VPC → subnet → instance) and relationships derived automatically.

Supported formats

CloudFormation templates (AWS), in either JSON or YAML (including the short-form intrinsic tags like !Ref, !GetAtt, and !Sub).
Azure ARM templates (JSON) — the typed resources[] array, with dependsOn and resourceId(…) references.
Terraform (and OpenTofu), as the JSON produced by terraform show -json or tofu show -json (current state, or a plan -json), for the aws, google, and azurerm providers. A single state file may mix providers. OpenTofu is a drop-in Terraform fork sharing the same HCL and show -json schema, so its output imports identically.

Strata auto-detects the format and provider from the document, so in most cases you don’t need to tell it. (Resource types are provider-prefixed — aws_*, google_*, azurerm_* for Terraform; the ARM/CloudFormation type carries the namespace — so a mixed-cloud state resolves into one diagram.)

How to import

Open the importer — Data ▾ → Import IaC (Terraform / OpenTofu / CloudFormation / ARM)…, the Import IaC card in the Start hub, or Import IaC in the ⌘K command palette.
Select the template or state file. Strata auto-detects format and provider.
Strata parses it, matches each resource to a known service in the multi-cloud catalog, lays the nodes out on a grid, and draws the typed relationships. The status line reports “Imported N resource(s) from <format>.” (plus any unmapped types).

Containment is reconstructed from the source:

In CloudFormation, a resource’s VpcId, SubnetId, ClusterArn, etc. (when it points at another resource in the same template via !Ref / !GetAtt) nests that resource inside its parent. Remaining references and DependsOn become depends_on edges.
In ARM, child resource types (e.g. Microsoft.Sql/servers/databases) nest under their parent, and dependsOn / resourceId(…) references become depends_on edges.
In Terraform, a containment reference (vpc_id/subnet_id on AWS, network/subnetwork on GCP — matched by id, name, or self-link) nests a resource under its parent. depends_on becomes depends_on edges.

Generating Terraform / OpenTofu input

From your Terraform (or OpenTofu) working directory:


terraform show -json > state.json   # Terraform
tofu show -json > state.json        # OpenTofu (identical output)

Then open the contents of state.json in the Import IaC dialog (the file picker also accepts .tf / .tofu / .tfstate). Nested modules (child_modules) are walked automatically.

Example: a small CloudFormation template

Importing this YAML produces a VPC containing a subnet, which contains an EC2 instance:


AWSTemplateFormatVersion: "2010-09-09"
Resources:
  MyVpc:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
  MySubnet:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref MyVpc
      CidrBlock: 10.0.1.0/24
  MyInstance:
    Type: AWS::EC2::Instance
    Properties:
      SubnetId: !Ref MySubnet
      InstanceType: t3.micro

What if a resource doesn’t show up?

Strata only renders resource types it recognizes. Any source type without a mapping is skipped and reported back as an “unmapped types” warning after the import. That’s expected for less common services — the rest of your diagram still imports fine. Unmapped types are good candidates for a contributor to add to the service catalog (see the engineering IaC Import docs).

After importing

Imported resources are marked as imported, so you can tell them apart from ones you drew by hand.
You can edit, connect, and rearrange them just like any other node.
Validate the design or save it for later.

Exporting to IaC

The reverse direction: turn the diagram on your canvas into CloudFormation or Terraform / OpenTofu (the HCL is valid for both). Open the Export to IaC dialog from Data ▾ → Export to IaC…, the Export to IaC card in the Start hub (shown once the canvas has resources), or Export to IaC in the ⌘K command palette.

Provider scope. The export dialog currently emits AWS CloudFormation and Terraform; GCP/Azure resources in a mixed diagram are reported as skipped. (GCP Terraform and Azure ARM/Terraform generation exist in the codebase and are on the roadmap for the dialog.)

In the dialog you can:

Choose a Format from the dropdown — CloudFormation (YAML), CloudFormation (JSON), or Terraform (HCL).
See a live preview of the generated output below the controls.
Copy it to the clipboard (the button briefly reads Copied ✓), or Download it. The download button is labelled with the filename — which is strata-template.yaml, strata-template.json, or strata.tf depending on the format you picked.

It’s a scaffold, not a finished template

Be deliberate about what export does and doesn’t give you. Strata models a curated subset of each service’s configuration, so the output is a correct starting point you finish by hand, not a deploy-ready, loss-free template:

Resource types and dependencies are real. Each node becomes a resource of the right CloudFormation type / Terraform type, and containment + relationships become DependsOn / depends_on.
Property names follow Strata’s model. They reflect the fields Strata tracks, not the provider’s full schema — you’ll likely need to map or add some.
Required fields you didn’t set become TODO markers in the output.

Between the controls and the preview, the dialog shows a coverage report — a line reading “N resource(s) exported”, plus “N skipped” (services with no target type, listed on hover) and “N field(s) need your input” when either applies — followed by the reminder that the output is a scaffold, not deploy-ready. So there are no silent gaps.

This pairs with import: you can bring in an existing template, edit visually, and export a scaffold back out — just expect to reconcile the details against your real configuration.