End-to-end flows between Serval and Customer applications
The diagram below highlights system boundaries, data transmission paths, and key security controls within Serval. Hover over a component to isolate its flows, or over a line to trace it. Customer applications are provided as examples only — Serval can be connected with as many or as few external applications as needed.System boundaries, data transmission paths, and security controls within Serval
Hybrid self-hosted deployments
In a Hybrid Self-Hosted deployment the Credential Proxy runs alongside the Serval worker inside your own infrastructure. Integration credentials are stored encrypted in Serval Cloud by default; the proxy fetches them at call time, injects them into the outgoing request, and sends that request to the target service from inside your network. Workflow code never sees them. A connection configured with worker-local credentials instead reads its credential from a Kubernetes Secret in your cluster, and Serval Cloud holds only a placeholder. The worker opens an outbound HTTPS connection to Serval Cloud; the workflow engine sends it signed integration requests and the result flows back. Everything else — the web app, the workflow engine, inbound webhooks, and application storage — stays in Serval Cloud.Hybrid self-hosted: the Credential Proxy runs on your worker; worker-local credentials are optional