Integration vs key custody
Restormel Keys is BYOK-first: most teams keep provider material in their gateway or secret store. You may also use Connections to store a hosted API key encrypted at rest (when the deployment is configured) or a non-secret vault reference only. This page clarifies what Restormel stores vs what stays with you.
What Restormel stores
- Gateway keys (
rk_…) as prefix + hash only — not reversible - Routes and policies that describe how requests should be handled
- Optional hosted provider keys under Connections — ciphertext only in Postgres when encryption is enabled; list/API/UI show masked labels; never echo full secrets after save
- Health and analytics configuration for the control layer
- Embeddable UX for model selection and BYOK-aligned flows
Where provider credentials usually live
- Gateway-backed: in OpenRouter / Vercel AI Gateway / Portkey (or your gateway vendor), with your app holding the gateway key in env/secrets manager
- Builder-managed direct: in your env vars / secret manager; use a credential reference string in Connections if Restormel should not hold ciphertext
- Hosted in Restormel (optional): one-time paste under Connections for encrypted storage — common for Restormel Testing resolve without duplicating secrets in CI; see Keys + Testing onboarding
Practical guidance — Prefer gateway or your vault when you want zero provider material in Restormel’s database. Use hosted encrypted keys when you accept Restormel custody for that secret class and need a smooth Testing/judge path. Operators must set
RESTORMEL_CREDENTIALS_ENCRYPTION_KEY for hosted key storage to work.