Passer au contenu principal
En bref : vos appels API partent directement vers les providers (OpenAI, Stripe, Resend…). Elding n’est jamais sur le chemin de la requête. Nous stockons et servons les valeurs des secrets, comme tout coffre, mais votre trafic ne passe jamais par nous.

​
L’idée reçue

Elding n’est pas un proxy MITM hébergé. Beaucoup d’outils de secrets font transiter votre trafic de production par une passerelle tierce. Elding ne le fait pas. C’est le cœur de notre conception.

​
En développement

Votre app ──────────────► Provider (OpenAI, Stripe…)
   │         appel direct
   └─► Proxy local (127.0.0.1) injecte la clé, puis forward en direct
Le proxy tourne en local sur votre machine (lié à 127.0.0.1). Il injecte la vraie clé et transmet la requête directement au provider. Les serveurs d’Elding ne voient que des métadonnées (les noms des clés référencées), jamais le corps, la query ou la réponse.

​
En production

1. Le SDK récupère le secret une fois  ──►  Elding (renvoie la valeur)
2. Votre app appelle le provider       ──►  Provider (direct, Elding hors jeu)
Aucun proxy en production. Le SDK récupère la valeur du secret une fois au runtime, puis votre application appelle le provider directement. Elding n’est jamais sur le chemin de la requête.

​
Le modèle de confiance, honnêtement

Comme Doppler, Infisical, Vault ou AWS Secrets Manager, Elding stocke et sert vos valeurs de secrets. Pour les servir, nos serveurs peuvent les déchiffrer (envelope encryption, AES‑256‑GCM, KEK dans KMS). C’est le modèle standard et accepté de la gestion de secrets.
Ce qu’on dit ✅Ce qu’on ne prétend jamais ❌
Vos requêtes API ne transitent pas par nous« On ne voit jamais vos secrets »
Proxy local, appels directs« Zero-knowledge »
On stocke et sert vos secrets, jamais le trafic« On ne touche jamais vos clés »
Nous sommes transparents à dessein : la valeur d’Elding, c’est de garder les clés hors de votre code et hors du chemin de vos requêtes, pas de prétendre qu’on ne les détient jamais.