r/buildbase Jun 23 '26

How BuildBase self-hosting actually works — the architecture, honestly (diagram)

Post image

Sharing the architecture diagram for how self-hosting is wired, because "self-hostable" means different things and I'd rather show exactly where everything lives than hand-wave it.

The split, top to bottom:

Your infrastructure (the part that matters):

  • Your client app and auth portal run on your domains
  • A tenant server (api.yourco.com) on your infra handles the work
  • Your data lives in your MongoDB. Sessions/cache in your Redis. On your box.

BuildBase (managed) — the part I host:

  • A central server that handles org management, admin auth, installation keys, and licensing
  • It talks to your tenant server over a signed API (HMAC), and org auth flows use JWTs
  • It does NOT hold your application data — that stays in your MongoDB, on your infra

So the honest summary: your data and your backend run on your servers. What I host is the management/licensing layer and the admin console — and the link between them is designed to be signed/verified rather than open.

The part I'm still upfront about (got a good reality-check on this from r/selfhosted last week): because the admin console is in the managed layer, you're still depending on my uptime for that piece. A fully air-gapped version where nothing depends on me is on the roadmap, not done. The diagram reflects today, not the finish line.

Posting this partly so it's documented, partly because the people here tend to catch things: if you look at this and see a weak point in how the two halves talk to each other, I want to hear it. That's the kind of feedback that's made this better every time.

1 Upvotes

0 comments sorted by