Platform Architecture Overview

This overview walks through the technical foundation behind BrightStar — the systems running quietly every time someone lands on your event page, buys a ticket, or scans in at the door of a kirtan circle, a retreat, or a festival gate. You don't need to understand serverless computing or database replication to run a good gathering, but knowing what's underneath can help you trust why things behave the way they do, especially in the moments that matter most: the instant registration opens, or the line moving through check-in before your first session begins.

BrightStar is built in layers, each doing one job. The frontend — the pages your attendees actually see — is server-rendered so search engines can index your event properly and pages load fast even on a slow phone connection at a festival gate; the busiest static pages are cached at the edge, close to wherever someone is browsing from. It also works as a progressive web app, so a returning attendee can revisit your event page like a lightweight app rather than hunting through old bookmarks or emails. Behind that sits an API layer of server routes that return data as JSON, with rate limiting on the public endpoints so a flood of automated requests can't overwhelm the system during a popular on-sale. The database layer is PostgreSQL, with read replicas so heavy reporting or dashboard traffic doesn't slow down checkout itself, real-time subscriptions through Supabase for live updates, and automatic daily backups kept for 30 days. Payments run through Stripe Connect — card numbers go to Stripe directly and are never stored on BrightStar's own servers, with webhooks confirming each payment as it clears.

BrightStar runs on serverless functions hosted across Vercel's global edge network rather than on a fixed set of servers. That distinction matters most in the exact moment you'd expect trouble: when registration opens for a popular retreat and hundreds of people hit the same page within seconds. Because the functions serving your event page and checkout scale with whatever traffic actually arrives, a slow trickle of sign-ups over a week and a sudden rush the moment tickets go live are handled by the same system, just doing more or less work. Underneath that, ticket inventory is reserved atomically at the moment of purchase, which is what stops an on-sale rush from overselling more tickets than you actually have. Nobody has to guess your expected attendance in advance and provision for it.

Two different concerns sit under the umbrella of security, and BrightStar treats them separately. Card data itself never touches BrightStar's servers — Stripe handles the number, the expiry, the CVC, and BrightStar only ever sees the result of the charge. Stripe itself is certified to PCI DSS Level 1, the top tier of that compliance standard, which is one more reason organizers don't need to think about card security themselves. Everything else — your event details, attendee information, account credentials — is encrypted both while it's moving between systems and while it's sitting in the database. Access to that database is further restricted with row-level security, so a request can only see the rows it's actually permitted to, and the elevated service-role credentials that could bypass those restrictions are kept confined to server-side code, never shipped to a browser where they could be exposed.

When you're standing at a retreat check-in table or a festival gate, you need the numbers on your screen to match what's actually happening. BrightStar's dashboard doesn't work by refreshing on a timer — it uses live connections, so sales, check-ins and capacity changes appear as they happen. That means if you have several staff watching the same event from different phones or laptops — one at registration, one at the gate — they're all looking at the same number at the same moment, without anyone needing to hit refresh to catch up.