> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lovable.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Secrets

> Store API keys and other sensitive values securely in your app's built-in backend (Cloud), and understand the difference between secrets and VITE_ environment variables.

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:

```text wrap theme={null}
Connect Stripe so clients can pay invoices online. Ask me for any API keys you need.
```

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](/integrations/introduction). 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.

<Warning>
  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.
</Warning>

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

<AccordionGroup>
  <Accordion title="Can I view a secret's value after saving it?">
    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.
  </Accordion>

  <Accordion title="Are secrets copied when I remix a project?">
    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.
  </Accordion>

  <Accordion title="Where do my secrets get used?">
    Secrets are injected into your project's [Edge Functions](/features/edge-functions) and server-side integrations at runtime. They are never included in your frontend code or exposed to the browser.
  </Accordion>

  <Accordion title="Should I put my API key in a secret or in .env?">
    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`.
  </Accordion>
</AccordionGroup>