Identity and deployments

Internal calls use capabilities#

A Durable Object binding, service binding or private dispatch namespace grants access to a resource. Our internal calls do not carry application bearer tokens. This is not “no security”; authorization comes from which code holds which binding.

The executor flow route is not exposed by the example’s public router. queueAuthMode: skip assumes the internal delivery boundary. Do not publish an equivalent route that trusts arbitrary queue payloads.

The example’s run and hook endpoints are public examples. A hook token acts as a capability to resume that hook. Add your application’s authentication, authorization and abuse controls before using the example as a multi-tenant public service.

Encryption has a narrower scope than “all data”#

An optional 32-byte base64 Worker secret enables per-run key derivation using HKDF-SHA256, with workflow-cloudflare|<runId> as context. Core encrypts serialized payloads using the resulting key material.

Operational metadata and raw byte streams remain readable. Do not assume R2 objects or list rows are application-encrypted just because run payload encryption is enabled. Protect access to bindings, buckets and secrets.

There is no supported key-rotation scheme or external derived-key service. Removing or replacing a secret can make old encrypted state unreadable. Keep the key material required by retained runs.

Keep the code that owns old history#

A recorded deployment ID identifies the executor a queued run should reach. With Workers for Platforms enabled, EXECUTOR_ROUTES maps each retained release to its script. Even the current deployment needs an explicit valid route.

The main World owns shared state. Executor releases use those same namespaces and buckets. That means retained code still calls current RPC methods, so method names and argument contracts must remain compatible.

Invocation handling is a special case: hook invocation executes on the current deployment, then wakes the run on its recorded deployment. Do not assume every operation goes straight to the old executor.

How Vercel’s identity differs#

Vercel’s direct Workflow API uses explicit tokens or Function OIDC identity. External callers can use its authenticated API proxy with project/team context. Eligible same-deployment Functions derive a per-run key locally; other callers can retrieve a derived key through the Vercel API.

That is useful for managed project isolation and external tooling. Our binding-based access is simpler inside one configured deployment, but does not provide the same project identity or run-key API.