Where your gateway runs
Custody and execution are inseparable (see why), so the one real deployment decision is: where does your gateway run, and how is its key protected there? It is always the same gateway binary — "local", "remote", and "hosted" are three placements of it, not three different products.
At a glance
| Placement | Where the secret lives | Where the call runs | Reachable by remote agents | Needs your machine online | Plan |
|---|---|---|---|---|---|
| Local | Sealed vault on your device | On your device | ❌ loopback only | it is the machine | Free and up |
| Remote (local + tunnel) | Still on your device | Still on your device | ✅ over a secure tunnel | ✅ machine must be up | Pro and up |
| Hosted | Sealed under a per-tenant key in Secret Manager | In a Permaura-run worker | ✅ always | ❌ | Pro and up |
The trade is a slider, not a right answer: custody is strongest where execution is closest to you, and convenience grows as it moves to the cloud. You place each secret where you're comfortable.
Local
Your gateway runs on your own machine and listens only on 127.0.0.1. The secret sits in a sealed local vault; plaintext exists only inside a single call and is wiped on return. This is free, fully offline-capable after activation, and the strongest custody — at the cost of running on one machine, only when it's on. Agents on the same machine can use it; agents elsewhere (including hosted ones like ChatGPT) cannot, until you add remote access.
Remote (local gateway + secure tunnel)
Turn on remote access and Permaura gives your local gateway a stable public URL (https://g-xxxx.permaura.com) over a secure tunnel. Two things stay true:
- Your gateway still runs only on your machine; no key or data moves to the cloud.
- The tunnel is just a pipe. Agents authenticate to Permaura and connect directly to your gateway; the bytes of each call go straight to your machine.
This is the sweet spot for most people: cloud-grade convenience (any agent, anywhere, including ChatGPT) with local secret custody. It needs your machine to be online to answer calls.
Hosted
Permaura runs the gateway for you, always-on, with envelope encryption under a per-tenant vault key held in Secret Manager, and Cloud KMS wrapping the audit key and any secret you enrol to it. Most frictionless, fully multi-device, no machine of yours to keep online. The honesty rule still holds: a worker that makes the call had to decrypt the secret, so this is not zero-knowledge — the stronger-guarantee options are local or your own tunnelled gateway.
Hosted execution is included from Pro upward. If the hosted option shows as unavailable when you open the console's gateway setup, it hasn't been switched on for your deployment yet — pick a local or tunnelled gateway in the meantime; you can move later.
Approvals and approval devices on hosted
A hosted worker has no machine of yours attached to it, and that changes two things you would otherwise never notice.
Enrolling an approval device works differently. On a local or tunnelled gateway, trusting a phone's signing key takes a command run on the gateway's own machine, and being at that machine is the consent. A hosted worker has no such machine, so the Permaura app enrols the device itself after asking you to prove it's you again with your password or a two-step code. The first device is trusted on that basis alone; every device after it is confirmed by a device you already paired, so a compromised Permaura could at worst enrol one key on a gateway that has none, never join its own device to a keyring you already have. The account owner is emailed either way, which tells you an enrolment happened but does not prevent one.
Once any device is paired, the console gets quieter. Every request to a hosted worker is remote by definition, so from that point on any control-plane change that isn't strictly tightening (a new policy, a lowered rung, a widened grant, approving an agent, un-pausing the broker) waits for a signature from your device instead of applying when you click save. That is the same rule a tunnelled gateway follows for network traffic; it just applies to everything on hosted, because everything is network traffic there.
Full detail, including how to get back if the last device is lost, is in Approvals.
Bring your own vault
Where a secret is stored at rest is a separate axis from where the gateway runs, so they compose. Permaura exposes a secret-backend seam — "resolve this secret, hand its plaintext to this closure, guarantee it's wiped" — so you can keep secrets in tooling you already run:
- Local vault (built-in default) · Per-tenant vault key in Secret Manager (hosted), with Cloud KMS for enrolled secrets
- Infisical — resolve secrets from an Infisical project at call time, configured on the gateway via environment variables
- Infisical dynamic secrets — mint a fresh credential per call and hand it straight back afterwards (below)
- On the roadmap — HashiCorp Vault, Doppler, 1Password, and the cloud secret managers
The line stays honest: Permaura fetches your secret for the one approved call and wipes it; it never stores your secret at rest unless you ask it to.
Credentials that expire on their own
For anything that can issue credentials on demand (databases, cloud IAM), the gateway does not have to hold a standing credential at all. Point a secret at an Infisical dynamic secret and the gateway mints one when an approved action runs, uses it for that call, and revokes it as the call finishes.
# Machine identity, shared with the static Infisical backend above.
export PERMAURA_INFISICAL_CLIENT_ID="…"
export PERMAURA_INFISICAL_CLIENT_SECRET="…"
export PERMAURA_INFISICAL_ENV="prod"
export PERMAURA_INFISICAL_DYNAMIC_PROJECT_SLUG="acme"
export PERMAURA_INFISICAL_DYNAMIC_SECRETS="db_password=pg-readonly:DB_PASSWORD"
export PERMAURA_INFISICAL_DYNAMIC_TTL="5m" # optional; the backstop, not the usual lifetime
All five of the first block's variables are required. Set only some of them and the gateway logs that
dynamic secrets are partially configured and falls back to the local vault for those ids, rather than
starting with a half-built minting path. PERMAURA_INFISICAL_URL (default https://app.infisical.com)
and PERMAURA_INFISICAL_PATH (default /) are optional; the URL must be https, since the login
carries your client secret and every mint returns a live credential.
Each entry is secret_id=dynamic-secret-name:FIELD. The field names which part of the minted credential this secret stands for; you can omit it only when the provider returns a single field, because guessing between a username and a password would put the wrong one into a live call.
What this changes: a stolen disk image, a stolen backup, or a leaked log holds nothing that still works. The credential existed for the length of one approved action. The TTL is only the safety net for a gateway killed mid-call before it can revoke, which is why it should stay short.
What it does not change, and it is worth being plain about: the machine identity allowed to mint is now the thing worth stealing. Scope it to what those calls actually need, and remember your policy and approval rules are still a separate lock in front of it. Static API keys (Stripe, OpenAI, and most SaaS) cannot be minted this way and stay in whichever vault you chose above.
This maps to plans
The custody slider and the pricing line are the same line. Local is free and can't meaningfully be gated — it runs entirely on your machine. The paid line is reach: a public URL for your gateway and hosted always-on execution, because that's Permaura's infrastructure to run.
See Plans & billing for exactly what each tier unlocks and current prices.