Self-Hosting Options
Serval supports three delivery models when you run it in your own infrastructure. The two axes that actually differ between them are (1) what you bring — a Linux host, an AWS account, or a Kubernetes cluster — and (2) who operates it — Serval or your team. Pick the model that matches both. This page is the starting point for evaluation; step-by-step deployment instructions are shared with customers during onboarding.Most organizations should start with Hybrid Self-Hosted (smallest footprint, fastest setup). Choose a fully self-hosted model when regulatory, data-residency, or air-gap requirements demand that the entire application runs in your environment.
The three delivery models
Hybrid Self-Hosted
You run only the Serval worker in your infrastructure. Serval operates the backend in Serval Cloud. Integration credentials stay on your worker and are never shared with Serval. Smallest footprint, fastest to set up.
Serval-Managed in Your AWS
The full Serval application runs in an AWS account you own. Serval provisions, upgrades, and operates the layered deployment inside that account through an operator appliance; your AWS credentials never leave your environment.
Self-Managed on Your Kubernetes
The full Serval application runs on a Kubernetes cluster your team operates. You install the public Serval Helm chart from OCI and own day-2 operations. You bring the cluster; you run it.
Comparison
| Hybrid Self-Hosted | Serval-Managed in Your AWS | Self-Managed on Your Kubernetes | |
|---|---|---|---|
| What you bring | A Linux host for the worker | A supported AWS account you own | A Kubernetes cluster (any cloud or on-prem) |
| Who operates it | Serval (backend) + your team (worker host) | Serval, via an operator appliance inside your AWS account | Your team |
| What runs in your environment | Worker only | Full application stack | Full application stack |
| Where app data lives | Serval cloud | Your AWS account | Your cluster |
| Tenancy | Shared control plane, isolated worker | Single-tenant | Single-tenant |
| Upgrades | Automatic | Serval applies them | Your team runs helm upgrade |
| Setup time | Hours | Days (onboarding) | Hours to days |
| Kubernetes expertise required | Basic | Minimal (Serval operates it) | Intermediate to advanced |
Does Serval need to reach private resources?
If Serval needs to talk to systems on your internal network — on-prem Active Directory, internal LDAP, self-hosted GitLab, internal APIs, etc. — the connectivity story differs per model. The Private Network Access page walks through the options for each.Evaluating Serval self-hosting
Use these pages while you decide which model fits:Hybrid Self-Hosted — overview
How Hybrid works, what runs where, prerequisites, and when to pick it over the fully self-hosted options.
Compare the fully self-hosted options
Serval-Managed in Your AWS vs. Self-Managed on Your Kubernetes, side by side.
Architecture
High-level view of the services that run in a fully self-hosted Serval deployment.
Serval-Managed in Your AWS — overview
How the Serval-Managed delivery model works and what your team supplies.
Self-Managed on Your Kubernetes — prerequisites
What your Kubernetes platform must provide before you install the Helm chart.
Private network access
Options for letting Serval reach resources on your internal network (on-prem AD, internal GitLab, etc.).
Ready to deploy?
Detailed installation steps, configuration references, integration setup, and operational runbooks live in a password-protected area of this site, which we share with customers and teams working through onboarding.Deployment instructions
Installation, configuration, integration setup, and day-2 operations for Serval self-hosting.