FluxBilling
Security

Security is a property of the topology, not a button you tick.

FluxBilling isolates each hosting provider's tenant at the database, namespace, and network policy level. Encryption is per-tenant. Backups replicate off-site. Disclosure has a published mailbox and a response window. The page below documents how each of those is wired.

At rest
AES-256-GCM
In transit
TLS 1.3
Isolation
K3s namespace
Region
EU · NL
Trust signals

The four things auditors ask about first.

Every claim below resolves to a concrete mechanism documented further down the page.

Encryption

AES-256-GCM at rest for credentials and tenant settings. TLS 1.3 in transit, HSTS enabled.

Tenant isolation

Per-customer PostgreSQL database and dedicated K3s namespace. No shared application processes.

EU data residency

EU-region by default. Master + tenant pods deploy to NL; regional pods on contract.

2FA & sessions

Email-code 2FA for operators, optionally enforced per role. Session tokens rotate and are revocable per device.

Topology

How tenants are deployed and protected.

One control plane. One standby that holds a synced copy of master state. Tenant pods land in the operator’s chosen deployment locations, each with its own Postgres and backup cron.

Topology
fleet · 2 locations
Master Server
Primary
Control plane · K3s · Registry
Standby Server
Standby
Backup store · Failover ready
Location A
K3s · Postgres · Backups
NL
  • Tenant 1· Pod · DB · PVC
  • Tenant 2· Pod · DB · PVC
  • Tenant 3· Pod · DB · PVC
Location B
K3s · Postgres · Backups
FI
  • Tenant 4· Pod · DB · PVC
  • Tenant 5· Pod · DB · PVC
  • Available capacity
MasterStandbyLocationTenant pod
Mechanisms

How each control is implemented.

One row per topic. Plain prose on the left, the four specifications that matter on the right.

  • 01.Encryption

    Encryption

    Credentials, API keys, gateway secrets, and any tenant setting flagged sensitive are encrypted with AES-256-GCM using a per-tenant key derived from SETTINGS_ENCRYPTION_KEY. Network traffic terminates at TLS 1.3; HSTS is enabled on the operator and customer panels.

    At rest
    AES-256-GCM
    In transit
    TLS 1.3
    Header
    HSTS
    Key scope
    Per-tenant
  • 02.Tenant isolation

    Tenant isolation

    Every customer runs as its own K3s pod inside a dedicated namespace, with a dedicated PostgreSQL database on a shared but per-tenant-scoped Postgres instance. There is no shared application process, no shared in-memory cache, and no cross-tenant connection pool. Each pod is scoped to its own namespace, so tenants cannot reach each other through the application layer.

    Compute
    K3s namespace
    Database
    Per-tenant DB
    Process
    Per-tenant pod
    Pool
    Per-tenant
  • 03.Authentication

    Authentication

    Operator accounts support email-code 2FA, which an organisation can require per role. Sessions issue rotating JWTs with a refresh token, configurable timeout, and per-device revocation from the panel. Webhook deliveries are HMAC-signed.

    2FA
    Email code
    Session
    Rotating JWT
    Revoke
    Per-device
    Webhooks
    HMAC-signed
  • 04.Data residency

    Data residency

    Master and tenant pods deploy to EU-region infrastructure (NL) by default. Customers requiring a specific region (US, APAC) get a dedicated tenant pod and per-region backup target on contract. Data does not leave the contracted region for the lifetime of the tenant.

    Default
    EU · NL
    Optional
    US · APAC
    Transfer
    Region-locked
    DPA
    On contract
  • 05.Backups

    Backups

    Each tenant database is dumped on a scheduled cron and shipped to the master backup store with a 7-day rolling retention. When a tenant runs in a non-master deployment location, the dump is taken on the remote server and copied back over SSH so the master holds a copy in a separate region. Restore is a documented operator action.

    Method
    pg_dump + gzip
    Cadence
    Daily cron
    Retention
    7 days rolling
    Off-site
    Master copy
  • 06.Vulnerability disclosure

    Vulnerability disclosure

    Send reports to security@fluxbilling.app. We acknowledge receipt within one business day, send an interim status within five, and credit the reporter on resolution unless asked otherwise. We do not pursue legal action against good-faith research conducted within the scope below.

    Email
    security@fluxbilling.app
    Ack
    < 1 business day
    Update
    < 5 business days
    Safe-harbour
    Yes
  • 07.Incident response

    Incident response

    Incidents are triaged by severity. Sev-1 affects multiple tenants or risks data integrity — paged 24/7. Customer notification with scope and timeline is sent within 24 hours of confirmation. A post-incident write-up follows within 10 business days, including the root cause and the change that prevents recurrence.

    Sev-1
    Paged 24/7
    Notify
    < 24h
    Post-mortem
    < 10 days
    Scope
    Multi-tenant
Compliance posture

What we hold — and what we do not, yet.

No certification claims unless the report is signed. The four entries below are the live status as of the page footer date.

GDPR
Data Processing Addendum available on contract. Data subject rights (access, deletion, portability) are supported via the operator panel and the customer-facing portal.
PCI DSS
Self-assessed scope SAQ A. Card data is tokenised by the payment processor (Stripe, PayPal, and other plugin gateways); FluxBilling stores only the resulting token reference, never the PAN, CVV, or expiry. We do not hold a PCI certification.
SOC 2
Not certified. Underlying infrastructure providers maintain their own SOC 2 / ISO 27001. A formal SOC 2 Type II is on the roadmap — the report will be published when signed, not before.
Dependencies
Production dependencies are tracked in lockfiles (Bun) and updated on a regular cadence. Disclosed vulnerabilities with a credible exploit path are prioritised and patched in the next release.
Report a vulnerability

Send it to a real mailbox. Get a real response.

We treat the security mailbox as a critical inbox. Acknowledge in a business day, interim status in five, and we credit the reporter on resolution unless asked otherwise. Test only on your own tenant, do not pivot, do not exfiltrate — that is the safe-harbour boundary.

security@fluxbilling.appOther contact routes
Disclosure flow
Active
  1. 01.
    Send the report
    Steps to reproduce, affected tenant, suspected impact.
    You
  2. 02.
    Acknowledged
    A reply with a tracking ID and an owning engineer.
    < 1 day
  3. 03.
    Investigation
    Triage, severity assignment, interim status update.
    < 5 days
  4. 04.
    Patch & credit
    Fix shipped, advisory written, reporter credited.
    On fix
Safe-harbour · No legal action on good-faith research
Updated 2026-05
Documentation

Where these controls live in the panel.

Get started

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.

Pick a tierTalk to sales
14-day refund
Standard policy
  1. 01.
    Pick a tier
    Lite from €4.95/mo. Upgrade later, no migration.
    < 1 min
  2. 02.
    Provision the tenant
    Isolated K3s namespace + your own PostgreSQL database. Full product, your data.
    < 2 min
  3. 03.
    Refund inside 14 days
    Not the fit? Open a ticket within 14 days and we refund the subscription. No questions, no qualification gate.
    d0 — d14
14-day refund · cancel any time
Start →