Why Self-Host Your SaaS: The Case for VBWD

The honest case for self-hosting: keep the percentage hosted platforms take, own your data by architecture, get the whole subscription stack pre-built — and accept that uptime, backups and compliance are now yours.

Self-hosting is a trade, not a free lunch; here is the honest case for running your SaaS on VBWD, including the costs a hosted platform hides from you.

You’re renting the thing that pays your rent

Most people building a subscription product start on a hosted platform because it’s the fastest way to take a first payment. That’s a reasonable decision on day one. It gets less reasonable every month your revenue grows, because the platform’s cut grows with it. A 10% fee is invisible when you’re making $200 a month and painful when you’re making $20,000.

Self-hosting is the alternative, and it’s not a hobbyist position. It’s a business decision about who owns your customer relationships, your data, and your margins. VBWD is a source-available platform built for exactly this: running a subscription product or marketplace on infrastructure you control. This article makes the case, including the parts that are genuinely harder.

The economics: a fixed bill instead of a percentage

Hosted platforms are priced as a share of your success. Substack takes around 10%. Gumroad takes around 10%. OnlyFans takes around 20%. GoHighLevel starts at roughly $497/month before you’ve earned anything. These are convenient, and convenience has a price that scales with you.

Self-hosting inverts the math. You pay a fixed server bill plus your normal payment-processor fees (Stripe, PayPal, and the like charge the same whether you self-host or not). VBWD runs comfortably on a small EU VPS in the range of around €12–16/month. The percentage of every dollar you keep goes up as you grow instead of down.

The break-even is simple arithmetic. If a hosted platform takes 10% and you’re doing $5,000/month, that’s $500/month leaving your account for something a fixed server bill covers many times over. The higher your revenue, the more lopsided the comparison gets. You can walk through the model and what a real deployment costs on the pricing page.

One thing to be honest about up front: VBWD’s own license is not a percentage tax in disguise. It’s BSL 1.1 — free for commercial use until your VBWD-attributable annual sales exceed the value of 6.7 BTC (measured at the year’s average BTC/USD rate), at which point a commercial license applies. It also converts to Apache-2.0 on its change date. For the overwhelming majority of projects, that threshold is far above where you are, and you pay nothing for the software itself.

The data argument is not abstract

When you use a hosted platform, your customer records, payment metadata, and content live on someone else’s systems, under someone else’s jurisdiction, subject to someone else’s subpoenas. You are the data controller in the eyes of the law and your customers, but you don’t actually hold the data. That gap is where GDPR risk lives.

Self-hosting on an EU-resident VPS closes it. Your data has a physical location you chose. Your processor list is short and explicit by architecture — you know every service that touches customer data because you wired it in. You’re the data controller in fact, not just on paper, and you remove the exposure that comes from data sitting in a foreign jurisdiction that can compel disclosure without ever telling you.

This isn’t a compliance checkbox. For a European B2B product, “where does our data live and who can reach it” is a question buyers actually ask, and “on a server we control, in the EU” is a much stronger answer than “on a US platform, somewhere.”

What you actually get

Owning your stack only makes sense if you don’t have to build the stack. The reason self-hosting is usually rejected is the assumption that you’d be assembling billing, auth, and invoicing from scratch. VBWD ships those already built:

User accounts and authentication
Tiered subscription billing with trials and recurring charges
Multi-currency pricing and tax handling
Invoices
A token/credit system for usage-based products
A CMS for your marketing and content pages
Multi-provider payments — Stripe, PayPal, and YooKassa through swappable adapters, so you’re not locked to one processor
An admin backoffice for managing users, plans, and subscriptions
A plugin system, webhooks, and AI features including bots and an MCP server

The stack underneath is deliberately boring in the good sense: Python/Flask, PostgreSQL, Redis, Vue 3 with TypeScript, all in Docker. Nothing exotic to hire for, nothing that traps you. The payment-adapter design is worth calling out — because providers sit behind swappable adapters, switching from one processor to another is a configuration change, not a rewrite. You can see how the pieces fit on the architecture page, and the plugin catalogue shows what extends the core without touching it.

A minimal deployment looks about like this:

git clone the recipe
cp .env.example .env   # set DB, Redis, JWT, payment keys
docker compose up -d   # API, PostgreSQL, Redis, admin, storefront

From there you configure plans, wire your Stripe or PayPal keys, and point a domain at it.

The honest costs of self-hosting

Here is where a sales page usually goes quiet. It shouldn’t. When you self-host, you own operational responsibilities that a hosted platform absorbs for you, and pretending otherwise would set you up to fail.

Uptime is yours. If the server goes down at 2am, no one else is paged. You are.
Backups are yours. A cheap VPS with no backup plan is a single point of failure and one bad disk away from losing your customer records. Automated, tested, off-box backups are not optional.
TLS and certificates are yours. You set up HTTPS and keep it renewed.
OS and dependency patching is yours. Security updates don’t apply themselves.
Scaling is yours. If you get a traffic spike, you’re the one adding capacity.
Legal and compliance obligations are yours. Being the real data controller means you carry the duties that come with it.

None of this is exotic — it’s standard operations work, and the tooling to automate most of it is mature and well documented. But it’s real work, and it needs an owner. The documentation covers deployment, backups, and hardening, which shortens the learning curve but doesn’t remove the responsibility.

The clearest way to put it: if you would rather pay a percentage of revenue to never think about a server again, a hosted platform is the honest choice, and you should take it. Self-hosting trades a recurring fee for recurring responsibility. That trade is good for some people and bad for others.

Who it’s for, and who it isn’t

Self-hosting on VBWD is a good fit if you have some technical comfort or one person on the team who does; if your revenue is high enough that platform fees are a real line item, or you expect it to be; if data residency and being a genuine data controller matter to your customers or your regulators; or if you want to extend the platform with plugins rather than live inside someone else’s feature roadmap.

It’s a poor fit if you’re pre-revenue and just validating an idea, where the fastest path to a first customer matters more than margin. It’s a poor fit if no one on the team wants to own a server and you have no budget to contract that out. And it’s a poor fit if your product is a weekend experiment you might abandon — the operational overhead isn’t worth it for something disposable.

The takeaway

Self-hosting isn’t ideologically better than using a hosted platform. It’s a specific trade: you take on operational responsibility in exchange for keeping your margins, controlling your data, and owning your customer relationships outright. VBWD exists to make the “you take on operations” side as small as possible by giving you the billing, subscriptions, payments, CMS, and admin tools already built, on a stack you can actually maintain.

If the platform fees you’re paying have started to feel like a tax on your own growth, and you have — or can hire — someone to mind a server, the math is worth running. Start with the pricing page to compare against what you pay today, and read the architecture to judge whether it fits how you build.