Bring your own key is easy to summarize and easy to describe inaccurately. In Storyloom, a provider credential is stored in your browser, sent to your Storyloom deployment when you generate, and then used by that deployment to call the provider you selected.
The key does leave the browser. That detail matters.
Where a key lives
Keys added through Extensions are stored in browser localStorage under Storyloom's connector store. Storyloom does not place them in an application database. The project does not require a database for boards or credentials.
Browser storage is a trade-off, not a vault. Any script executing on the same origin can potentially read local storage. Self-host code you trust, keep dependencies current, and serve the app over HTTPS.
How a generation request moves
When the studio runs a generation, the browser attaches the connected keys to a request header sent to the Next.js API route on your Storyloom deployment. The server resolves the selected key and calls the external provider. The browser does not call fal.ai, ElevenLabs, or HeyGen directly.
That proxy makes server-side validation, retries, cost estimates, and model normalization possible. It also means your deployment is inside the credential path. If you require a provider key to never reach an application server, Storyloom's current architecture is not that design.
Per-user and deployment keys
Storyloom supports two practical modes:
- A creator connects a key in their browser. It travels per request and overrides a deployment-level key.
- A self-hoster configures provider keys in the deployment environment. Visitors then use that provider account unless they supply their own key.
The second mode can create shared spend on a public deployment. It is best suited to a private instance or an environment with its own access controls. Storyloom does not add authentication or billing around that configuration.
With no key, the app uses a deterministic mock provider. That lets someone explore the complete interaction loop without silently incurring provider charges or crossing a sign-up wall.
What the repository protects
Environment files with real values are ignored. Provider variables are optional. Credential-bearing headers, cookies, and query strings are scrubbed from Sentry events before they are sent. Request logging is designed not to include key material.
These safeguards reduce accidental exposure; they do not change the trust boundary. Your deployment and the selected model provider handle the key during a real generation.
Read the repository's security policy for the current model and responsible disclosure path, or inspect the open-source architecture before connecting a provider.