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. 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:
To manage secrets yourself, go to Cloud tab → Secrets.

​
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.
  • Remove deletes 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.
Some secrets carry a badge:
  • Lovable: managed by Lovable and required for the platform to work. These cannot be deleted.
  • Manage: added by a connector. The value is managed by the connection, and you delete it by removing the connection, not from the Secrets view.
  • Not in use: another secret with the same name takes precedence at runtime.
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.

​
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 GitHub 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 Lovable Cloud 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 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 Lovable Cloud, 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.