How does Draftbit handle API keys, secrets, and environment variables?

Build Config in the Builder holds each app’s environment variables. A variable has a name, a value, a visibility, and the environments it applies to, which can be any mix of development, staging, and production. One name can therefore point at a test backend while you build and at the live one when you publish.

Visibility decides where a value can go. Plain text variables are injected into the app and visible to anyone who inspects the compiled code, so use them only for public configuration such as an API base URL or a Supabase publishable key. Expo apps require the EXPO_PUBLIC_ prefix on plain text names, and web apps and websites built with Vite or Astro use those frameworks’ public prefixes. Sensitive variables stay out of runtime app code and compiled bundles. They are available to build and configuration files and to the agent’s sandbox, and the Builder masks them after you save.

On Draftbit’s side, stored variable values are encrypted with field-level encryption, as are OAuth tokens, MCP credentials, Supabase keys, and other stored secrets, and traffic is protected with TLS. Draftbit’s documentation describes the encryption of stored keys as AES-256. The agent’s sandbox receives the development values so it can run tooling that depends on them, and the agent can add or update variables when you ask. If a REST connector header reads a sensitive variable, Draftbit refuses to generate frontend client code for it instead of shipping the value.

A database administrator key, payment secret, or AI provider key still needs a trusted server. Call it from a Supabase edge function or your own backend and return only the data the user should see. If a key was ever committed or shipped in a build, rotate it. Removing it from the current file does not remove it from history or from installed builds.