Security
Orch8 runs code, stores workflow state, and may hold credentials. This page describes implemented controls and operator responsibilities. It is not a certification or a substitute for reviewing the version you deploy.
The server supports API-key authentication and tenant-scoped access. Cross-tenant storage lookups carry tenant identity in their signatures. Operators remain responsible for key distribution, rotation, network exposure, and database access.
With a 256-bit key configured, the storage wrapper uses AES-256-GCM for credentials, workflow context, block outputs, worker parameters, signals, checkpoints, step logs, and other protected state. The server refuses to start without a key unless an explicit insecure-storage flag is supplied.
Workflows reference stored secrets through credentials:// identifiers. Provider tokens, idempotency, TLS trust, and the behavior of third-party handlers are still part of your application threat model.
The engine repository includes dependency policy configuration, locked dependencies, security tests, and release tooling for checksums, SBOM evidence, and provenance attestations. Verify the evidence attached to the exact artifact you deploy.
Security pack
The data flow for Hybrid, what each plan sends to Orch8, and a questionnaire pre-filled from the engine repository. Where the published material does not answer a question, the questionnaire says “available on request” instead of guessing.
Pre-filled security questionnaire
Company, data handling, encryption, access control, logging, secure development, recovery, and licensing, as a Markdown file.
Orch8 Cloud runs the engine
The orchestrator and its database run in Orch8 Cloud. It stores sequence definitions and run state, schedules steps, and renders each step's params and context. Steps without placement run in Cloud.
Executors dial out from your VPC
Executors connect outbound to Orch8 Cloud with a dedicated executor API key from the join token and advertise their labels. Nothing listens for inbound connections from Orch8, and Cloud has no route into your network.
Placed steps run next to your systems
Steps routed by placement labels or tenant placement policies are claimed by a matching executor, which runs them with the credentials it reads locally and its access to your internal APIs. Results go back to Cloud.
Optional: seal outputs with BYOK
An executor configured with BYOK stores large step output fields in your own bucket, encrypted with a data key wrapped by your KMS key. Cloud keeps only the reference and the wrapped key. Step params and context rendered by Cloud and error messages are never sealed, and a step that is not placed on an executor receives the reference, not the data.
| Plan | Who runs the engine | Orch8.io stores | Orch8 Cloud receives |
|---|---|---|---|
| Self-hosted | You | Nothing | Nothing |
| Observability | You | Run metadata, 30 days | Run metadata: ids, sequence name and version, state, timings, error kind |
| Cloud (Starter, Pro) | Orch8.io | Workflow data, context, outputs, logs for the plan retention | Everything the hosted engine processes |
| Hybrid | Orch8.io runs the engine and database; your executors run placed steps in your VPC | Sequence definitions, run state, step params, context, outputs (output fields sealed by BYOK on the executor only as references), error messages, executor identity and labels, placement policies, 90 days | Everything the engine processes, except the plaintext of output fields sealed by BYOK on the executor. Never the credential values of placed steps or access to your network. Credentials of steps that are not placed live in Cloud's credential store |
| Embedded | You | Nothing by default | Nothing by default; the licence key is verified offline |
Account, team, and billing data for any Cloud workspace are handled as described in the privacy policy. No SOC 2 or ISO 27001 report is published; ask us for the current status.
The latest internal review remains a historical engineering record, not an external audit. It identifies open design work around scheduler tenant scoping, a synchronous gRPC authentication path, DNS-rebinding windows in outbound URL validation, expression-depth limits, and CDN endpoint enforcement. Do not market a deployment as confidential or sovereign without an independent review of its complete threat model.
Read the audit notes in the repository →Do not open a public issue. Email security@orch8.io. We aim to acknowledge receipt within 48 hours and provide an initial assessment within seven days.