Trust and isolation

Running your OpenTofu means running your code — providers are arbitrary binaries, and external data sources run commands. This page is the honest account of what contains that, for the security review an evaluator will run.

The Run sandbox

Each hosted Run executes as a one-shot Kubernetes Job — a fresh pod per Run, nothing surviving it — in a dedicated, locked-down namespace. The pod runs non-root, drops all Linux capabilities, mounts no cluster credentials (no ServiceAccount token), and is bounded to its runner tier’s CPU, memory, and disk. A namespace-wide quota caps how much the sandbox as a whole can ever consume, so a busy queue can’t crowd out the platform.

Be clear about the boundary today. Runs currently execute under the cluster’s default container runtime (runc), not a stronger sandbox. Hardware- grade isolation (a gVisor runtime, and beyond it per-Run microVMs as a hardened tier) is designed and on the roadmap; the runner protocol doesn’t know which sandbox it runs in, so tightening it is an operations change, not a redesign. For launch the blast radius is capped structurally — one throwaway pod per Run, no cluster identity, no access to the internal network (below), and each Run sees only its own Stack’s secrets — rather than by the runtime alone. If your threat model requires VM-grade isolation, a self-hosted runner pool (on the roadmap) runs the same agent on your own machines.

Network egress

The sandbox is default-deny in both directions. A Run may reach exactly two things:

• DNS, to resolve names.
• The public internet — cloud APIs, public module and provider registries.

Everything private is blocked: RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), the cloud metadata service (169.254.169.254), and every in-cluster address. A Run reaches the Longbridge control plane only over its public hostname, exactly as a stranger’s laptop would.

The practical consequence: a private or internal registry or provider mirror won’t work from a hosted Run — anything served from inside your own network is unreachable. Use public sources, or a self-hosted pool with your own network reach. See Troubleshooting.

Encryption

Stacks uses envelope encryption. Each Stack has its own data key, wrapped by a platform service key. State versions, plan artifacts, and logs are all sealed under the Stack’s own key before they reach object storage — plaintext never rests there.

One thing OpenTofu itself forces: state carries your resources’ attributes in plaintext by design. That’s why a state key is a sensitive credential — treat it accordingly, and rotate freely (they’re revocable).

What’s enforced, and what’s best-effort

Not everything that helps is a guarantee. Know which is which — an enforced boundary holds; a best-effort courtesy helps but is not one.

Boundaries — enforced:

• Per-Stack isolation. A Run sees only its own Stack’s variables, state, and identity tokens — never another Stack’s, never another organization’s.
• Write-only sensitive variables. A variable marked sensitive is envelope-encrypted and never readable back through any API — a compromised Console session can overwrite a secret, not exfiltrate it.
• Outputs-only cross-Stack reads. A downstream reads an upstream’s root outputs only; the full state blob never transits a runner. See Dependencies & cascade.

Courtesies — best-effort, not a boundary:

• Log masking. Sensitive values are scrubbed from logs by best-effort substring replacement. It’s a courtesy — don’t treat a masked log as proof a secret can’t leak. Plan artifacts, which can embed resolved secrets, get state-grade encryption at rest and never appear on the PR page.

The four credentials you touch

People conflate these constantly — they do different jobs, are minted by different parties, and have different reach.

Credential	Who mints it	Lifetime	What it can do
State key	you, in the Stack’s settings	until you revoke it	HTTP-basic access to one Stack’s hosted state from a tofu CLI
Runner key	you, per runner pool (self-hosted)	until you revoke it	register an agent into that pool; it then reaches only that pool’s Runs, their variables, state, and identity tokens
Run identity token	the Longbridge control plane, per Run phase	10 minutes	prove one Run’s identity to your cloud or Vault — whatever your trust policy grants its subject
GitHub installation token	Longbridge, per Run, from the App install	dies with the Run	read-only clone of your configuration

The Run identity token is the security wedge: your cloud trusts it instead of a stored key, so no static cloud credential rests with Longbridge. The installation token is read-only and per-Run — there’s no long-lived deploy key to leak. Inside a hosted Run the platform also manages an internal per-Run claim token (runner-to-control-plane auth) and a per-Run state credential; you never see or handle those.

Where your data lives

• Run execution happens on the eu-hel shard — Hetzner, Helsinki, in the EU.
• Metadata — your Stack configuration, Run records, and the state-version index — lives in the platform’s EU Postgres on the same shard.
• State is envelope-encrypted before it is written to object storage and stays under EU data residency.

Nothing about a Run reaches your cloud except the short-lived identity token your own trust policy accepts.