Skip to content
moduloom, home

Personal project · in development

Design your cloud architecture. Ship it as Terraform.

Build it on a canvas from your platform team's approved modules, with your guardrails checked as you go. You get a pull request with deterministic, plain HCL that Terraform and OpenTofu both run. Your pipeline plans and applies; Moduloom never touches your cloud.

Try itRead how it works

Questions? Write to contact@moduloom.dev

Illustration of the Moduloom canvas for an application environment in AzureThe prod environment of a fictitious payments application is selected, next to dit and uat tabs for the same design. A resource group in eastus2 and a Log Analytics workspace connect to a virtual network with address space 10.20.0.0/16. The virtual network connects through typed subnet_id edges to a Key Vault with a private endpoint and to an Azure SQL server whose password comes from Key Vault. A rule check at the bottom reports no overlapping ranges, valid names, and the required tags present.dituatprodworkspace_idresource_group_namesubnet_idsubnet_idlog_analyticslog-payments-proddiagnosticsresource_grouprg-payments-prodeastus2virtual_networkvnet-payments-prod10.20.0.0/16key_vaultkv-payments-prodprivate endpointsql_serversql-payments-prodpassword from Key Vaultrules: no CIDR overlap · names valid · required tags present

Openfeat(payments): add prod environment

ciap/payments/prod → main

main.tf
+ module "vnet" {
+   source  = "Azure/avm-res-network-virtualnetwork/azurerm"
+   version = "0.8.1"
+
+   name                = "vnet-payments-prod"
+   location            = "eastus2"
+   resource_group_name = module.rg.name
+   address_space       = ["10.20.0.0/16"]
+ }
  • ciap diff: HCL matches the design
  • plan: waiting for your pipeline

Illustration with fictitious data, not a product screenshot.

The problem

Diagrams drift from reality. Hand-written Terraform drifts from standards. Reviews catch both too late.

Moduloom keeps them together: the design is the source, it can only use modules your platform team approved, and it produces the Terraform you review.

How it works

  1. Start from approved modules

    The catalog holds the modules your platform team trusts, pinned by commit and checksum: Azure Verified Modules and terraform-aws-modules today. Inputs fixed by policy stay fixed.

  2. Compose them on a canvas

    Drag modules onto the canvas and connect them. Connections are typed: an output only connects to an input that accepts it. Each module gets a form generated from its variables.

  3. Check the design against your rules

    Rules run as you design: overlapping CIDR ranges, invalid names, missing required tags, overridden policy inputs, and sensitive inputs set as literals instead of Key Vault references. Each finding points to its node.

  4. Get Terraform as a pull request

    Moduloom renders deterministic HCL, parses it back, and checks it against the design. Opening the pull request in GitHub or Azure DevOps is coming; today you render with the CLI and commit the result.

What you can design

Anything your catalog has modules for. A few examples, marked with what works today and what is in progress.

Featured · Azure today

Self-service environments for app teams

An app team composes its own environment from the platform's approved modules: a spoke network peered to the platform hub, subnets with network security groups, private DNS, Key Vault, Log Analytics, and the app's database. The platform team reviews one pull request instead of hand-writing Terraform for every request.

  • Guardrails while they design. Subnets inside the spoke's address space and not overlapping, environment ranges that do not overlap, required tags, valid names, inputs pinned by policy, and secrets only as Key Vault references.
  • Peered to the hub you already run. The hub is referenced by its resource ID, and nothing is created there. Checking the spoke against the hub's address ranges is planned.
  • DIT, UAT, and PROD from one design. Each environment is an overlay with its own region, ranges, and sizes, and a diff view shows what differs. A promotion flow is planned.
An application spoke peered to the platform hub in AzureOn the left, the platform hub virtual network in eastus2 with address space 10.0.0.0/16 and shared services. It already exists and is drawn dashed: the design only refers to it. On the right, the orders application spoke for the dit environment, designed in the canvas, with address space 10.40.0.0/22, an app subnet with a network security group, a data subnet, a Key Vault, an Azure SQL server, and Log Analytics. The spoke is peered to the hub. A rule check at the bottom reports that the subnets are inside the spoke address space and the required tags are present.hub · existing · referencevnet-hub-eastus2Owned by the platform team.address space10.0.0.0/16shared servicesfirewall · DNSspoke · dit · designed in the canvasvnet-orders-dit10.40.0.0/22subnetssnet-app + nsg · snet-dataserviceskey vault · sql · logspeeringrules: subnets inside 10.40.0.0/22 · required tags present

  • Azure today

    A network segment

    A virtual network with subnets, network security groups, private DNS zones, and peering. Subnets are checked against the address space and against each other.

  • Azure today

    A data tier with secrets

    Azure SQL and storage behind private endpoints. Passwords come from Key Vault references, never from literals in the design or in the generated code.

  • Azure today

    One design, several environments

    DIT, UAT, and PROD, or several regions, as overlays of the same design: same topology, different values. A diff view shows what changes in each environment.

  • Azure today · AWS in progress

    A multi-cloud network baseline

    The same network pattern on each cloud: virtual network or VPC, subnets, encryption keys and secrets, and tags, from Azure Verified Modules and terraform-aws-modules. On AWS, the VPC, S3, and KMS designs are already rendered and applied in CI against AWS Emulator; Secrets Manager and SSM references, more modules, and AWS rules are being added.

Built for regulated teams

Moduloom writes code and opens pull requests. It cannot touch your cloud, and that is by design.

  • Guardrails while you design

    Rules check every change in the canvas, before anything reaches a pull request. Reviewers get a design that already follows your standards.

  • Deterministic output

    Same design, same HCL, byte for byte. Every value is escaped, and every output is parsed back and checked before it is written.

  • No cloud credentials

    Moduloom holds no Azure or AWS keys and never runs plan or apply. The most it can do is open a pull request.

  • Your pipeline applies

    The code lands in your repo, and your own pipeline applies it with OIDC, your state, and your choice of Terraform or OpenTofu.

  • Self-hosted

    Runs in your environment, so designs and network layouts stay there. A Helm chart for EKS, AKS, and kind is in progress.

  • Azure and AWS

    Azure works today with the azurerm provider. AWS is in progress with the aws provider.

Read the security principles and disclosure policy

Try it

Moduloom is a personal project in active development. Designing and rendering Azure infrastructure works today; AWS and pull requests from the editor are in progress. It is free to run yourself, and nothing is for sale.

The repository is private while it is in development. Write to contact@moduloom.dev for access.

Quickstart

You need git, uv, pnpm, make, and Docker for the editor's local database.

# 1. Get the code and install dependencies
git clone https://github.com/carlosv1989/moduloom
cd moduloom
make install

# 2. See the generated Terraform for an example design
make render EX=examples/azure-dr ENV=dr-centralus

# 3. Run the editor: API and Postgres in one terminal...
make api-dev

# 4. ...and the web app in another (after: make api-create-admin EMAIL=you@example.test ORG=Demo)
pnpm --filter @ciap/web dev
  1. Clone the repository and install the Python and frontend dependencies.
  2. Render the example Azure design to see the Terraform it generates.
  3. Start the API with its local Postgres, in a first terminal.
  4. Create a local admin (replace the email), then start the editor in a second terminal.

Moduloom never runs plan or apply, so the quickstart needs no cloud account. Questions or feedback:contact@moduloom.dev.

Frequently asked questions

What is Moduloom?

A self-hosted visual designer for platform and cloud teams. You compose infrastructure from approved Terraform modules, rules check the design, and the result is deterministic Terraform that is reviewed in your repo like any other change.

What works today?

For Azure: the module catalog, the canvas with typed connections, the rules, environments, and the Terraform render, in the editor and in the CLI. AWS is in progress. Opening pull requests from the editor in GitHub and Azure DevOps is coming.

Does Moduloom need access to my cloud?

No. It never stores cloud credentials and never runs plan or apply. Your pipeline authenticates to the cloud with OIDC under your own identity.

How can I try it?

Run it locally with the quickstart in the Try it section. It needs no cloud account. The repository is private while it is in development, so write to us for access.