Hybrid · your executors, our orchestrator

Your credentials and your network stay in your VPC. We run the orchestrator.

Orch8 Cloud runs the engine and its database. Executors in your VPC dial out, claim the steps you place on them, and run them next to your secrets, internal APIs, and private network. Steps without placement run in Cloud.

Start Hybrid Talk through your network

$499/month with 10 executors included, then $25 per executor. See pricing →

Where the line is

Connections run one way: your executors dial out to Cloud, claim placed step tasks, and send back results. Cloud never opens a connection into your network. Because Cloud runs the engine, it sees what the engine needs to orchestrate: definitions, run state, and the params, context, and outputs of each step, unless you externalize those payloads to your own bucket and key.

Your VPC

Orch8 executors running your placed steps
Your credentials and secret manager
Your internal APIs, databases, and private hosts
Optional: your bucket and KMS key for externalized payloads (BYOK)

Orch8 Cloud

The orchestrator: scheduling, timers, retries, state
The engine database and sequence definitions
Steps without placement
Fleet console, placement policies, run history

What stays in your network and what Orch8 Cloud sees.
Data	Location
Credential values for placed steps (ORCH8_CREDENTIAL_<id> or ORCH8_CREDENTIALS_DIR on the executor)	Stays in your VPCNever sent to Cloud; Cloud stores only the credentials://<id> reference
Network access to your internal APIs, databases, and private hosts	Stays in your VPCCloud never gets a route in
Side effects of placed steps (API calls, writes, payments)	Stays in your VPCExecuted by your executors
Plaintext of output fields sealed by BYOK on the executor	Stays in your VPCCloud stores a reference and a wrapped key
Sequence definitions	Seen by CloudStored in Cloud
Run state and metadata: ids, states, timers, retries	Seen by CloudStored in Cloud
Step params and context rendered by the engine	Seen by CloudStored in Cloud; never sealed
Credentials referenced by steps that are not placed	Seen by CloudResolved from Cloud's credential store
Step outputs	Seen by Cloud, or yours with BYOKStored in Cloud unless sealed with BYOK on the executor
Error messages of failed steps	Seen by CloudStored in Cloud
Executor identity, labels, region, credential ids, lease heartbeats	Seen by CloudStored in Cloud

Try the placement rules

An interactive mock of the fleet console. Drain the EU executors and watch an EU-only step wait instead of running in the US. Nothing here connects to a real fleet.

Fleet console

Demo · sample data

Executors in your VPC

Select one, then drain it. Placement re-evaluates immediately.

Placement for charge_card

{ "residency": "eu", "labels": { "pool": "payments" } }

Dispatches to exec-eu-1

Drain evidence

Nothing drained yet.

Who sees what for this step

Orch8 Cloud

sequence refund_v3 (definition)
run state: running
rendered params: { amount, currency, customer_ref }
step output (unless sealed with BYOK on the executor)

Your VPC

STRIPE_SECRET_KEY read by the handler
the call to your payments API
the network route to that API

Cloud schedules the step and renders its params. The key and the network call stay with the executor.

What Hybrid gives you

Outbound-only executors

Executors dial out to Orch8 Cloud with a dedicated executor API key, claim step tasks, and report results. No inbound ports, no VPN, and no route from Cloud into your network.

Hybrid guide →

Placement decides what runs where

A step runs on your executors only when its placement labels, or a tenant placement policy, route it there. Everything else runs in Cloud. A placed step that no connected executor can satisfy waits with placement_unsatisfied; it is never run somewhere else to make progress.

Placement rules →

Your bucket, your key (BYOK)

Configure BYOK on the executor and it seals large step output fields into your own S3-compatible bucket, each encrypted with a data key wrapped by your KMS key. Cloud keeps the reference and the wrapped key, not the plaintext, and needs no KMS access. Params and context rendered by Cloud are never sealed.

BYOK externalization →

Drain one replica at a time

Each executor replica registers separately, so draining one pod never withdraws its siblings. On SIGTERM or a drain command the replica advertises draining, stops claiming, lets in-flight steps finish within its drain timeout, and releases the rest for retry elsewhere with the attempt marked unknown. A killed executor's leases are reclaimed by the engine's reaper.

Drain and failures →

Signed effect receipts

Every side-effecting attempt gets a durable receipt and an idempotency key to pass downstream. When an executor dies mid-call the receipt is marked unknown instead of silently retried, so you can reconcile before repeating a charge or an email. Execution is at-least-once; receipts make the uncertain cases visible.

Effect receipts →

One console for the fleet

See executors, labels, queue depth, and run history across regions in Orch8 Cloud. Placement policies are edited once and enforced on every claim. Queue-depth metrics by capability, region, and lane feed your autoscaler.

Cloud docs →

Connect an executor

A join token carries the Cloud endpoint, a dedicated executor API key, and your labels. Treat it as a secret. The command writes an executor config file with your labels and starts the process. Protect that file like any other credential.

terminal

1# 1. In Orch8 Cloud: Executors → Connect an executor. Copy the one-time join token.
2# 2. On a host inside your VPC (the command reads ORCH8_JOIN_TOKEN):
3export ORCH8_JOIN_TOKEN='o8x1.…'
4orch8 executor join \
5  --label site=vpc --label pool=payments \
6  --config-out /etc/orch8/orch8.toml \
7  --run

With Docker Compose, the executor needs only the join token.

docker compose

1# deploy/hybrid-executor/docker-compose.yml from the engine repository.
2# The join token is all it needs: no database, API key, or encryption key.
3export ORCH8_JOIN_TOKEN='o8x1.…'
4docker compose -f deploy/hybrid-executor/docker-compose.yml up -d
5# Credentials for placed steps: ./credentials/<id> on this host.

On Kubernetes, the engine's Helm chart runs executors with mode=executor: the token comes from a Secret, each pod joins under its own name, and a Secret whose keys are credential ids is mounted as ORCH8_CREDENTIALS_DIR. hybrid.allowedInternalCidrs lists the internal networks placed steps may call; everything else stays limited to public addresses.

helm

1kubectl create secret generic orch8-join --from-literal=join-token='o8x1.…'
2kubectl create secret generic orch8-executor-credentials --from-file=vpc-api=./vpc-api.json
3helm install exec deploy/helm/orch8 \
4  --set mode=executor \
5  --set hybrid.joinToken.existingSecret=orch8-join \
6  --set hybrid.credentials.existingSecret=orch8-executor-credentials \
7  --set hybrid.allowedInternalCidrs=10.0.0.0/8

A connected executor runs nothing until placement routes steps to it. Route whole sequences with a tenant policy, for example every instance tagged vpc:

placement policy

1PUT /api/v1/placement/policies
2{
3  "items": [
4    { "name": "vpc-tagged",
5      "match": { "tag": "vpc" },
6      "require": { "labels": { "site": "vpc" } } }
7  ]
8}

Or place a single step. A step with labels always goes to an executor that advertises them.

sequence step

1{
2  "type": "step",
3  "id": "charge_card",
4  "handler": "charge_card",
5  "placement": {
6    "labels": { "site": "vpc", "pool": "payments" }
7  }
8}

Status and limits

• Executors, placement, and BYOK externalization are beta engine features. Check the changelog for the engine release that includes them.
• Only placed steps run in your VPC. Steps without placement run in Cloud.
• Cloud sees the rendered params and context of every step, and they are never sealed. Step outputs and error messages are visible to Cloud; BYOK on the executor seals output fields only, and error messages are never sealed.
• A step that is not placed on an executor and templates a BYOK-sealed field receives the reference, not the data. A sealed reference opens only inside its own instance.
• Credential values for placed steps are read on the executor and never sent to Cloud. Credential values for steps that are not placed live in Cloud's credential store.
• Activities run at least once. Effect receipts and idempotency keys make retries safe to reason about; they do not make external systems transactional.
• We operate the engine and its database. You operate the executors: patching, capacity, and egress policy stay your responsibility.
• Read the security pack for the data flow, the per-plan data table, and a pre-filled vendor questionnaire.

Questions security teams ask

Does my workflow data leave my VPC?

Some of it does. Orch8 Cloud runs the engine, so it stores sequence definitions and run state, and it renders the params and context each step receives; those are never sealed. Step outputs and error messages are reported to Cloud. Output fields an executor seals with BYOK reach Cloud only as references, and a step that is not placed on an executor and templates such a field receives the reference, not the data. What stays in your VPC is what your executors hold locally: the credential values of placed steps, your network access, and the side effects of the steps you place there.

Which steps run on my executors?

Only steps routed there by placement: labels on the step or sequence, or a tenant placement policy (for example, every instance tagged vpc requires the label site=vpc). Steps without placement run in Cloud. An executor runs the built-ins http_request, llm_call, tool_call, email, notify, transform, assert, log, sleep, noop, and fail; built-ins that change engine state (set_state, send_signal, human_review, wait_for_event, memory and blob steps) always run in Cloud.

Where should secrets live?

On the executor. A placed step references credentials://<id>, and the executor resolves it from ORCH8_CREDENTIAL_<id> or a file in ORCH8_CREDENTIALS_DIR; Cloud stores only the reference. Credential values for steps that are not placed live in Cloud's credential store. Anything you put into workflow context or step params is data Cloud processes, and a placed step's output reaches Cloud unless sealed, so do not echo credentials into outputs.

What happens when an executor goes away?

Its heartbeats stop, the engine's lease reaper reclaims its tasks, marks the attempt unknown, and the step's retry policy schedules it on another executor that satisfies the same placement. If none is connected, the step waits with placement_unsatisfied; it never falls back to Cloud.

Bring your network diagram

Tell us your regions, residency rules, egress policy, and which steps must touch your internal systems. We will reply with the executor layout, the placement policies, and the exact endpoints your firewall needs to allow outbound.

Start Hybrid Embedding in your product instead?