Lovable + Powabase

Example apps

Real apps, each from one prompt. Copy any of them and give it to Lovable.

Where Lovable keeps your keys

Lovable keeps backend keys in Secrets (More → Cloud → Secrets). They're encrypted, write-only, and injected into your server-side code at runtime: an Edge Function in older React + Vite apps, a server function in newer TanStack Start apps. BASE_URL and the Service Role key go there. Anything prefixed VITE_ lives in the project's .env instead, which Lovable commits to the repo and bundles into the browser, so the Anon key is the only Powabase key that can go there.

Lovable example

// The browser calls this function; only the function talks to Powabase.
const cors = {
  "Access-Control-Allow-Origin": "*",
  "Access-Control-Allow-Headers": "authorization, x-client-info, apikey, content-type",
};

Deno.serve(async (req) => {
  if (req.method === "OPTIONS") return new Response(null, { headers: cors });
  const { query } = await req.json();
  const key = Deno.env.get("API_KEY")!; // Secret: Service Role (Secret) Key
  const url = `${Deno.env.get("BASE_URL")}/api/knowledge-bases/${Deno.env.get("KB_ID")}/search`;
  const res = await fetch(url, {
    method: "POST",
    headers: { apikey: key, Authorization: `Bearer ${key}`, "Content-Type": "application/json" },
    body: JSON.stringify({ query, top_k: 5, retrieval_method: "hybrid" }),
  });
  const headers = { ...cors, "Content-Type": "application/json" };
  return new Response(await res.text(), { status: res.status, headers });
});

KB_ID is a third Secret holding your knowledge base's ID. Newer TanStack Start apps get a server function instead of an Edge Function; the fetch inside is the same. Before this goes live, have it check the signed-in user so strangers can't run searches on your key.

Connecting to Powabase from any tool

Mechanics that don’t change from tool to tool.

• Every call to /api/* or /rest/v1/* needs two headers, apikey and Authorization: Bearer, both set to the same key. Sending only one is the most common cause of a 401.

  Docs↗

• The Database URL from the Connect modal is PgBouncer in transaction mode, not a direct Postgres connection. Disable prepared statements in your driver, or you'll hit prepared statement "..." does not exist. No LISTEN/NOTIFY and no session-level SET across statements. Use Realtime for change notifications; SET LOCAL inside a transaction otherwise. The username and database in the URL are both your project ref, not postgres.

  Docs↗

• @supabase/supabase-js mostly works for the BaaS surface (PostgREST, Auth, Storage, Realtime) when you point it at your project URL with the Anon key. It doesn't cover the /api/* AI surface (agents, knowledge bases, orchestrations), which you call over plain REST. There's no /graphql/v1 route: point any GraphQL client at POST /rest/v1/rpc/graphql instead.

  Docs↗

Common errors

Lovable won't save a secret named SUPABASE_URL or SUPABASE_SERVICE_ROLE_KEY

Cause: The SUPABASE_ and LOVABLE_ prefixes are reserved for Lovable's own backend.

Fix: Name them BASE_URL and API_KEY, as in the quick start, and read those names in your server code.

The Service Role key turns up in your repo and in the browser bundle

Cause: It was saved as a VITE_ variable in .env. Lovable refuses VITE_ names in Secrets, commits .env to the repo, and bundles VITE_ values into client code.

Fix: Remove it from .env, add it to Secrets under a name without the VITE_ prefix, and read it only in server-side code. If it shipped, rotate it in Studio.

Calls to Powabase fail in a remixed project

Cause: Secrets you add by hand aren't copied when a project is remixed.

Fix: Add BASE_URL and API_KEY again under More → Cloud → Secrets in the remix.

401 Unauthorized

Cause: Only one of the apikey / Authorization headers was sent.

Fix: Send both, set to the same key. Docs↗

prepared statement "..." does not exist

Cause: PgBouncer's transaction-mode pooler moved you to a different server connection.

Fix: Disable prepared statements in your driver's config. Docs↗

A query that should return rows comes back empty, or a write is silently rejected

Cause: Row Level Security on your own tables. New public tables ship with RLS off, but once you add policies they gate every request.

Fix: Check the policy's USING/WITH CHECK clause and confirm which role (anon, authenticated, service_role) you actually authenticated as. Docs↗

FAQ