02 · INFRASTRUCTURE MANAGER

Infrastructure requested from the catalog, applied inside your network.

Engineers request a Resource from a resource schema your team defined. The Agent runs Terraform in your network, and the state goes to your cloud account's bucket.

Talk to engineering

Opens a WhatsApp chat. Prefer email? heimdall@yops.cloud

What it does

Your team decides what can be requested

A resource schema sets the resource type, the inputs it accepts — in a JSON Schema enforced in full, with enum, pattern and additionalProperties — the default values for each environment and, if your team wants, the Terraform module that applies it. An input outside the rule is refused before anything runs, and the refusal names the field, never the value.

Someone else approves

Under a resource schema that requires approval, creating and changing a Resource wait for someone else to approve — on the version of the request they read. Whoever asked cannot approve their own request.

Modules that the Agent's operator allowed

A Terraform module is code that runs with your cloud credentials. That is why the list of allowed sources lives in the Agent's configuration, not in the API: a resource schema that points outside it doesn't run.

The region the resource asks for

On AWS, the resource is created in the region the Resource asks for, or in its cloud account's region. Never in a region fixed by the product.

Bring in what exists, and take it with you

A resource created outside Heimdall comes under management without being recreated, with heimdall resource import. And heimdall terraform export builds a package that runs with plain terraform.

Deleting means deleting

heimdall resource delete runs only the destroy, and actually destroys the infrastructure. An apply still in the queue does not run after it. The Resource stays on the list as history.

The providers the Agent runs

AWS, GCP, Azure, Kubernetes, Helm and Cloudflare.

How it works

One apply, from request to state:

The API checks the request against the resource schema and checks that a cloud account exists for that System and environment.
The API queues a job. The row holds the request, never a credential.
An Agent picks up the job over the channel it opened itself, with mutual TLS. The Agent only makes outbound connections; the API never dials it.
With OIDC federation, the API trades a 5-minute token for a temporary credential from your cloud, which goes to the Agent with the job and is never stored. With a static credential, the API sends only the secret's address, and the Agent reads the value from its own store.
The Agent runs Terraform, at a pinned version checked by SHA-256. The state goes to the account's bucket, with the cloud's own lock.
The Agent returns the outputs, and the Resource becomes provisioned — or failed, with the Terraform output that says why. Each job gets three attempts, and an Agent that drops mid-run doesn't lose the work.

TERMINALheimdall resource

$ heimdall resource create --component 2a5e9fa9-e606-4306-883e-842f4082901d --schema a15f8f12-a127-44e0-99cd-3d2da4cc8c1d --environment 1f332b6d-e96f-85c4-a747-5a20deef94c9 --name recibos --input '{"bucket":"checkout-recibos"}'
✓ Resource created: recibos (5044c77d-f1c6-434c-adc3-cf5d03fe0e5c)

$ heimdall job list --component 2a5e9fa9-e606-4306-883e-842f4082901d --resource 5044c77d-f1c6-434c-adc3-cf5d03fe0e5c
JOB ID                                OPERATION  STATUS     ATTEMPTS  REASON  QUEUED AT
ef109461-1aa5-460a-b59c-ff2235c66371  apply      completed  1/3               2026-10-10T06:25:16.154935Z

$ aws --endpoint-url http://127.0.0.1:4666 s3 ls --recursive s3://terraform-state
2026-10-10 03:25:33       2770 heimdall/5044c77d-f1c6-434c-adc3-cf5d03fe0e5c.tfstate

Real output of heimdall resource create and heimdall job list, and the state in the account's bucket.

Where the data lives

Everything runs in your infrastructure. The split below matters inside your company: it says who on your team can reach what.

Infrastructure Manager: where the data lives
IN THE AGENT AND YOUR CLOUD ACCOUNT	IN THE API, WHICH IS YOURS
The Terraform run. The state and lock, in the bucket of each Resource's cloud account, one state per Resource — Heimdall keeps no copy. The value of a static credential, in the Agent's store.	Each Resource's inputs and outputs (an output marked `sensitive` is stored as `<sensitive>`). Each job's Terraform output, with the plan, up to 1 MiB per job. The record of who requested, who approved, and every run. The temporary credential passes through the API on its way to the Agent and is never stored.

See security

Who approves what

Infrastructure Manager: who approves what
ACTION	WHO
Create, change and retry a Resource	`owner` and `admin`, by default
Approve or refuse	whoever may manage Resources — and never the requester
Delete, which destroys the infrastructure	whoever may delete; a `policy` restricts it
Register and link cloud accounts	`owner` and `admin`; `member` can't see accounts
Decide which Terraform modules run	whoever runs the Agent, in its configuration
Read Resources and jobs	every member

With the other modules

01

Catalog

The Resource is created under a Component and belongs to a System; the cloud account resolves from the System, then the Domain, then the organization.
03

Secret Manager

A static credential is a secret in the Agent, and the API never reads its value.
07

Incident Manager

An incident can be opened about a Resource.

Talk to the people who build Heimdall.

Tell us how your engineers store secrets and reach the database today. We'll answer with what Heimdall would put under rules first, and how the deployment would get there.