Skip to main content
Service Bindings let one Rust Worker call another account-owned Rust Worker without exposing a public URL. Use them for internal auth, billing, webhooks, and shared APIs that should not be callable from browsers.

​
Service Binding flow

1

Create the target Service

Create or deploy the private Rust Worker that owns the internal API before adding it to callers.
2

Create the caller binding

Choose a stable uppercase binding name, then bind the caller Service to the target Service.
tovuk binding create --service service_1 AUTH_SERVICE --target auth-service --json
3

Deploy the caller Worker

Deploy the caller Rust Worker after the binding exists so its runtime environment receives the private target Service id.
4

Read the runtime binding

Read TOVUK_BINDING_AUTH_SERVICE from the Rust worker runtime (TOVUK_BINDING_<NAME> for other binding names). Static frontends should not call Service Bindings directly.
5

Verify and cap calls

Run tovuk service show service_1 --json to verify serviceBindings, limits, usage, and next actions. Set Worker caps before high-throughput private calls.

​
CLI workflow

tovuk binding create --service service_1 AUTH_SERVICE --target auth-service --json
tovuk binding delete --service service_1 AUTH_SERVICE --json

​
API

  • POST /v1/services/{service_id}/service-bindings
  • DELETE /v1/services/{service_id}/service-bindings/{binding}
Bindings are injected into the Rust runtime as TOVUK_BINDING_<NAME>=<target_service_id>.

​
Meters and caps

Service Binding calls count as Worker subrequests and Worker invocations. Set caps for worker_requests, worker_cpu_ms, and worker_transfer_bytes. 
tovuk limits set worker_requests --period day --value 100000 --notify-at-percent 80 --json

​
Limits

  • One Service can bind up to 5000 service resources.
  • Service binding call chains can use up to 32 worker invocations per top-level request.
  • Calls must stay private to Rust Workers. Static frontends cannot call Service Bindings directly.
Last modified on June 3, 2026