Skip to main content
Short version: your API calls go directly to providers (OpenAI, Stripe, Resend…). Elding is never in the request path. We store and serve the secret values, like any secret manager, but your traffic never passes through us.

​
The common misconception

Elding is not a hosted MITM proxy. A lot of secret tooling routes your production traffic through a vendor gateway. Elding does not. This is the core of our design.

​
In development

Your app ──────────────► Provider (OpenAI, Stripe…)
   │        direct call
   └─► Local proxy (127.0.0.1) injects the key, then forwards directly
The proxy runs locally on your machine (bound to 127.0.0.1). It injects the real key and forwards the request directly to the provider. Elding’s servers only ever see metadata (the names of the keys referenced), never the request body, query, or response.

​
In production

1. SDK fetches the secret once  ──►  Elding (returns the value)
2. Your app calls the provider  ──►  Provider   (direct, Elding not involved)
There is no proxy in production. The SDK fetches the secret value once at runtime, then your application calls the provider directly. Elding is never in the request path.

​
The honest trust model

Like Doppler, Infisical, Vault, or AWS Secrets Manager, Elding stores and serves your secret values. To serve them, our servers can decrypt them (envelope encryption, AES‑256‑GCM, KEK in KMS). This is the standard, accepted model for secret management.
We say ✅We never claim ❌
Your API requests never transit our servers”We never see your secrets”
Local proxy, direct calls”Zero-knowledge”
We store and serve your secrets, never your traffic”We never touch your keys”
We are transparent about this on purpose: the value Elding adds is keeping keys out of your code and out of your request path, not pretending we never hold them.