$ trust ./layerssoon

when your customer can't share their data with you.

sometimes a workflow needs data your customer holds — but they'd rather not hand it to you. the orchestrator dispatches nodes directly to whoever owns the data, encrypted with a key only they hold. you get the output, scoped to what they chose to return.

Flowget cloud
orchestrator
  • orchestrates: execution · routing · audit
  • never sees: plaintext
You
your VPC · your nodes
  • holds: key A
  • never sees: your customer's data
Your customer
their VPC · their nodes
  • holds: key B
  • never sees: your nodes · your DB
scenario · onboard a corporate borrower
  1. cloudNew onboarding requestevent fires on the orchestrator
  2. youRun KYC + risk scoringyour nodes · your DB · ciphertext to cloud
  3. customerFetch financial statementsyour customer's nodes · their DB · you can't read it
  4. youCompute final decisionyour nodes combine KYC + signed summary from your customer
  5. youEmail decision to applicantyour worker calls SMTP — result ack to cloud

the trust geometry

you never hold your customer's encryption key.the orchestrator dispatches your customer's nodes directly to their worker — bytes go cloud ↔ customer, encrypted with key Bonly they hold. you get the workflow's output, scoped to what their nodes chose to return.

honest FAQ
the hard questions, answered

No. Your nodes run inside your worker process, in your VPC. The FlowgetSDK invokes the functions you registered — it doesn't see your DB credentials (they live in your code's closures, not in ours) and it doesn't reach out to anywhere except our Temporal cluster, over mutual TLS with your own root CA.

Combined with the payload codec, our cluster only ever handles ciphertext — same encryption boundary as TLS, just one layer deeper.

Picture the actual flow:

[trigger] → [getOrderById] (in customer's worker) → [send_email] (in yours)

You share a key for confidentiality on the wire. Encryption ≠ authorization. Four layers close the enumeration gap — some today, some on the roadmap:

  1. Workflow signature. soon Your customer signs the approved graph; every invocation carries the signed context. Calls outside scope get rejected before the DB.
  2. Node-level scoping (in your code).getOrderById refuses IDs that don't belong to the active session.
  3. Per-call audit log. Every invocation is recorded; soon a burst-detection alarm on unusual patterns.
  4. Kill switch. soon Revoke the key → your access dies instantly.

Two independent backstops:

  1. Signed releases (Sigstore / npm provenance). Every artifact is signed; your CI verifies before install. soon SBOM.
  2. Capability-scoped dispatch.Cloud can't send your worker arbitrary code — only invocations of nodes you registered. No eval, no remote code load.

Two paths, both paid Enterprise tier:

  1. Dedicated cloud. Single-tenant orchestrator on infra you approve (your AWS/GCP/Azure, your region).
  2. On-premise license. soonEngine runs entirely inside your data centre — air-gapped if needed.

With the codec wired: metadata, never content. Which workflow ran, which nodes were invoked, when, how long, success or failure, cost attribution. With the codec on, payloads cross our cluster as ciphertext.

All metadata is per-tenant scoped and retained per your contract. Export or delete on request. soon Self-serve audit-log query/export API.