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.
- 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.
- 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.
- 03
Data loads after sign-in
The portal asks Supabase for rows, and Row Level Security decides which ones this person can see.
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.
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.
What to get right.
- 01The 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.
- 02Row 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.
- 03Serve everything over HTTPS.Every BrightSite domain gets SSL, so credentials go from the browser to Supabase encrypted.
- 04Keep the service-role key out of the frontend.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.
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.
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.