ARCH — Architecture Control Hub

ARCH is an architecture-as-code platform. You lay out a cloud topology on a canvas, and ARCH generates the Terraform configuration that provisions it. The canvas is not documentation that sits beside the infrastructure; it is a projection of the same model the generator reads.

The idea came out of the apprenticeship at Adex International. Every architecture review started with a diagram in a slide deck, and every implementation ended with Terraform that had quietly diverged from it. Nobody was at fault. There was simply no mechanical link between the two artefacts.

Three problems compound in most infrastructure teams.

• Diagrams are drawn once, for a review, and then abandoned. They describe an intent that the running system stops matching within weeks.
• Terraform is precise but hostile to read as a system overview. You can audit a module and still not know the shape of the network.
• Multi-cloud work multiplies both problems. The same logical pattern, a load-balanced private tier behind a managed database, is spelled three different ways across AWS, Azure and Google Cloud.

The gap is not tooling for any single step. It is that no artefact is authoritative.

Make the graph the source of truth and treat everything else as a rendering of it.

A design on the canvas is stored as a typed graph: nodes carry a provider-neutral kind, edges carry a relationship. A network node knows it is a network; it does not yet know whether it becomes an aws_vpc or an azurerm_virtual_network. Provider mapping happens at generation time, so one design can target more than one cloud.

Generation produces plain Terraform, laid out the way a person would write it, in files a reviewer can read in a pull request. There is no proprietary intermediate format holding the output hostage. If ARCH disappeared tomorrow, the Terraform it produced would keep working.

The system splits into four layers.

Canvas

A client-side editor holding the graph in memory. Nodes snap to a coarse grid, edges validate against a small rule set (a subnet cannot contain a region, a database cannot route to the internet directly). Validation happens as you draw, not at generation time, so the feedback loop stays tight.

Model

A provider-neutral schema. Each node kind declares required properties, optional properties and permitted children. This is the contract the canvas validates against and the generator compiles from.

Generator

A per-provider compiler. Each provider implements a mapping from node kinds to resource types, plus a naming and tagging convention. The generator emits a module tree rather than a single flat file, because that is what survives review.

Registry

Reusable pattern templates. A three-tier web application, a private data platform, a batch pipeline. These are the shapes teams draw over and over, captured once as parameterised graphs.

Terraform for provisioning, since it is the one tool that speaks to all three providers with a single mental model. The canvas is TypeScript. The graph schema is declarative data, not code, so adding a node kind does not mean writing a compiler pass.

Deployment is planned around GitOps rather than a push button in the UI. ARCH opens a pull request containing generated Terraform; the pipeline plans it; a human approves it. The tool proposes, the pipeline enforces, and the audit trail is the Git history rather than an application log.

Built the model layer first, before any canvas code existed, and drove it from fixture graphs written by hand as JSON. That let the generator reach a working state for AWS while the editor was still a wireframe, and it left a suite of graphs that double as regression fixtures.

The AWS provider mapping covers the network and compute core: VPC, subnets across availability zones, route tables, internet and NAT gateways, security groups, EC2 and autoscaling, application load balancers, RDS instances and subnet groups, S3 buckets, IAM roles and policies.

The canvas renders with SVG rather than a charting library. A cloud topology is a constrained diagram, not a general-purpose drawing surface, and hand-rolled SVG keeps the node kinds and the render path in one place.

Naming is the hard part. Terraform resource names have to be stable across regenerations, or every redraw produces a diff that destroys and recreates infrastructure. The fix was to give each node an immutable identifier at creation and derive resource names from that identifier plus a human label, so renaming a node on the canvas changes a tag rather than a resource address.

Provider parity is not symmetric. Azure virtual networks and AWS VPCs look equivalent until you reach subnet delegation and service endpoints. Rather than force a lowest-common-denominator model, provider mappings are allowed to reject a node kind they cannot express honestly. The canvas surfaces that as a validation error when you switch target providers.

Nested state. A generated module tree that changes shape between versions is a state migration problem. Currently ARCH pins the module layout per generated version and records it in the output, so an existing deployment is regenerated with the layout it was created with unless you explicitly migrate.

Generate Terraform, not a proprietary plan. Owning the deployment step would have made the product stickier and the user more trapped. Emitting readable Terraform means ARCH has to earn its place on the quality of its output.

No apply from the UI. A button that mutates production from a web canvas is a security and blast-radius problem wearing a convenience costume. Pull request, plan, review, apply.

Provider-neutral core, opinionated edges. The model refuses to encode AWS assumptions, but each provider mapping is allowed strong opinions about naming, tagging and module structure. Neutrality in the core, judgement at the boundary.

The AWS network and compute mapping generates a plan-clean three-tier topology from a canvas design, and the pattern registry covers the shapes that came up most often during the Adex apprenticeship. Azure and Google Cloud mappings are partial: network and compute are mapped, managed data services are not.

The project is in active development and is not production software. The honest state is that the model and the AWS generator work, the canvas is usable but rough, and the GitOps deployment path is designed but not built.