Heimdall

PLATFORM

Seven modules, one permission model.

Each module has its own page: the mechanism, where the data lives and who approves what. The order follows the cycle, from the map of what you run to the incident.

Talk to engineering

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

  • 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 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 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  admin@demo.example.com  prod         2        site-agent  127.0.0.1  1
2026-10-10T06:18:45Z  admin@demo.example.com  prod         3        site-agent  127.0.0.1  1

    See the 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'\'';'
    Real output, through the Heimdall proxy.

    See the 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 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 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 module

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.

Talk to engineering

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