Enterprise Overview

The Enterprise build of QuantumBPM is the same product as the managed SaaS, packaged for self-hosted deployment. It runs as a single organization against your own infrastructure and your own OIDC identity provider, with internal teams or business units modeled as projects and a signed license replacing the SaaS billing path.

Who Enterprise is for

• You need data residency, compliance, or air-gap that SaaS can't satisfy.
• You already operate an OIDC identity provider and want the platform to consume tokens from it directly.
• You want one platform binary running against your organization, with internal teams or business units modeled as separate projects (each with its own RBAC, schema, and Temporal namespace).

For evaluation on a single laptop, the devserver image is usually a better fit than a full Enterprise install.

What's included vs. SaaS

Area	SaaS	Enterprise
Identity	Zitadel (managed)	Bring your own OIDC provider
Tenancy	Multi-organization (one tenant = one customer)	One organization, but multi-project — model internal teams or business units as separate projects
Billing	Paddle integration, plan limits, credit accounting	None — replaced by license
RBAC source	Zitadel + database	OIDC token claims (stateless)
Bootstrapping	Auth Console UI	YAML provisioning file at startup
User management	Platform Console + Auth Console	Your IdP
License gating	None	Required signed license

For end users — anyone modeling, deploying, running instances, or building integrations — the contract is identical. Same UI, same APIs, same SDKs, same modeler.

Components

A working Enterprise deployment needs:

Component	Required	Purpose
PostgreSQL	Yes	Application database. Stores definitions, instances, history, project membership.
OIDC provider	Yes	Issues the JWTs the backend validates on every request.
Temporal server	If you use BPMN	Durable workflow substrate for the BPMN engine. DMN-only deployments can skip it.
Signed license JWT	Yes	Vendor-issued attestation; verified at startup and daily.

The backend itself is stateless — durable state lives in PostgreSQL (and Temporal, if used). Scale horizontally by running multiple backend replicas behind a load balancer.

                ┌─────────────────────────────┐
                │      Web UI image           │
                │  (served behind your proxy) │
                └────────────────┬────────────┘
                                 │ HTTPS (TLS at proxy)
                                 ▼
┌─────────────────────────────────────────────────────────┐
│       QuantumBPM backend (Enterprise build)             │
│   • OIDC token validation (stateless)                   │
│   • Project RBAC from token claims                      │
│   • License validation at startup + daily               │
└──────────┬────────────────┬─────────────────────────────┘
           │                │                  ▲
           ▼                ▼                  │
   ┌────────────┐   ┌──────────────┐   ┌─────────────────┐
   │ PostgreSQL │   │   Temporal   │   │ OIDC provider   │
   │ (required) │   │  (optional,  │   │   (your IdP)    │
   │            │   │   for BPMN)  │   │                 │
   └────────────┘   └──────────────┘   └─────────────────┘

Organization, projects, and isolation

The Enterprise binary runs as a single organization — there is no multi-organization routing layer like in SaaS. Inside that organization, you create as many projects as you need to model your internal structure: one per team, business unit, environment, customer-facing product, or whatever segmentation makes sense.

Projects are the unit of isolation the platform actually enforces:

• RBAC — each user's per-project roles come from their OIDC token claim, so a user can be editor on Project A and viewer on Project B (or absent from C entirely).
• Database — each project has its own PostgreSQL schema; cross-project queries don't happen by accident.
• Temporal — each project gets its own Temporal namespace; BPMN workflows in one project can't observe or signal workflows in another.

Provision projects via the YAML file read at startup — see Deployment → Project provisioning.

Running without Temporal

DMN evaluation, project management, definitions, and authentication all work without a Temporal cluster. Only BPMN process execution requires it.

To run DMN-only, set TEMPORAL_HOST_PORT="" explicitly.

Where to go from here

• Deployment — required components, license setup, project provisioning, reverse proxy.
• Authentication — wiring up your OIDC provider, claim mapping, role model.
• Configuration — what you can tune (REST, DB, caching, FEEL budgets, BPMN workers).
• Temporal — connection, TLS, search attributes, long-running workflow handling.
• Operations — observability, license monitoring, backups, upgrades.