Hybrid Self-Hosted
In the Hybrid delivery model, you run only the Serval worker inside your own infrastructure. Serval operates the rest of the platform — the backend application services, the control plane, the web app, and the application database — in Serval Cloud. Your worker is the only Serval component that ever touches your internal network or handles your integration credentials.This is usually the right starting point. Hybrid has the smallest footprint, the fastest setup, and still gives you (a) integration-credential isolation and (b) the ability for Serval to automate against resources on your private network.
Why teams pick Hybrid
- Smallest footprint of the three self-hosting options.
- Fastest to stand up — usually hours, not days.
- Integration credentials (OAuth secrets, API keys, service-account JSONs for your internal tools) live on the worker host and are never shared with Serval.
- Reach private systems — the worker can talk to on-prem Active Directory, self-hosted GitLab, internal APIs, and internal databases without opening them to the public internet. See Private Network Access.
- Minimal ops burden — Serval owns operations for the backend and control plane. Your team only owns the worker host.
What runs where
| Component | Where it runs | Who operates it |
|---|---|---|
| Serval worker | A Linux host you provide | You (host and OS); Serval (the worker process itself, via auto-update) |
| Backend application services | Serval Cloud | Serval |
| Web application | Serval Cloud | Serval |
| Application database (users, workflows, tickets, knowledge base) | Serval Cloud | Serval |
| Integration credentials | Your worker host | You |
Where your data lives
- Application data — users, tickets, workflow definitions, knowledge base content — lives in Serval Cloud. If you need application data in your own environment, pick Serval-Managed in Your AWS or Self-Managed on Your Kubernetes instead.
- Integration credentials live on the worker host. Serval’s backend sends the worker a signed request describing “make this API call to this integration”; the worker substitutes the credential at call time and returns the result. The credential itself never leaves the worker.
- Payloads returned from integration calls — for example, a user record read from your internal API — flow back through the worker to the Serval Cloud backend. If those payloads must also stay inside your network, pick a fully self-hosted model.
Prerequisites
- A Linux host you control (x86_64). A VM or container host is fine; bare metal is fine.
- 2 CPU cores, 4 GB RAM, 10 GB free disk at minimum.
- Outbound HTTPS from the worker host to the Serval Cloud control plane (
public.api.serval.com) and to the Serval image registry (public.ecr.aws). - Network access from the worker host to every internal system you want Serval to reach — AD, internal GitLab, internal APIs, internal databases. See Private Network Access for specifics.
- Ability to run an install command on the host (the exact commands are in our password-protected deployment docs).
When to choose Hybrid vs. the fully self-hosted options
| You care most about… | Pick… |
|---|---|
| Smallest setup and fastest time-to-value | Hybrid |
| Keeping integration credentials out of Serval Cloud | Hybrid (also true for both fully self-hosted options) |
| Serval automating against resources on your private network | Hybrid (also possible with either fully self-hosted option) |
| Keeping all application data — users, tickets, knowledge — in your own environment | Serval-Managed in Your AWS or Self-Managed on Your Kubernetes |
| Not running anything in your own infrastructure | Serval Cloud (not self-hosted) |
Next steps
Compare all three models
See Hybrid side-by-side with the two fully self-hosted options.
Private network access
How the worker reaches resources on your internal network.
Deployment instructions
Worker install, configuration, and operations — shared with customers during onboarding.
Talk to Sales
Start a Hybrid deployment.