Supabase Edge Function

A Supabase app talks to its database straight from the browser, with row-level security deciding what each user can see. Some work can't happen there: anything that needs a secret key, has to trust its own logic, or is called by another service rather than a user. Edge Functions are where that code lives. Supabase lists typical uses as receiving webhooks from services like Stripe or GitHub, serving low-latency HTTP endpoints, generating images on demand, coordinating calls to AI models, sending transactional email, and running chat bots.

Each function is a TypeScript entry file, by convention at supabase/functions/<name>/index.ts. Supabase bundles and deploys it to its Edge Runtime, which is Deno-compatible and TypeScript-first, and serves it from locations close to your users. Secrets such as API keys are set on the project and read as environment variables at run time, so they never appear in the code.

A function handles a request and finishes. There is no long-running server to keep alive, which suits short jobs like answering a webhook or proxying one API call, and makes long, heavy work a poor fit. You can run functions on your own machine with the Supabase CLI (supabase functions serve) before you deploy them.

By default, Supabase checks every request to a function before your code runs. With verify_jwt on, a request without a valid Supabase JWT in its Authorization header gets a 401 and your function never executes. That's the right setting for functions your signed-in users call. A webhook from an outside provider can't send a Supabase JWT, so that function is set to verify_jwt = false in supabase/config.toml, and it must verify the caller another way, usually by checking the provider's signature on the payload.

The Vibely agent writes Edge Functions into supabase/functions/ when your app needs server-side code. Examples include a Stripe webhook and, on mobile apps, the function that calls Vibely AI so the key never reaches the phone. Vibely deploys them to your linked Supabase project after the turn that wrote them. It keeps JWT verification on unless the project declares a function public in that function's config.json or in supabase/config.toml. Connector secrets are stored as Edge Function secrets, not in files. If a deploy fails, Vibely records what broke on the project, redeploys every function on each build turn until a deploy comes back clean, and tells the agent what's still broken so it doesn't claim a success that didn't happen.