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	Free and up with your own tunnel or domain; Pro and up for a managed tunnel
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://my-laptop.permaura.app) over a secure tunnel. Two things stay true:

• Your gateway still runs only on your machine, and your keys and data are stored there, not in the cloud.
• Agents authenticate to Permaura and connect to your gateway over the tunnel; the bytes of each call go to your machine, not through permaura.com.

From gateway 1.3.48 and desktop 1.4.21, permaura.com creates a managed permaura.app tunnel and its name, and the gateway or the desktop app writes the connector's configuration on your machine, with your gateway's port on 127.0.0.1 as the one destination for that name. The gateway or the app also stops the connector within about a second if Cloudflare's side ever pushes it a different configuration or routes private-network traffic through it. Permaura and Cloudflare still carry the traffic for that name; What Permaura protects states what that leaves them able to do, that second included.

The console and the Permaura app are the exception: they reach a tunneled gateway through permaura.com, which relays their requests in memory and without logging them, including a credential you type there. The FAQ has the detail and how to avoid it.

An agent that signed in through permaura.com counts as remote even when it runs on the gateway's own machine, so a capability whose credential is limited to local execution (its allowed_execution_locations in GET /v1/secrets names local_only alone) refuses it; a local MCP client that needs one connects to http://127.0.0.1:7376/mcp with a one-time setup code, or with a session opened on that machine through POST /v1/sessions, instead.

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 (scaling to zero when idle, or always-on on Enterprise), with envelope encryption under a per-tenant vault key held in Secret Manager, and Cloud KMS wrapping the audit key and any secret you enroll 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 tunneled gateway.

Availability

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 tunneled gateway in the meantime; you can move later.

Hosted gateways carry rate limits and a monthly fair-use ceiling that slow a very busy gateway down; nothing is ever billed per call.

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 tunneled 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 enrolls the device itself after asking you to confirm it's you with a passkey, an approval on your phone or your password. The first device is trusted on that basis alone, and only the gateway's owner, or an owner or admin of its organization, can pair it; every device after it, a member's included, is confirmed by a device you already paired, and from gateway 1.3.46 not by the asking person's own device while someone else's is on the keyring, unless the asking person is the gateway's owner. The account owner is emailed either way, which tells you an enrollment happened but does not prevent one.

That protects you from a stolen session (though a stolen session together with your password can confirm it's you) and from the console, not from permaura.com itself. On a hosted gateway, permaura.com issues the single-use tickets that pair and remove approval devices, and it is permaura.com, not the gateway, that checks who asked for each one and states their role in it. The gateway enforces what it can: the first device, and a removal that would leave none, need the ticket of the gateway's owner or of an owner or admin of its organization; every later device waits for a paired device to confirm it; and once a device is paired, every Device-signed action waits for its signature, as does every control-plane change that isn't strictly tightening unless an owner or admin has lowered the approval floor, a change that itself waits for a paired device and is undone if it was made while no device was trusted and a first device then pairs. But whoever could mint permaura.com's tickets could remove every paired device and then pair one of their own as the first, so on hosted, permaura.com is inside the trust boundary for your approval devices as well as for your secrets.

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 tunneled 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 with environment variables on a gateway you run yourself. Any plan can use it; a hosted gateway has no way to set those variables yet
• 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 that Permaura runs: a managed tunnel address for your gateway and hosted execution, because that's Permaura's infrastructure to run. A tunnel or domain you run yourself works on Free.

See Plans & billing for exactly what each tier includes and current prices.