Best practices that don't depend on discipline.

• 01

  CATALOG

  The map every module uses as its address.

  Domain, System, Component and environment. Everything else builds on it: releases, incidents, secrets and network services point to the same Component, instead of separate records nobody reconciles.

  See the Catalog module→

• 02

  INFRASTRUCTURE MANAGER

  Infrastructure requested from the catalog, applied inside your network.

  Heimdall plans and applies Terraform in your infrastructure, and keeps the state in your account's bucket. On AWS, GCP and Azure, the credential comes from OIDC federation by default and is never stored. When the resource schema requires approval, someone else approves the exact version they saw. Works with AWS, GCP, Azure, Kubernetes, Helm and Cloudflare.

  See the Infrastructure Manager module→

• 03

  SECRET MANAGER

  A secret's value only exists in your Agent.

  The API refuses to receive the value; it governs the name, the version, who may read it and who did. The Agent stores the value under a key you hold, and only serves a read once it has recorded it. When someone leaves the company, every secret they read is marked at_risk.

  $ heimdall secret access-log db-password

  ACCESSED_AT           ACCESSOR                ENVIRONMENT  VERSION  SERVED_BY   FROM       READS
  2026-10-10T06:18:58Z  agent site-agent        prod         3        site-agent  127.0.0.1  1
  2026-10-10T06:18:45Z  [email protected]  prod         2        site-agent  127.0.0.1  1
  2026-10-10T06:18:45Z  [email protected]  prod         3        site-agent  127.0.0.1  1

  See the Secret Manager module→

• 04

  DATABASE MANAGER

  Production access: requested, approved by someone else, set to expire.

  Every access has a named approver and an expiry, and nobody approves their own request. Commands and migrations respect the database's time window. The password is created in the Agent and stays there.

  masking by source column: a tax ID comes back as [CPF] even when the query renames it, reads it in a subquery or goes through a view. guardrails refuse a DELETE without WHERE on the spot; for it to run, someone else has to approve it, and the approval covers a single execution.

  NOTICE:  Heimdall authenticated this connection as PostgreSQL role "hd_pg_orders_orders_7cyjmwi7_hdm" under access grant 05512517-3276-4918-af87-79ef234fbd9d; any credentials you supplied were not used and were not sent to the database.
  psql (18.6, server 17.11)
  Type "help" for help.
  
  => select cpf as documento, upper(email) as e, name from customers limit 1;
   documento |    e    |   name    
  -----------+---------+-----------
   [CPF]     | [EMAIL] | Ana Souza
  (1 row)
  
  => UPDATE customers SET name = 'cliente de teste';
  ERROR:  HEIMDALL GUARDRAIL: UPDATE without WHERE clause is blocked by guardrail "DELETE and UPDATE need a WHERE" [require-where]. To run it, get it approved first, then run it again: heimdall db command submit 'b4bc0108-1814-47df-a9a9-7e591423dae6' --reason '<why this must run>' --sql 'UPDATE customers SET name = '\''cliente de teste'\'';'

  See the Database Manager module→

• 05

  INTERNAL APP ACCESS

  Internal apps in the browser, without a VPN.

  The edge runs in your infrastructure, and that is where TLS terminates. Each access is granted to one person for one service, with an expiry and a reason, and is recorded before the first byte goes through.

  See the Internal app access module→

• 06

  RELEASE MANAGER

  You approve the exact change that goes to production.

  Heimdall commits the new version to your manifests repository, and your GitOps tooling delivers it. Approvers see the diff, the gate is asked again right before the commit, and a rollback returns to the previous known version, with no one picking the target by hand.

  See the Release Manager module→

• 07

  INCIDENT MANAGER

  An incident only closes once its postmortem is approved.

  Every rollback opens an incident automatically, dated from when the bad version landed. A database break-glass is tied to the open incident, but the incident never grants access: it records why the access happened.

  See the Incident Manager module→

1. Agree on the first phase with you: what goes under rules first, and whatever needs building for it, on an agreed timeline.
2. Install the API, the Agent and the edge in your infrastructure, with your team.
3. Put your first secrets and databases under rules, with your real data.
4. Train the people who operate and the people who approve.

Leaving doesn't depend on us: you can export the organization at any time, and the Terraform state already lives in your bucket.