Can I use BrightSite as the frontend for a Supabase app?

Yes. BrightSite serves your pages and hosting, and the supabase-js client library talks to Supabase directly from the browser for auth and data. Customers run gated client portals and internal tools this way today, with the marketing site and the app on one platform.

Is it safe to put my Supabase key in a BrightSite page?

The Supabase publishable (anon) key is designed to be public, the same way it is in any React or Next.js frontend. Security comes from Supabase Row Level Security policies, which decide what each signed-in user can read and write. Enable RLS on every table before you launch.

Does BrightSite store my users and passwords?

No. Credentials go straight from the visitor's browser to Supabase Auth over HTTPS and never pass through BrightSite's servers. BrightSite stores your pages, media, and form submissions; Supabase stores accounts and application data.

Do I need a server or any backend code?

No. Supabase provides the hosted backend (Postgres, auth, storage, and edge functions if you need them), and BrightSite provides hosting, CDN, custom domains, and the page editor. Everything you write is HTML, CSS, and client-side JavaScript.

When should I use Lovable or Bolt.new instead?

Use an AI app builder when the application is the whole product: complex multi-view state, server-side logic, or a large custom React codebase. Use BrightSite plus Supabase when you mostly need a real website (SEO pages, blog, forms, fast hosting) with an app section attached, like a client portal or booking status page.

Will a login page hurt my site's SEO?

No. Your public pages stay fully crawlable and fast, and the gated pages simply hold no private content in their HTML. Private data loads from Supabase after sign-in, so crawlers see a sign-in screen and nothing sensitive.

BrightSite + Supabase: Build a Web App on a Website Builder

How the architecture works

BrightSite serves your pages: fast hosting (30 to 80ms page loads), a custom domain, the visual editor, forms, and SEO for everything public. Supabase provides the backend: a hosted Postgres database, user authentication, and file storage. The two connect with supabase-js, Supabase's official JavaScript client, running in the visitor's browser.

There is no server to deploy and no build pipeline. Sign-in credentials travel directly from the browser to Supabase over HTTPS and never touch BrightSite's servers. Application data loads after sign-in, governed by Supabase's Row Level Security rules.

Division of labor: BrightSite owns pages, hosting, domain, forms, media, blog, and analytics. Supabase owns accounts, sessions, database tables, and access rules.

What you can build

A working portal is a login page, a session-gated app page, and Row Level Security policies deciding who sees which rows. Everything public stays a normal BrightSite page, so the marketing site and the app share one domain, one editor, and one bill.

Client portals

Each customer signs in and sees only their own projects, files, or invoices.

Internal dashboards

Team-only views of live data, without standing up an app server.

Booking and status pages

Let people check and change their own bookings after signing in.

Member areas

Gated content sitting alongside your public, indexable pages.

Setup guide

Ready to build one?

The docs walk through it end to end: creating the Supabase project, loading the client library, wiring sign-in, gating the portal page, and the Row Level Security checklist to clear before you invite anyone in. Sample code included.

Read the Supabase guide

Prefer to hand it off? Connect the BrightSite MCP server and ask Claude or ChatGPT to build the portal for you. The open-source brightsite-skills repo includes a supabase-portal skill for exactly that.

Security: what to get right

The publishable key is public by design. Anyone can see it in your page source, exactly as they can on a React site. It grants nothing by itself.
RLS is your only real gate. The client-side redirect keeps honest people out of the portal page, but the HTML of a BrightSite page is public. Never put private data in the page itself; fetch it from Supabase after sign-in, where RLS decides who sees what.
Use HTTPS-only, which BrightSite enforces by default. Credentials go browser to Supabase, encrypted end to end.
Keep the service-role key out of the frontend entirely. That key bypasses RLS and belongs only in Supabase Edge Functions or other server-side code.

When this pattern fits, and when it doesn't

A good fit: client portals, member areas, internal dashboards, booking and status pages, waitlist tools, and any product where the public website matters as much as the app. You get real SEO pages, a blog, native forms, and fast hosting alongside the gated section, and you can manage the whole thing from the visual editor or from Claude and ChatGPT via MCP.

Not the right tool: apps with heavy server-side logic, secrets that cannot live in the browser, or a large custom React codebase. For those, an AI app builder such as Lovable or Bolt.new, or a hand-built stack on Vercel, is the better call. Supabase Edge Functions can cover moderate server-side needs (webhooks, payment calls) while keeping the frontend on BrightSite.

Comparing options? See our roundups of Lovable alternatives and Bolt.new alternatives.

Want the longer version? We wrote up whether you can build a web app on a website builder, covering where the pattern works and where it breaks down.

Building something like this?

Start a free trial, or email us and we'll help you sketch the architecture.

Start free trial

support@onbrightsite.com

Use BrightSite as the frontend for Supabase