05 · INTERNAL APP ACCESS

Internal apps in the browser, without a VPN.

The edge runs in your infrastructure, and TLS terminates there. Each person is granted access to a catalog service, with an expiry and a reason, and every connection is decided and recorded before the first byte.

Talk to engineering

Opens a WhatsApp chat. Prefer email? [email protected]

What it does

In the browser, with nothing to install

A dashboard, a BI tool, an in-house app: the person opens the usual address and signs in through the company's single sign-on. There is no password field. The session lasts 8 hours and covers one address.

From the terminal, by the real name

heimdall network up makes the internal name resolve on the person's computer and carries every connection through the edge. Kafka, MongoDB replica sets and Redis Cluster, which announce each node's name, work under their real names, without localhost and without changing the application's configuration.

The grant

Access is granted to a person, for one service, with a mandatory expiry of up to 90 days and a reason, read months later by whoever decides whether it still makes sense. A time window, in an IANA time zone, is optional. Only owner and admin grant; a member can't grant even themselves.

Every connection is decided

On every connection, the API asks: this person, a member of this organization, with a live grant for this service, inside the window, allowed by policy — now? The grant alone isn't enough, and neither is the policy: both must allow it.

Recorded before the first byte

The decision becomes an audit record before any byte passes, with who, from where, to which service and, on refusal, the reason. If the record can't be written, the connection is refused.

Nothing outside the catalog

A service only becomes reachable with a Component and an environment in the catalog, and a public name only under a domain the organization proved through DNS. The refusal is the same answer in every case, so the edge can't be used to list the company's portals.

Identity that can't be forged

Before handing the request to the portal, the edge strips the identity headers the browser sent — the ones portals and proxies tend to accept as "who the user is".

How it works

One connection, from browser to service:

The browser reaches the edge, which is yours. Without a session, it goes to the company sign-in.
The edge asks the API whether that person may reach that service now. The API decides and records the decision.
The Agent, already connected from the inside out, opens the connection to the service. The Agent never accepts inbound connections.
Traffic between the edge and the Agent is encrypted end to end, and the edge requires from the Agent a certificate of your organization, naming the Agent the API pointed to.

TERMINALheimdall network-grant

$ heimdall network-grant create --service grafana.lvh.me --user f8e39903-3865-85b2-837c-3270d4eeaf23 --days weekdays --from 09:00 --expires-in 30d --reason "painel de vendas"
Error: --timezone, --days, --from and --to go together, or leave all four out for a grant that is open at any time. Half a window is a rule nobody wrote

$ heimdall network-grant create --service grafana.lvh.me --user f8e39903-3865-85b2-837c-3270d4eeaf23 --expires-in 91d --reason "painel de vendas"
Error: VALIDATION_ERROR: networkedge: a grant must expire in the future and at most 90 days out (got 2027-01-09T06:20:04Z)

$ heimdall network-grant create --service grafana.lvh.me --user f8e39903-3865-85b2-837c-3270d4eeaf23 --expires-in 1d --reason "eu mesmo"
Error: FORBIDDEN: access denied

$ heimdall network-grant create --service grafana.lvh.me --user f8e39903-3865-85b2-837c-3270d4eeaf23 --expires-in 30d --reason "acompanha os painéis de vendas"
✓ Network access granted: f8e39903-3865-85b2-837c-3270d4eeaf23 → grafana.lvh.me (daily 00:00-24:00 UTC, until 2026-11-09T06:20:04Z)

$ heimdall audit list --action network_flow.denied
TIMESTAMP             ACTOR                    ACTION               RESOURCE_TYPE    RESOURCE_ID
2026-10-10T06:19:57Z  [email protected]  network_flow.denied  network_service  7263e2f4-3bfa-42df-9d1e-b5f77c66dc92

Real output of heimdall network-grant create and of the trail for a refused connection.

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.

Internal app access: where the data lives
AT THE EDGE AND IN THE AGENT	IN THE API, WHICH IS YOURS
The edge terminates the browser's TLS with your domain's certificate and sees the portal's HTTP, like any proxy in your company. The Agent dials the service from inside your network; the internal address never leaves it.	Who asked for which service, from which address, when, and the decision, in the audit trail. Each connection's duration and bytes, in the log. Not the content: what the person saw, clicked or downloaded doesn't go into the trail. Traffic crosses the API encrypted between the edge and the Agent.

See security

Who approves what

Internal app access: who approves what
ACTION	WHO
Register a service and prove the domain	`owner` and `admin`
Grant and revoke access	`owner` and `admin` — and nobody grants themselves without that role
Suspend a person without hunting down their grants	a `forbid` `policy`, which beats every permission
Connect	whoever is a member, holds a live grant and is allowed by `policy`. No `policy` lets through someone without a grant — not even the `owner`

With the other modules

01

Catalog

Every reachable service is a Component in an environment; the trail records both.
04

Database Manager

heimdall db connect goes through the same edge, with database governance on top: network grant and database approval.

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.