Hybrid Self-Hosted
In the Hybrid delivery model, you run the Serval worker and its credential proxy inside your own infrastructure. Serval operates the backend application services, control plane, web app, and application database in Serval Cloud. Workflows routed to your hybrid worker execute there, and its proxy can reach resources on your private network.Why teams pick Hybrid
- Smallest footprint of the self-hosting options.
- Fastest to stand up: Usually hours, not days.
- Local integration credentials: Configure selected connections with worker-local credentials mounted in your cluster instead of storing the real secrets in Serval Cloud. Connections you do not configure this way are stored encrypted in Serval Cloud, exactly as in the standard SaaS deployment.
- 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 owns the worker host.
What runs where
Serval Cloud orchestrates runs and stores workflow definitions and run history. Run on self-hosted workers routes workflows using that integration to your worker; other workflows continue to run on Serval-managed workers. See the workflow and credential flow diagram.
Where your data lives
- Application data: Users, tickets, workflow definitions, run history, and knowledge base content live in Serval Cloud. If you need application data in your own environment, pick BYOC on AWS instead.
- Integration credentials: Credentials entered in the Serval dashboard are stored encrypted in Serval Cloud. For a connection set to run on the worker, the worker’s proxy fetches the credential from Serval Cloud at call time, injects it into the request, and sends that request to the target service from inside your network, so the target system is never exposed to the internet. For a locally configured connection, the proxy loads the mounted credential instead and Serval Cloud holds only a placeholder. In both cases the credential reaches the target service, such as Okta, and never reaches workflow code. Worker-local credentials support API keys, OAuth client credentials, and custom auth data; they do not support user-authorized (three-legged) OAuth, and they apply only to workflow and ingestion runs the worker executes, not to features Serval Cloud calls directly, such as ticket channels and ticket sync.
- Payloads returned from integration calls: Responses return to the workflow running on your worker. Run results and application data can flow back to Serval Cloud. If those payloads must also stay inside your network, pick BYOC on AWS.
Prerequisites
- A dedicated, always-on Linux host you control (x86_64). A VM or container host is fine; bare metal is fine.
- Recommended: 4 vCPU, 16 GB RAM, 40 GB free disk. Minimum: 2 vCPU, 8 GB RAM, 20 GB free disk.
- A dedicated-CPU instance. Avoid burstable/credit-based types, which throttle CPU under sustained load and can make the worker slow or unreliable.
- 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).
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.