Personal project · in development
Design cloud infrastructure with the modules your platform team already trusts.
Drag, connect, and open a pull request. Moduloom turns diagrams into clean Terraform built from your approved modules, and runs inside your own Kubernetes.
Questions? Write to [email protected]
Openfeat(dr): add centralus region
ciap/dr-centralus → main
+ module "vnet_dr" {
+ source = "Azure/avm-res-network-virtualnetwork/azurerm"
+ version = "0.8.1"
+
+ name = "vnet-dr-centralus"
+ location = "centralus"
+ resource_group_name = module.rg_dr.name
+ address_space = ["10.1.0.0/16"]
+ }- ciap diff: HCL matches the design
- plan: waiting for your pipeline
Illustration with fictitious data. The editor is being built.
The problem
Diagrams drift from reality. Hand-written Terraform drifts from standards. AI-generated HCL ignores both.
Moduloom keeps them together: the diagram is the design, the design produces the Terraform, and the Terraform is built only from modules your platform team approved.
How it works
Design with approved modules
Drag modules from your catalog onto the canvas (Azure Verified Modules to start). Connections are typed: an output only connects to an input that accepts it. Each module gets a form generated from its variables, validated as you type.
Review generated Terraform
Watch the HCL update next to the canvas. The same design always produces the same Terraform, byte for byte. Rules flag problems early, such as a disaster recovery range that overlaps your primary.
Open a PR, your pipeline applies
Moduloom commits the design and the generated Terraform to a branch in your repo and opens a pull request. Your pipeline runs plan and apply with your runners, your state, and your identity.
Why security teams can say yes
Moduloom writes code and opens pull requests. It cannot touch your cloud, and that is by design.
Self-hosted
Installs with Helm in your Kubernetes. Your designs and your network layout stay there.
Never stores cloud credentials
Moduloom holds no Azure or AWS keys. Your pipeline authenticates to the cloud with OIDC workload identity.
Never runs apply
No plan and no apply inside the tool. The most it can do is open a pull request.
Every change is a PR
A person reviews and approves every change in your repo, with the controls and audit trail you already have.
Deterministic output
Same design, same HCL. Every value is escaped, and every output is parsed back and checked against the design before it is written.
First use case
Stand up a disaster recovery region in Azure
Your primary region was built by hand and has no Terraform. You do not need to import anything: declare the primary as a reference, design only the new region, and open the pull request.
A reference, not a migration
The primary node only declares its region and address ranges. It creates no resources.
Address ranges that do not overlap
A rule checks every CIDR in the recovery region against the primary and flags any overlap.
Peering and database failover
Global VNet peering to the primary and an Azure SQL failover group, from approved modules.
Works with your stack
Your pipeline stays yours. Run it with Terraform or OpenTofu, your choice: the generated code is the same for both.
Cloud
Azure with the azurerm provider. AWS is in progress.
Terraform or OpenTofu
The generated HCL works with both, and your pipeline runs the binary you choose. Inside Moduloom, validation uses OpenTofu.
Azure DevOps and GitHub
Pull requests and pipeline templates for both, with self-hosted runners and OIDC instead of long-lived secrets.
EKS, AKS, or kind
One Helm chart for production clusters and for a local kind cluster on your laptop.
Optional AI · planned
AI that proposes, never applies. Runs on local open models by default.
Off unless you turn it on. Describe what you need and the assistant drafts a design on the canvas from your approved modules. You review it like any other change, and it still ends as a pull request. Pointing it at an external model endpoint is your decision.
Try it
Moduloom is a personal project in active development. The Azure disaster recovery case works today; AWS is in progress. It is free to run yourself, and nothing is for sale.
The repository is private while it is in development. Write to [email protected] 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 the Azure DR example
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 protected] ORG=Demo)
pnpm --filter @ciap/web dev- Clone the repository and install the Python and frontend dependencies.
- Render the Azure disaster recovery example to see the Terraform it generates.
- Start the API with its local Postgres, in a first terminal.
- 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:[email protected].
Frequently asked questions
Do my designs leave my network?
No. Moduloom runs in your own Kubernetes cluster, and the design is stored in your repo next to the generated Terraform. The optional AI is off by default and uses a local model when you turn it on.
Do I need Terraform Cloud?
No. Moduloom opens a pull request, and the pipeline you already run (Azure DevOps or GitHub, with Terraform or OpenTofu) does plan and apply against your own state backend.
What happens if I stop using it?
You keep plain Terraform in your repo. Nothing in the generated code depends on Moduloom, so your pipeline keeps working without it.
Can I use it today?
In part. Moduloom is a personal project in active development. The Azure disaster recovery case works today and AWS is in progress. You can run it locally by following the quickstart in the Try it section.