​

Private Network Access

Many Serval deployments need to talk to systems that only live inside a customer’s private network: on-prem Active Directory, internal LDAP, self-hosted GitLab or Bitbucket Server, internal HR or ticketing APIs, internal databases for lookups, and so on. The path Serval takes to reach those systems depends on which self-hosting delivery model you pick.

​

Hybrid Self-Hosted

Easiest for most private integrations. The Serval worker runs on a Linux host you provide, inside your network. It reaches private resources using normal internal networking — whatever DNS, VPN, Direct Connect, ExpressRoute, or MPLS your infrastructure already uses.

• Install the worker on a host that can resolve and reach your private targets.
• Credentials for the private service live on the worker and never leave your network.
• If the worker host already sits on the same network as the target (for example, inside your corporate VPN CIDR, or in an AD-joined subnet), there is usually no extra networking to do.

Common pattern: put the worker on an internal VM that’s already trusted by your internal systems, and Serval integrations “just work” against those systems.

​

Serval-Managed in Your AWS

The Serval application runs inside an AWS account you own, so connectivity from Serval to your private networks is a standard AWS networking problem — the same one you solve for any workload running in that account. Common patterns:

• AWS Site-to-Site VPN between the Serval VPC and your on-prem network.
• AWS Direct Connect for dedicated, high-throughput circuits.
• VPC peering or Transit Gateway to a hub VPC that already has on-prem connectivity.
• Route 53 private hosted zones or a DNS forwarder for resolving internal hostnames (for example, your AD domain).
• Security group + NACL changes to allow the Serval subnets to reach specific target IPs/ports.

Onboarding decision points:

• Which VPC/subnets should the Serval stack deploy into?
• Which of the connectivity patterns above already exists and which needs to be stood up?
• Does on-prem DNS need to resolve from the Serval VPC?

Work these out with Serval during onboarding; we deploy into the VPC and subnets you specify.

​

Self-Managed on Your Kubernetes

Serval runs on your cluster and inherits its networking. If your cluster already has connectivity to your private networks (VPN, Direct Connect, ExpressRoute, MPLS, on-prem cluster on the corporate LAN, etc.), Serval picks it up for free. Typical setup tasks:

• Point Serval services at private DNS names or internal endpoints the way you would any other in-cluster workload.
• Ensure your cluster’s egress — NAT gateway, service mesh, egress proxy, or direct VPC routing — allows traffic to the target hosts and ports.
• Mount or project any private CA bundles Serval needs to trust (for example, an internal PKI used by AD LDAPS).
• Provision credentials (LDAP bind account, GitLab token, etc.) as Kubernetes secrets referenced by the Serval chart.

This is usually the most flexible option when targets live on-prem and you already run Kubernetes with on-prem connectivity.

​

Common private targets

In customer environments we regularly wire up:

• On-prem Active Directory / LDAP — identity, group sync, user lookups
• Self-hosted GitLab or Bitbucket Server — code and workflow automation
• Internal service APIs behind a corporate firewall — custom automations
• Internal PostgreSQL/MySQL — data lookups and enrichment
• SCIM endpoints on private networks — user provisioning

​

Questions to answer before onboarding

When you talk to your Serval solutions engineer, have rough answers ready to:

• Which private targets does Serval need to reach, and at what hostnames/ports?
• DNS — does Serval need to resolve internal hostnames? Which zones?
• Auth — does the target use Kerberos, LDAP+TLS, mTLS, a private PKI, or just TLS with a public CA?
• Throughput and latency — are these interactive lookups, bulk syncs, or streaming?
• Change control — who owns the VPN/Direct Connect/firewall changes on your side?

---

​

Next steps