You already sell to a market VBWD serves. You have the customer relationships, the domain knowledge, and a brand people recognise. What you don't want to build from scratch is subscription billing, user management, an admin backoffice, and a plugin system to hang your features on. That is the gap an OEM arrangement closes: take VBWD, put your name on it, and sell it as your platform.
This is a playbook, not a pitch. It covers what you can rebrand, how you run one deployment per customer, how the licensing side actually works, and — because it matters — where the honest limits are.
VBWD is self-hosted and source-available: Python/Flask with PostgreSQL on the backend, Vue 3 on the frontend, packaged with Docker. The core is deliberately domain-agnostic; everything specific to a vertical lives in plugins. You can read the shape of that in the architecture overview, and the plugin catalogue on the plugins page shows what already exists to build on (payments, subscriptions, CMS, bots, marketplace, and more).
OEM here means you take that stack, rebrand it end to end — logos, colours, transactional emails, custom domains — and sell the result to your own customers under your own name. You are not reselling "VBWD by the seat." You are shipping your product, and VBWD is the engine underneath it. The end customer never needs to know the engine's name, and in most OEM deals they never do.
Because the source is available, you are not reverse-engineering a black box or waiting on a vendor's roadmap to expose a feature flag. If a customer needs a payment provider that isn't packaged yet, you can write an adapter. If they need a vertical feature, you write a plugin. That is the practical difference between an OEM arrangement and a white-label SaaS reseller programme: you hold the code.
The frontend is split into three repositories, and knowing that split tells you exactly where branding lives:
Colours and visual theme are driven by CSS variables and theme tokens rather than hard-coded values, so re-skinning is a matter of setting a token palette, not hunting through component files for hex codes. Logos, favicons, and app names are configuration. Transactional emails — the account, billing, and notification messages your customers' users receive — carry your sender identity and templates, not VBWD's. Custom domains close the loop: each deployment answers on the customer's own hostname, so nothing in the URL bar contradicts the brand.
A realistic first-pass rebrand is: set the token palette in fe-core, drop in logo assets, wire the custom domain, and adjust the email templates. That gets you a platform that reads as yours across the surfaces a customer actually looks at. Deeper customisation — restructured layouts, custom admin pages — is plugin and component work on top of that baseline.
The model that holds up in practice is a separate instance per customer rather than one shared multi-tenant database. Each deployment is its own Docker stack: its own Postgres, its own configuration, its own domain, its own plugin set enabled or disabled to match what that customer bought.
This costs you a little more in orchestration and buys you a lot in isolation. One customer's data never shares a database with another's. One customer's outage, migration, or noisy workload doesn't touch the rest. You can run different customers on different plugin combinations and even different versions during a staged rollout. When a customer churns, you decommission one stack; you are not carefully deleting rows out of a shared table and hoping you got the tenant filter right everywhere.
Practically, this means your operational work scales with the number of instances, so investing early in a repeatable deploy pipeline pays off fast. The upside is that each instance is a clean, standard VBWD stack — the same thing you tested — which keeps support tractable.
Different customers come with different constraints — a payment processor their bank mandates, a payout arrangement their business model requires, a region where a given PSP isn't available. VBWD's core talks to these through provider-agnostic ports rather than baking one vendor in.
Payment providers are adapters behind a common interface, so adding or swapping a PSP is a matter of implementing the adapter, not patching the checkout flow. Payouts go through an IConnectProvider port on the same principle. The core routes through the interface; the concrete provider is a plugin choice per deployment. For an OEM that serves customers across regions or industries, this is what lets you say yes to a payment requirement without forking the platform. The architecture pages describe the port-and-adapter approach in more depth, and it is worth understanding before you promise a customer a specific processor.
If you sell tiers — a base product, add-on features, premium plugins — you need a way to turn capabilities on and off per customer without shipping a different build to each one. VBWD's designed answer to this is a License Server / hub that issues signed license keys. A deployment presents its key; the core verifies the signature and gates the corresponding capability.
Be clear-eyed about what this is: it is VBWD's designed monetization architecture, the same mechanism VBWD uses to gate its own commercial features. As an OEM you can build your own per-customer and per-feature licensing on top of it — issue a key that unlocks the plugins a given customer paid for, and their instance honours it. It is a capability you assemble into your product, not a turnkey billing SaaS you switch on. You still design your tiers, decide what each key unlocks, and run the issuance. What the hub gives you is the cryptographic gate and the key-issuing machinery so you are not inventing signed-license infrastructure yourself. The documentation is the place to go for how keys are issued and verified before you design your tiering around it.
This is the part that decides whether an OEM arrangement is profitable for you, so read it plainly: you operate every deployment.
Uptime is yours. Backups are yours. Applying updates and security patches across your fleet of instances is yours. First-line and second-line support to your customers is yours — they bought from you, they call you. VBWD is the platform vendor; you are the operator and the face your customers see.
That is not a hidden cost so much as the actual business you are in. An OEM that treats operations as an afterthought will drown in per-instance toil the moment it has more than a handful of customers. An OEM that builds a solid deploy-and-update pipeline early turns operations into a margin. Budget for it: monitoring, backup verification, an update cadence you can execute across every instance, and a support process. The pricing page is the right starting point for understanding the commercial side of the relationship with VBWD itself, separate from what you charge your own customers.
A few things worth stating directly, because they will come up:
OEM is a commercial arrangement. VBWD is licensed under BSL 1.1 (Business Source Licence). Use is free while annual VBWD-attributable sales stay below the value of 6.7 BTC per year; the licence converts to Apache-2.0 as its change licence. An OEM business selling the platform to customers is, essentially by definition, operating above the free-use threshold, so you will need a commercial licence. The straightforward path is to talk to us and get the arrangement in writing before you sign your first customer. (For the avoidance of doubt: VBWD is source-available under BSL, never public-domain — it is not CC0.)
You own your customers' compliance. Data residency, payment regulation, tax handling, privacy obligations — these attach to the deployment you operate for a given customer, in their jurisdiction, for their industry. The platform gives you the mechanisms; it does not absolve you of the compliance work. Scope this per customer.
The hub is designed capability, not a managed service. The License Server / hub is architecture you run and assemble into your offering. It is real and it is designed for exactly this, but framing it to your own customers as a finished, hosted, turnkey SaaS would be overstating it. Set expectations to match what you are actually operating.
The OEM path on VBWD is a clean trade. You bring the market, the brand, and the customer relationships. VBWD brings a source-available, agnostic-core platform — billing, users, admin, plugins, provider-agnostic payment and payout ports, and a licensing hub — that you rebrand end to end and deploy one instance per customer. In return you take on real operational ownership: uptime, backups, updates, support, and your customers' compliance. If you were going to build that operational muscle anyway, an OEM arrangement lets you skip building the platform and put your effort where your advantage actually is.
Start with the architecture and plugins pages to see what you'd be rebranding, then talk to us about a commercial licence before you sign your first customer.