Most agencies that offer "a platform" to their clients end up in one of two places. Either they resell a hosted SaaS and become a support desk for a product they don't control, or they build a bespoke stack per client and drown in maintenance. Both leak margin. In the first case the vendor owns the customer, sets the price, and takes the cut. In the second, every client is a snowflake that only one developer on your team understands.
There is a third option: run one source-available platform under your own brand, on your own infrastructure, and deliver it to clients as if you built it. That is what this article is about. We'll call the pattern an "Agency OS" and walk through what you actually white-label, how you isolate clients from each other, how you bill under your own name, and — importantly — where the honest limits are.
An Agency OS is not a product you buy. It's a way of operating: you pick one platform, learn it deeply once, and stamp out branded instances for each client instead of re-architecting from scratch every time. The platform becomes the reusable substrate; your work becomes configuration, branding, and the client relationship.
VBWD fits this pattern because it is self-hosted and source-available under BSL 1.1 — free to use commercially until your VBWD-attributable annual sales cross the equivalent of 6.7 BTC, and it converts to Apache-2.0 as its change license. In practice that means an agency can run client platforms without paying a per-seat or per-instance fee to an upstream vendor. You are not licensing a black box; you have the source, the Docker setup, and the plugin system.
The stack underneath is deliberately conventional: Python/Flask and PostgreSQL with Redis on the backend, Vue 3 and TypeScript on the frontend, all containerized. The frontend is split into three repos — a shared component library (vbwd-fe-core), a customer-facing app (fe-user), and an admin backoffice (fe-admin). The backend is an agnostic-core plugin platform: the core knows nothing about tarot, real estate, or pharmacy shops; capabilities arrive as plugins. You can read more about how that separation is enforced on the architecture page.
White-labeling only works if the branding surface is broad enough that a client never sees the upstream name. In VBWD the surface you control covers both apps a client and their staff will touch.
fe-user and fe-admin. The admin backoffice your client's staff log into carries your client's brand, not yours and not "VBWD".var(--color-primary), so a rebrand is a token change, not a hunt-and-replace across component files.A minimal token override for a client's brand looks like this — no forking of component code required:
:root {
--color-primary: #0b5cff;
--color-primary-contrast: #ffffff;
--color-surface: #ffffff;
--color-text: #101828;
}
Because colour lives entirely in tokens, you can keep one shared component library and give every client a distinct look. The structure stays common; only the theme layer differs. That is the difference between white-labeling and forking — you are not maintaining N copies of the UI.
The next question every agency asks is: how do I keep Client A from ever seeing Client B's data? VBWD gives you two levers, and you can combine them.
Separate instances. The simplest and strongest boundary is one deployment per client: its own containers, its own PostgreSQL database, its own domain. Nothing is shared at the data layer, so a mistake in one client's configuration cannot leak into another's. Because the whole stack is Dockerized, spinning up a new instance is a repeatable operation rather than a bespoke build. This is the model most agencies should start with — it trades some hosting overhead for a boundary you never have to reason about.
Role-based access within an instance. Inside any single client platform, you still need to separate the client's own staff, admins, and end users. VBWD ships granular RBAC built from three role systems working together: a base User.role, admin roles that gate access to the /admin backoffice, and user access levels that gate the /user area. That means a client's support agent can be given exactly the admin permissions they need — say, viewing invoices but not editing plans — while their end customers only ever reach the customer app. You configure this per client so their staff see only what they should.
For most agencies the practical answer is: separate instances per client for the hard data boundary, plus RBAC inside each instance to separate the client's team from their customers. The documentation covers the deployment recipes and role seeding that make this repeatable.
Here is where the Agency OS model pays for itself. VBWD includes subscription, invoice, and payment plugins, so the platforms you deliver can charge end customers directly. Critically, there is no platform cut: because you are self-hosting, the money flows through your (or your client's) payment accounts, and you keep 100% of what you bill. Compare that to reselling a hosted SaaS where the vendor skims every transaction.
The billing engine handles the parts that are tedious to build correctly: recurring subscriptions with trial-to-paid transitions, multi-currency, and per-line tax so invoices are calculated correctly across rates rather than with a single blanket percentage. You can see the range of what the subscription and invoicing plugins cover on the plugins catalogue, and the commercial framing on the billing page.
There are two billing relationships to keep straight, and it's worth being explicit with clients about both:
The business case is straightforward: you charge each client a recurring fee to host, brand, operate, and maintain their platform. Because you run the same substrate for everyone, your marginal cost per new client is mostly operational, not development. Your first client pays for you to learn VBWD; every client after that reuses that knowledge.
You also own the relationship and the data. The client's customers live in a database you administer. That is a stronger position than being a reseller who can be cut out the moment the upstream vendor decides to sell direct. It also means you can offer things resellers can't — data exports, custom plugins for a client's vertical, integrations — because you have the source and the plugin system to extend it. If a client needs a capability that doesn't exist yet, it's a plugin in plugins/<name>/, not a support ticket to a vendor who may never build it. The features overview is a good starting point for scoping what's already covered before you build.
The handoff story matters too. When you onboard a client, the deliverable is a running branded platform with their staff trained on the admin app. If the relationship ever ends, because everything is source-available and self-hosted, you can hand over the instance and its data rather than holding it hostage on someone else's cloud. That honesty tends to make the sale easier, not harder.
This model is not free money, and pretending otherwise sets up agencies to fail. The core trade-off is that you operate the infrastructure. For every client instance you are responsible for uptime, backups, security patching, and platform updates. A hosted SaaS reseller offloads all of that to the vendor; you are choosing to take it on in exchange for margin and ownership.
The practical consequences:
Agency OS suits agencies that are willing to run infrastructure — or willing to build the process and hire the one person who will — in exchange for margin and control. If your team has no appetite for operations at all, a hosted reseller model may genuinely fit you better, and that's a fair call to make before you start.
The Agency OS pattern turns a source-available platform into a repeatable product line: one stack you learn deeply, branded per client through design tokens and custom domains, isolated per client through separate instances and RBAC, billed under your own name with no platform cut. The margin comes from reuse; the ownership comes from self-hosting; the cost is that you run the infrastructure. For agencies that want to stop reselling other people's software and start owning the client relationship, that trade is often worth making. Weigh the recurring fees you'd charge against the operational load on the pricing details before you commit.
Next step: read the deployment and multi-instance recipes in the documentation to see exactly how one repeatable process provisions each new branded client platform.