Hide an API key: move it to a Supabase Edge Function

Every guide about a leaked API key ends in the same place: move it to a server. Then it stops. You are left holding an app you built in Lovable, Bolt or Cursor, no server anywhere in sight, and a sentence that assumes you already know what to do next.

Here is the part guide after guide leaves out. Moving the key into a Supabase Edge Function takes it out of your page, and by itself it does not stop a stranger using it. Supabase's own documentation says why: the check a deployed function runs by default also accepts your publishable key, and your publishable key is in your frontend for anyone to copy. Hiding the key is the straightforward half. The half nobody writes about is deciding who your new function answers to.

Think of the key as the master key to a stockroom. Right now it is taped to the inside of the shop window, where anyone who stops to look can read it. An Edge Function is a back room with a hatch: the key goes in there, and visitors ask through the hatch instead of walking in and helping themselves. Whether that is an improvement depends on who the hatch opens for.

Where should I put my API key instead of the frontend?

Anywhere that is not the browser. An Edge Function is the smallest version of that you can get.

A browser cannot keep a secret. Everything your page needs in order to run gets downloaded by every visitor, and a visitor can read all of it: the code, the images, the values compiled into the code. That is not a fault in your builder. It is what a web page is. Which API keys are safe in your frontend is the long version; the short one is that an sk_ key, an OpenAI key or a Supabase secret key was never going to survive being shipped to a browser.

A Supabase Edge Function is a small piece of code that runs on Supabase's machines. It can read secrets you set on your project, it answers at a web address of its own, and your app calls it by name. You write one file and Supabase runs it, so there is no server for you to rent, patch or keep awake.

Rotate the key you already published, before you move anything

The key sitting in your frontend today is already public, and it stays public after you take it out of the code.

Every visitor who loaded your site downloaded it. So did every crawler, and there are automated ones walking the whole web looking for exactly these strings. Your old bundle is also still in your version history and in whatever caches have a copy of your page. Removing a line from a file you control does nothing about a value that has already been handed out.

So the order is: create a new key at the provider, hold on to it for a moment, and revoke the old one once the function below is live. Then read your billing page and your usage logs for the whole period the old key was out there. Rotating stops what happens next; it has no effect on what already happened. If the key was a Supabase secret key, the order to work in has a wrinkle worth reading first.

The four steps

Store the secret, write the function, deploy it, then change your app to call the function instead of the vendor.

Inside the function the secret arrives as an environment variable, which is a named value the code can read and nobody outside can. Supabase's docs for Edge Function secrets have the full reference, and three details in it save a confusing hour:

• A secret name cannot start with SUPABASE_. That prefix is reserved for the values Supabase sets for you, and both the dashboard and the API refuse it.
• A new secret is readable immediately. You do not redeploy the function after changing one.
• Local and production are separate. The local stack reads supabase/functions/.env, which is a different place from the secrets on your live project, so set the value in both or the function works on your machine and fails once deployed.

Then delete the old variable from your frontend. If it was named VITE_, NEXT_PUBLIC_ or EXPO_PUBLIC_, that prefix was an instruction to compile the value into the bundle, and the prefix is the whole story of how it got there.

Does a token requirement mean only my users can call it?

No, and this is the one thing in this article worth reading twice.

Supabase turns a check called verify_jwt on by default. It inspects the Authorization header before your code runs and refuses the request if nothing valid is there. That sounds like a door only your users can open. It is not, because Supabase also documents that the same check accepts a publishable or secret key on either header, for compatibility with older projects, and adds plainly that the check alone does not authenticate a caller who sends only an API key.

Your publishable key is in your frontend. That is correct and it is meant to be there. It also means anyone who opens your site, reads the key and sends it to your new function gets past the platform check and into your code.

In the stockroom, verify_jwt is a doorman who checks that you are holding a visitor pass. Every visitor has one, because you hand them out at the door. The receptionist at the hatch is a different job, and it is the one that asks which visitor you are.

Locking the function down, so you have not built an open proxy

Decide which callers your function accepts, and write that decision into the function.

Supabase ships a wrapper for this, so it is a line rather than a project. Set auth: 'user' and the function accepts a signed-in user's token and hands your code a database client already scoped to that user's Row Level Security rules:

import { withSupabase } from 'npm:@supabase/server@1'

export default {
  fetch: withSupabase({ auth: 'user' }, async (_req, ctx) => {
    // ctx.userClaims is who is calling. Reject anything you do not want here,
    // then call the vendor with the secret from the environment.
    return Response.json({ ok: true })
  }),
}

The Securing Edge Functions page lists the other modes, and two of them matter for ordinary apps. A function called by another machine rather than by a browser uses auth: 'secret', with the secret key sent on the apikey header. A function that receives webhooks from Stripe or GitHub cannot use either, because those providers have no token of yours; it sets verify_jwt = false and checks the provider's signature inside the handler instead.

Whichever you pick, decide deliberately what happens when a caller you did not expect arrives. Supabase's example of a function that may accept every caller is a health check, and a health check costs nothing when a stranger calls it. A function that forwards a paid API call bills you for each one.

Can I use service_role in an Edge Function?

Yes. A function is the one place a Supabase secret key belongs.

You do not paste it in, either. Supabase puts the project's keys into the function's environment for you, so the code reads them from there rather than from a secret you set. Newer projects get SUPABASE_SECRET_KEYS and SUPABASE_PUBLISHABLE_KEYS, each a small dictionary of named keys; older projects get SUPABASE_SERVICE_ROLE_KEY and SUPABASE_ANON_KEY under their original names. What changed when Supabase renamed its keys covers which pair you have.

Use the secret key for work that genuinely has to see every row, such as writing an audit record the user must not be able to edit. For anything a user is reading about themselves, use their own token and let your Row Level Security rules do the filtering, which is what they are for.

Verifying it from the browser, which is the only proof

Load your live site, open the network tab, and look at what your browser actually sends.

The two things to check:

• No request carries the key. Click through the part of your app that used to call the vendor. The outgoing request should go to …supabase.co/functions/v1/your-function, and the only credential anywhere in it should be your publishable key or your user's own token.
• The key is not in the downloaded code. Use your browser's search across all loaded files and paste in the first dozen characters of the old key. No result is the answer you want.

A rebuild and a redeploy is what removes a value from the bundle, so a key that still turns up in the search usually means the frontend went out before the variable came out of it.

Our free scan does the second check from outside and names what it can read in your live bundle, including which Supabase key you shipped. It takes about 20 seconds and needs no account: scan your app.

Doing this from inside Lovable, Bolt or Replit

Use the Supabase dashboard. There is no terminal step in it anywhere.

Open your project, choose Edge Functions in the sidebar, then Deploy a new function → Via Editor. Supabase's dashboard quickstart has the walkthrough with screenshots, and the templates it offers include one for proxying an AI provider, which is the exact shape of this job. Deployment takes somewhere between ten and thirty seconds, and the function is then live at an address of its own. Your secret goes on the Edge Function Secrets page in the same section.

One caveat that is worth knowing before you rely on it: Supabase says the dashboard editor has no version control, no versioning and no rollbacks, and recommends it for quick work rather than for code you intend to keep. Pressing Deploy overwrites what was there. If the function ends up doing something you care about, download it from that page and keep the file somewhere.

There is also a Replit-shaped version of this question, because Replit has its own secrets store and your app runs its own server there. What Replit Secrets actually do is that version.

When an Edge Function is the wrong answer

Two cases, and in both of them moving the key costs you work and buys nothing.

The key was publishable. A Stripe pk_live_ key, a Supabase publishable or anon key, a Mapbox public token: these are designed to sit in a browser, and the protection is somewhere else. Putting one behind a function adds a hop and removes no risk. Which keys those are is the list.

The key can be restricted to your own site. Google's browser keys are the common example: you can limit one to your domains in the Google console, which is the fix Google supports for exactly this situation. The key is still readable and it stops being useful to anyone who copies it.

Everything else belongs on a server. There is no publishable variant of an OpenAI or Anthropic key, which is why a model provider key in your frontend has no setting that saves it, and no amount of minifying hides a Stripe secret key from somebody reading your page.

What to do right now

If you would rather work through your whole app rather than one key, the 10-minute security checklist covers this alongside the other things worth closing in a newly launched app.