Your website,with an app inside.

BrightSite can host a real web app, with user accounts, a sign-in flow, and a database, by pairing its pages with a Supabase backend. Your marketing site, blog, and gated app all live on one platform, and Supabase handles auth and data.

  1. 01

    The page comes from BrightSite

    Your login and portal pages are normal BrightSite pages, edited in the visual editor and served on your domain.

  2. 02

    Sign-in goes straight to Supabase

    supabase-js runs in the visitor's browser. The password travels to Supabase over HTTPS and never touches BrightSite's servers.

  3. 03

    Data loads after sign-in

    The portal asks Supabase for rows, and Row Level Security decides which ones this person can see.

What you can build

A login page, a gated page, and a few rules.

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.

Your projects
Client portalsEach customer signs in and sees only their own projects, files, or invoices.
This week
Internal dashboardsTeam-only views of live data, without standing up an app server.
Your bookingPendingConfirmed
Booking and status pagesLet people check and change their own bookings after signing in.
Members only
Member areasGated content sitting alongside your public, indexable pages.
BrightSite ownspages, hosting, domain, forms, media, blog, and analytics.
Supabase ownsaccounts, sessions, database tables, and access rules.
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.

  1. 01
    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.
  2. 02
    Row Level Security 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.
  3. 03
    Serve everything over HTTPS.Every BrightSite domain gets SSL, so credentials go from the browser to Supabase encrypted.
  4. 04
    Keep the service-role key out of the frontend.That key bypasses RLS and belongs only in Supabase Edge Functions or other server-side code.
Fit

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 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 or a hand-built stack 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, or read whether you can build a web app on a website builder.

Building something
like this?

Or email support@onbrightsite.com and we'll help you sketch it.Start free trial →