Every integration is a flow graph.
No SDK, no module to publish. Drag twelve node types onto a canvas, wire them together, and the runtime walks the graph on every invocation. Payment gateways, hypervisors, registrars, notifications — all of them, the same way.
The graph is the plugin.
What you draw on the canvas is what gets persisted to visual_plugin_flows.canvas as JSONB. No build artefact, no compilation, no SDK module. The same shape ships in the .xzplugin export and the same shape replays on import.
{ "format": "fluxbilling-visual-plugin", "version": "2.0", "plugin": { "name": "Stripe", "slug": "stripe", "type": "payment-gateway", "capabilities": { "supportsRefund": true, "supportsRecurring": true, "webhookRequired": true } }, "connections": [{ "slug": "stripe-api", "baseUrl": "https://api.stripe.com/v1", "authType": "bearer_token" }], "flows": [{ "slug": "create-checkout-session", "flowType": "action", "canvas": { "nodes": [/* 5 */], "edges": [/* 4 */] } }]}Twelve node types. Enough for any REST integration.
The library is intentionally small. HTTP, transform, branch, loop — the primitives every integration actually uses. Each node emits structured output to the run trace, so debugging is reading a list, not stepping through a debugger.
Five plugin categories. One runtime.
Every plugin declares one of five plugin.type values. The category routes the graph into the right host: payments through GatewayRegistry, infrastructure through VisualPluginAdapter, notifications through NotificationRetryProcessor.
You almost never start from a blank canvas.
Six service-type starters scaffold the connection, capabilities, and a working flow set. Nine flow scaffolds add common shapes — lifecycle, power, data fetch, CRUD, payment — on top.
Ship a plugin as a single .xzplugin file.
Export bundles the manifest, connections, flows, webhooks, forms, styles, and config schema into a gzipped JSON file. Import on any tenant. The marketplace publishes the same bundle — admins install with one click and configure the connection per tenant.

Plugin code is third-party code. Treated like it.
Every plugin runs in the tenant’s own pod under the same auth model and rate limits as a regular API client. No god-mode internals, no privileged escape hatches, no shared secrets across tenants.
- Per-tenant isolation
- Plugin set lives inside the tenant pod. Sensitive settings encrypted with the per-tenant SETTINGS_ENCRYPTION_KEY. No cross-tenant path.
- Trace-first execution
- FlowExecutor records per-node input, output, latency, and errors to the run trace. Debugging is reading a list, not stepping through a debugger.
- Marketplace export-lock
- Plugins installed from the marketplace cannot be re-exported. PluginPackager refuses on a marketplace_listing_id check — anti-piracy without DRM theatre.
Try it on your own data. Refund inside 14 days if it’s not the fit.
Pick a tier and provision a tenant in under two minutes — isolated K3s namespace, your own database, the full product. If FluxBilling isn’t the right fit inside 14 days, open a ticket and we’ll refund the subscription. No sales call, no qualification gate. Want to look around first? The live demo opens the admin and client panels with sample data, no signup.
- 01.< 1 minPick a tierLite from €4.95/mo. Upgrade later, no migration.
- 02.< 2 minProvision the tenantIsolated K3s namespace + your own PostgreSQL database. Full product, your data.
- 03.d0 — d14Refund inside 14 daysNot the fit? Open a ticket within 14 days and we refund the subscription. No questions, no qualification gate.
