Skip to main content
Secrets store sensitive values such as API keys, tokens, and credentials without exposing them in code. They are encrypted, injected into your Edge Functions automatically, and never reach the browser. Each secret belongs to one project and is read while your app runs. Workspace-wide values your projects need while they build, such as npm tokens for private packages, are build secrets, available on Enterprise plans. You usually don’t add secrets by hand. When a feature needs one, Lovable prompts you to enter it through a secure input in chat. For example, a prompt like this leads Lovable to ask for the keys it needs:

​
Understanding a secret prompt

When Lovable asks you for a secret, the chat message explains which secret it needs and why. Before entering a value, check:
  • The secret name. For example, STRIPE_SECRET_KEY or OPENAI_API_KEY. The name is usually the exact environment variable your Edge Function will read.
  • The chat message before the prompt. Lovable explains what the current change needs the secret for, such as calling a specific API, authenticating with a provider, or signing webhooks, and where to get the value.
  • The provider’s dashboard. If you’re unsure what the value should be, open the provider’s website (Stripe, OpenAI, Resend, and so on) and look for the API key or credential of the same name. The input field shows an example of what a well-formed value looks like, and warns if what you enter doesn’t match the expected format. The warning never blocks you, so you can still submit a valid key the format check guessed wrong.
If you don’t want to add the secret yet, select Skip and ask Lovable to explain what the secret is used for, or to build the rest of the feature without it. Anything that depends on the secret won’t work until you add it. When you’re ready, ask Lovable in chat and it opens the secure form again. To manage secrets yourself, go to More → Cloud → Secrets in the project toolbar.

​
Manage secrets

The Secrets view lists each secret’s name and creation date. Values are never shown.
  • Add secret opens a dialog where you can enter one or more name and value pairs.
  • Delete, in the secret’s … menu, removes a secret. This cannot be undone; if a feature still needs the value, your app breaks until you add it again.
  • Secrets are write-only: after you save a secret, its value can never be viewed again in Lovable, only replaced or deleted. If you lose a key, generate a new one at the service that issued it. Secrets are not copied when a project is remixed.
When you save a value, Lovable removes spaces and line breaks from its start and end, so a stray character picked up while copying does not end up in the stored secret. Line breaks inside the value are kept, so multi-line values such as private keys stay intact. A value that contains nothing but spaces or line breaks is rejected. If a secret you saved earlier stopped working because of a stray character, save its value again to store it clean. Some secrets carry a badge:
  • Lovable: managed by Lovable and required for the platform to work. These cannot be deleted.
  • Not in use: another secret with the same name takes precedence at runtime.
Secrets added by a connector carry no badge. The connection manages the value, so you remove the connection rather than the secret. Select Manage connection in the secret’s … menu. The LOVABLE_API_KEY secret, used by built-in AI, has a Rotate action. If you suspect the key has been exposed, rotate it: Lovable issues a new key and updates your Edge Function environment automatically. Rotating requires editor access or above.

​
Workspace build secrets

On Enterprise plans, build secrets set for the whole workspace appear in this list too, sorted alphabetically alongside your project secrets. They sit in a dimmed row with your workspace avatar next to the name.
  • Workspace secrets are read-only here. You see the name, never the value. The Created column can be blank for older workspace secrets.
  • The only action is View workspace secrets, which opens Settings → Build & deploy → Build secrets. Add, change, and delete them there, as a workspace admin or owner.
  • Seeing these rows depends on your workspace role, not on your access to this project. You need workspace editor access or above, so external collaborators manage the project’s own secrets without seeing the workspace ones.
  • A project secret can use the same name as a workspace secret. The list then shows only the project row, marked with a warning icon, and your app runs with the project value. While a project builds, the workspace value still applies, because project secrets take no part in builds.

​
Secrets vs. VITE_ environment variables

Lovable’s Secrets manager is for backend values only: values used by Edge Functions and server-side integrations. Anything prefixed with VITE_ is a build-time, browser-exposed value and must live in your project’s .env file instead, not in Secrets.
  • Backend secrets (use Secrets): STRIPE_SECRET_KEY, RESEND_API_KEY, OPENAI_API_KEY, third-party service credentials, and anything that must never reach the browser.
  • Frontend variables (use .env): anything prefixed with VITE_, such as VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY. These are embedded into the client bundle at build time and are safe to be public. You can find and edit them in the .env file in Lovable’s code editor or in your synced Git repository.
Do not add .env to .gitignore in a Lovable project. Lovable needs .env committed to the repository so build-time VITE_* values are available when generating previews and published builds. Gitignoring it will break the preview.
If you try to add a VITE_-prefixed name in Secrets, Lovable rejects it with a message like “VITE_ prefixed variables are build-time browser values and should be defined in .env files, not in secrets.”

​
Reserved secret name prefixes

The following name prefixes are managed automatically by the built-in backend and cannot be created or overwritten in the Secrets UI:
  • SUPABASE_: for example SUPABASE_URL, SUPABASE_ANON_KEY, SUPABASE_SERVICE_ROLE_KEY, SUPABASE_DB_URL. These are populated by Lovable when the built-in backend (Cloud), or a connected Supabase project, is enabled.
  • LOVABLE_: reserved for Lovable-managed values such as the Lovable API key used by built-in AI.
You don’t need to add these yourself. They already exist in your Edge Function environment, and your functions can reference them directly (for example, Deno.env.get("SUPABASE_SERVICE_ROLE_KEY")). If your project uses an external Supabase connection instead of the built-in backend, secrets are managed in Supabase: the backend view shows a Manage secrets button that opens your Supabase project’s dashboard.

​
FAQ

No. Secrets are write-only: you can replace or delete a secret, but never read its value back. If you lose a key, generate a new one at the service that issued it.
Lovable-generated keys are recreated fresh in the remixed project. Manually added secrets are not copied over, so re-enter them in the new project.
Secrets are injected into your project’s Edge Functions and server-side integrations at runtime. They are never included in your frontend code or exposed to the browser.
If the value must stay private (payment keys, AI provider keys, service credentials), use Secrets. If it’s a VITE_-prefixed build-time value that is safe to be public, it belongs in .env.

Related topics

Connect to SupabaseBuild secretsWorkspace security centerWorkspace admin settingsSecurity best practices for Lovable apps