> ## Documentation Index > Fetch the complete documentation index at: https://docs.serval.com/llms.txt > Use this file to discover all available pages before exploring further. # Private Network Access > How Serval reaches systems on your internal network — on-prem Active Directory, internal LDAP, self-hosted GitLab, internal APIs — under each delivery model. # 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](/sections/self-hosting/index) you pick. Pick your delivery model first on [Self-Hosting Options](/sections/self-hosting/index). Private network access is a downstream consideration, but it can tip you toward one model over another if the targets are hard to expose to AWS or to Serval Cloud. ## 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. ## 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 deployment team, 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? ## See also * [Network Security and Firewalls](/sections/administration/network-security-and-firewalls) — egress, firewall, and allowlist configuration for deploying Serval in your organization. *** ## Next steps Pick the delivery model first, then come back here for connectivity. Side-by-side of the two fully self-hosted options.