Security & deployment you can verify yourself.

Yes. Building and installing Workflow Builder requires only a package registry and a container registry — both can be internal mirrors. Nothing in the build reaches any other host, and nothing is downloaded after installation. We test the build with all network access disabled and publish a step-by-step air-gapped installation guide, including the short list of container images to mirror.

Once installed, the stack has no external runtime dependency of its own: the editor, the execution engine, the database and the orchestrator all run inside your network. The only outbound call that can exist is the one you configure for AI nodes — the model endpoint — and it can point at a model running inside your network. With that in place, the deployment is fully air-gapped.

No SaaS component, no shared control plane, no account on our side. The backend is a self-hosted server. The orchestrator (Temporal) runs on your infrastructure — the reference deployment ships it — and the connection is configuration, so the same code talks to your own cluster, a hardened one, or Temporal Cloud if that is your choice, never a requirement.

All persistence is your database. The editor itself stores nothing — it persists through whatever endpoints your application exposes. In the reference stack, workflow definitions and their published versions live in the application database and execution events and run history in the orchestrator's — both PostgreSQL, both yours; the reference backend is built on PostgreSQL, so if your platform standardises on another database you build your backend against the engine's ports instead. Anything a workflow carries as variables is persisted in that run history too — keep secrets in the worker's environment, not in the graph. Encryption at rest and in transit is your infrastructure's; we add no secrets of our own.

Authentication and tenancy are explicit integration points you wire to your identity provider. The reference deployment ships with authentication deliberately open for local development and refuses to start unless you explicitly acknowledge that.

We don't need access to your environment to ship the product — everything we deliver is code you run, and we hold no standing credentials to customer systems. For support and retainer work, the access model is yours to choose, and we agree it with you up front. Every option is on the table: some customers deploy and operate everything themselves and use us for code and advice only; others grant us access — named accounts you provision and revoke, access over your VPN, or working sessions with your team over screen share where we never touch the system directly. Whichever model your policies allow, your administrators grant the access and your administrators revoke it.

Data follows the same rule. Depending on the engagement we work on synthetic data or on data you provide, and every engagement runs under an NDA — ours by default, yours if you prefer.

We don't hold SOC 2 or ISO 27001. Internally we use ISO 27001 as the framework for our security practices.

Workflow Builder itself doesn't rely on such an attestation: it is code you run, and we operate no service that touches your data, so the controls that matter for your deployment are yours.

If your process requires a questionnaire, send it — we answer it ourselves.

Everything in the Community Edition is reviewable before purchase. The full monorepo is public on GitHub under Apache 2.0: the React SDK, the reference backend, the Temporal worker and an examples folder. The SDK installs from npm. Documentation is public, including the API reference.

A live demo runs at app.workflowbuilder.io with no signup. The repo runs locally in about 2 minutes (UI demo, no Docker) or about 10 minutes (full stack with execution).

Public case studies name Vercom, Athena Intelligence and Plura AI. The Enterprise Edition additionally contains several source-available components that are not in the public repo: the Flow Runner plugin, the Figma Kit and advanced canvas plugins (ELK auto-layout, smart edge routing, edge reshaping).

The current list is the lockfile in the repository. Every runtime dependency, direct and transitive, is pinned there.

The editor SDK depends on UI, schema-validation, internationalisation and state libraries — none of them makes a network call. The execution core has no third-party dependencies. The reference backend and worker add an HTTP server, a PostgreSQL driver, the Temporal SDKs and the AI SDK used by AI nodes — the only component that talks to anything outside your network, and only when you configure it.

Licences. All runtime dependencies are under permissive licences — MIT, Apache 2.0, BSD, ISC and equivalents. Two worth naming: the bundled font is under the SIL Open Font License, and the PostgreSQL driver is a public-domain dedication (Unlicense). There is no copyleft licence anywhere in the runtime tree.

Can it be reduced to zero? Network-wise: yes. The SDK and the execution core never call out; the reference backend and worker need only your database and your orchestrator. The single egress — the model endpoint for AI nodes — accepts any OpenAI-compatible API, including one hosted in your network, and is not required unless you register AI nodes.

No — we operate no service that touches your data. Services run under NDA; a DPA applies only if you engage us on live personal data.

Yes. The editor runs with script-src 'self' — it needs neither 'unsafe-eval' nor inline scripts, by design. The one allowance it needs today is style-src 'unsafe-inline', because two components style themselves at runtime. Fonts and icons are bundled, and the only network access is to the endpoints you configure. Our reference deployment ships with this policy and is verified against it.

Both are your infrastructure's. Workflow Builder adds no encryption layer of its own — and stands in the way of none.

At rest. Everything the stack stores lives in your databases — PostgreSQL in the reference stack: workflow definitions in the application database, run history in the orchestrator's. Encrypt them the way you encrypt any database — at the volume or database level — and it applies with no configuration on our side. The stack holds no secrets of its own beyond the model API key in the worker's environment; anything a workflow carries as variables is persisted in run history, so keep secrets out of the graph.

In transit. The browser talks to the backend behind your TLS termination — the reference deployment expects your ingress in front of it and sends HSTS. Connections to your database use TLS when you enable it in the connection string; connections to your orchestrator can use TLS or mutual TLS; calls to the model endpoint are HTTPS.