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 Docker Hub, where the Hybrid worker Helm chart is published. - 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).
Existing Kubernetes clusters
If your platform team already operates Kubernetes workloads, you can usually run the Hybrid worker as a standard workload in that environment instead of provisioning a dedicated VM with k3s. The worker is packaged as a Helm chart, and k3s is the lightweight default path documented for teams that want the smallest single-host installation.The advanced install steps for existing clusters are in the password-protected Hybrid Worker Setup guide. Serval shares that guide during onboarding so your platform team can review the exact Helm values, credentials flow, and network policy settings before deployment.
FAQ
Can we deploy the Hybrid worker into an existing EKS cluster?
Can we deploy the Hybrid worker into an existing EKS cluster?
Yes. If your EKS cluster can reach Serval Cloud and the private systems you want Serval to automate against, the worker can run there as a Helm-managed Kubernetes workload. This is often a good fit for teams that already have AWS networking, cluster security, image-pull controls, and upgrade processes in place.
Is k3s required?
Is k3s required?
No. k3s is the default documented path for a simple dedicated Linux host because it provides a small Kubernetes runtime with minimal setup. The worker itself is deployed with Helm and does not require k3s specifically.
Is a non-k3s cluster such as EKS supported?
Is a non-k3s cluster such as EKS supported?
Yes, for standard Kubernetes clusters that meet the worker’s requirements. During onboarding, Serval will confirm the target cluster, Kubernetes version, outbound egress, Docker Hub access, namespace/RBAC model, and any cloud-specific settings such as AWS IAM Roles for Service Accounts (IRSA).
What should we consider in a shared cluster model?
What should we consider in a shared cluster model?
Where is the advanced existing-cluster guidance?
Where is the advanced existing-cluster guidance?
Customers with access can start with Hybrid Worker Setup. That guide covers the pre-flight checks, generated install command, Helm deployment, optional flags, verification, upgrades, and troubleshooting. If you are evaluating Hybrid, request access through Deployment instructions and mention that you want to deploy into an existing EKS or Kubernetes cluster.
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.