Choose a Delivery Model
If you want to run the full Serval application inside your own infrastructure, you have two delivery models. They differ on two axes that matter for qualification: what you bring (an AWS account vs. a Kubernetes cluster) and who operates it (Serval vs. your team).- Serval-Managed in Your AWS — you provide an AWS account you own and complete a lightweight bootstrap step. Serval then provisions and operates the deployment inside that account via an operator appliance, without holding persistent IAM access to your AWS. Lower operational burden for your team.
- Self-Managed on Your Kubernetes — you provide a Kubernetes cluster (any cloud or on-prem) and your team installs the public Serval Helm chart directly, owning installs, upgrades, and day-2 operations. Highest operational burden — intended for strictly air-gapped, non-AWS, on-prem, or platform-team-mandated environments.
This page compares the two fully self-hosted delivery models. If you are still deciding between Hybrid and fully self-hosted, start at Self-Hosting Options.
Regardless of which delivery model you choose, fully self-hosted deployments must provision their own OAuth apps (Slack, Microsoft, GitHub, Google Workspace, etc.) with each integration provider. See Integrations Overview for the full list and per-app setup guides.
Serval-Managed in Your AWS
Recommended for most organizations that want the full application in their own cloud without owning day-to-day platform operations. You bring the AWS account; Serval operates it remotely through an appliance provisioned there during onboarding.
Self-Managed on Your Kubernetes
For strictly air-gapped, non-AWS, on-prem, or platform-team-mandated environments. Highest operational burden — your team owns the cluster, datastores, ingress, monitoring, backups, upgrades, and on-call in addition to running Serval.
Side-by-side comparison
| Serval-Managed in Your AWS | Self-Managed on Your Kubernetes | |
|---|---|---|
| What you bring | A supported AWS account you own | A Kubernetes cluster (any cloud or on-prem) |
| Who provisions the platform | Serval, via an operator appliance inside your AWS account | Your team |
| Who runs installs and upgrades | Serval | Your team (helm upgrade) |
| Who owns Kubernetes operations | Serval | Your team |
| Who owns monitoring and on-call | Serval manages the baseline operational workflow | Your team |
| Tenancy | Single-tenant in your environment | Single-tenant in your environment |
| Cloud flexibility | AWS only | Any cloud or on-prem |
| Operational burden on your team | Low — Serval handles platform ops | High — your team owns all platform ops |
| Best fit | Most fully self-hosted customers | Strictly air-gapped, non-AWS, on-prem, or platform-team-mandated only |
| Primary prerequisite | Supported AWS account + bootstrap step | Existing Kubernetes cluster + Helm + a platform team to operate it |
Next steps
Serval-Managed in Your AWS — overview
Review how Serval operates the deployment inside your AWS account.
Self-Managed on Your Kubernetes — prerequisites
Prepare your Kubernetes platform before installing the Helm chart.
Private network access
Options for letting Serval reach resources on your internal network.