Skip to main content
The proxy is designed exclusively for HTTP API keys such as OpenAI, Stripe, Resend, and Anthropic: keys sent through an Authorization or x-api-key header to an HTTPS API. Non-HTTP variables (DATABASE_URL, JWT_SECRET, REDIS_URL, and similar values) remain in your host’s environment variables. Elding does not store or inject them.

​
How it works

In proxy mode, your application uses a {{KEY_NAME}} placeholder for an HTTP API key. The local proxy intercepts each outgoing request, replaces the placeholder with the real value, and forwards the request upstream.
The real key lives inside the separate proxy process and never enters your application’s memory.

​
Request processing

1

Authentication

The proxy verifies x-elding-token using a constant-time comparison. Only the child process started by elding proxy receives this token.
2

Anti-SSRF

The target hostname is resolved. Private, loopback, link-local, and cloud metadata IP addresses such as 169.254.169.254 are blocked. DNS pinning prevents rebinding attacks.
3

Host locking

For every placeholder used, the proxy verifies that the key’s authorized domain matches the target. A mismatch returns HTTP 403 and prevents exfiltration.
4

Injection and forwarding

Placeholders are replaced in request headers, then the HTTPS request is streamed to the upstream service.

​
Proxy security

  • Binds to 127.0.0.1 only and is never exposed to the network.
  • Uses a random session token with constant-time comparison.
  • Allows HTTPS only and strips hop-by-hop headers.
  • Logs placeholder names only, never API key values.
A compromised dependency or AI agent inside your application only sees {{OPENAI_API_KEY}}, never the real key.