Bookings and Appointments with VBWD: A Self-Hosted Scheduling-and-Payments Stack

How to run appointments, availability, payment and a branded client portal on VBWD’s booking plugin — self-hosted, GDPR-friendly, and composed with the billing engine.

A booking site needs scheduling, payment, and access control that fit together; VBWD’s booking plugin composes all three on infrastructure you own.

Scheduling and payments usually live in two systems. They don’t have to.

Most booking tools stop at the calendar. You still bolt on a payment processor, a separate CRM for client records, and a landing page builder that lives somewhere else again. Each integration is a webhook you maintain and a data-residency question you answer. VBWD takes the opposite approach: appointments, invoicing, payment capture, access control, and public pages run inside one self-hosted stack you own.

VBWD is source-available under BSL 1.1 — free to run commercially until your VBWD-attributable sales cross the value of 6.7 BTC per year, and the licence converts to Apache-2.0 on its change date. You host it yourself on a small VPS with Docker and a one-command installer. No per-booking platform fee sits between you and your customer.

What the booking plugin gives you

Booking in VBWD is a plugin, not a hardcoded feature. It adds the domain objects a scheduling business needs: services (the things people book), availability (when they can be booked), and appointments (the actual reservations). The plugin registers itself against the platform’s seams — the dependency-injection container, the event bus, registries, and CMS layouts — so it slots into the core without anyone editing core code. That boundary is deliberate: the core stays agnostic about what you sell, and the domain knowledge lives in the plugin.

Practically, this means an appointment is a first-class record with its own lifecycle, and other plugins can react to it. When a booking is confirmed, the event bus carries that fact to whatever is listening — the invoice engine, an email handler, an access-level grant. You compose behaviour instead of forking a monolith. The plugin catalogue and how these pieces fit together is documented at vbwd.cc/plugins.

A worked example: a two-practitioner clinic

Say you run a small physiotherapy clinic with two practitioners, a front-desk person, and clients who book online. Here’s how the pieces map.

Each practitioner’s offerings become services — “Initial assessment, 60 min”, “Follow-up, 30 min” — with a price attached. Their working hours become availability windows. A client visiting your site sees open slots and books one; that creates an appointment record tied to a service and a time.

The booking doesn’t end at the calendar. Because the plugin composes with the billing engine, that confirmed appointment can generate an invoice line automatically. The client pays through whichever payment plugin you’ve enabled, and the appointment, the invoice, and the payment are all rows in the same PostgreSQL database — queryable together, exportable together, backed up together. When your accountant asks for last quarter’s paid appointments, that’s one query, not a reconciliation across three vendors.

You don’t have to build this clinic from an empty database, either. VBWD ships ready-made vertical demo instances — a doctor/clinic instance among them, plus things like a hotel/B&B setup — that arrive with a sensible plugin set and starter content. You import one, rebrand it, and adjust services and pricing. The demo instances and the broader feature set are laid out at vbwd.cc/features.

Wiring payment and access

Payment capture is handled by payment plugins sitting behind a swappable adapter. Stripe, PayPal, and YooKassa are supported through the same seam, so the choice is configuration, not a rewrite. If you start on one processor and later switch — a common story when you expand into a new region — the booking and invoice logic doesn’t change; only the adapter does. The invoicing and payment model is described under vbwd.cc/billing.

Access control is where the clinic example gets interesting, because a scheduling business has several kinds of user who should see very different things. VBWD runs three role systems side by side:

User.role — the coarse account type on the user record itself.
Admin roles — these gate the /admin back office. Your front-desk person can manage the day’s appointments without touching billing configuration or plugin settings.
User access levels — these gate the /user area, which is what a logged-in client sees.

On top of those, permissions are granular and per-plugin. So “front desk can reschedule but not refund”, “practitioner sees only their own calendar”, and “client sees only their own appointments and invoices” are all expressible without custom middleware. For a health-adjacent business that separation isn’t a nicety — it’s the difference between a receptionist and a clinician having the right scope over patient data.

A grant can also be event-driven. A confirmed, paid booking can raise a client’s access level automatically, unlocking a member area or downloadable resources. The event bus makes that a subscription, not a cron job you babysit. A concrete outline:

appointment.confirmed
  -> invoice engine     (create line item, issue invoice)
  -> payment adapter    (capture via Stripe / PayPal / YooKassa)
payment.captured
  -> access level grant (raise User access level -> unlock /user area)
  -> email handler      (send confirmation + calendar details)

The public page comes with it

The part people forget: clients need somewhere to actually book. VBWD’s CMS handles public and landing pages, and a plugin can publish its own page by registering a layout and a widget — no edit to the Vue frontend router required. Your “Book an appointment” page and its embedded slot picker are content you manage in the admin, not a deploy. Marketing can adjust the landing copy while the booking widget keeps working, because the widget is a registered component, not a hand-wired template. The integration model for this is covered in the platform docs at vbwd.cc/docs.

Data residency and GDPR

Because you host VBWD yourself, appointment and client data lives on infrastructure you choose — including an EU-resident VPS. For clinics and other health-adjacent operators, that matters: the architecture keeps personal data inside your boundary rather than shipping it to a third-party scheduling SaaS whose sub-processors you have to audit. There’s no platform intermediary holding your client list. GDPR compliance is still your responsibility to configure and operate, but the self-hosted design starts you from a defensible position rather than working against you.

Honest limits

This is a build-it-yourself stack, and that cuts both ways. You run the VPS, apply updates, take backups, and own uptime — there’s no vendor pager. The one-command installer and Docker packaging keep the initial setup short, but “self-hosted” means the operational responsibility is genuinely yours.

The booking plugin gives you services, availability, and appointments as solid primitives; it is not a specialised vertical product with, say, insurance-claim workflows or resource-level room inventory baked in. Complex rules — overlapping resources, multi-staff group sessions, deposit-then-balance payment splits — are reachable through the plugin seams, but reaching them is development work, not a settings toggle. If your scheduling logic is exotic, budget for that.

Extending the platform assumes some comfort with the stack: Python and Flask on the backend, Vue 3 and TypeScript on the frontend, PostgreSQL and Redis underneath. You don’t need to touch any of it to run a demo instance and take bookings, but you do to build something the plugins don’t already cover.

Takeaway

If you want scheduling and payments in one system you actually control, VBWD gives you the primitives and the wiring: appointments that flow into invoices, payments behind a swappable adapter, three-tier access control that separates front desk from practitioner from client, and a public booking page you manage as content. Start from the clinic or hotel demo instance, rebrand it, and you have a working booking business on a small VPS — with no platform cut on the way out and your client data staying where you put it.