$ 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 control plane on a pinned cert.

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 stop enumeration:

  1. Workflow signature. Your customer signs the approved graph; every invocation carries the signed context. Calls outside scope get rejected before the DB.
  2. Node-level scoping.getOrderById refuses IDs that don't belong to the active session.
  3. Per-call audit log. Burst of unusual invocations → alarm.
  4. Kill switch. Revoke the key → your access dies instantly.

Two independent backstops:

  1. SBOM + signed releases. Sigstore signature on every artifact; your CI verifies before install.
  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, your KMS).
  2. On-premise license. soonEngine runs entirely inside your data centre — air-gapped if needed.

Metadata, never content. Which workflow ran, which nodes were invoked, when, how long, success or failure, cost attribution. Payloads cross our cluster as ciphertext.

All metadata is per-tenant scoped and retained per your contract. Query, export, or delete your audit log on demand.