Self-Hosting Cody in a Private GitHub Enterprise Environment

The default Cody service routes code through third-party LLM providers, and that routing is incompatible with how regulated enterprises running private GitHub Enterprise instances are required to handle their source code. Finance, healthcare, and defense organizations operate under compliance regimes, SOC 2 Type II and ISO 27001:2022 among them, that rule out any configuration in which proprietary code crosses outside a controlled boundary. A private GHE instance exists to enforce that boundary, so Cody's self-hosted deployment option is built to respect it, not work around it. Sourcegraph's own Cody Enterprise announcement names zero data retention, no training on customer data, and self-hosted deployment as the baseline for security-conscious environments, which settles the self-hosted path as the intended answer for this kind of deployment, not a fallback for teams unwilling to use the managed service. Getting from "Cody works with GitHub Enterprise" to a correctly deployed instance requires a sequence of infrastructure decisions, each carrying its own security consequence if skipped or rushed: sizing the Sourcegraph instance, connecting it to GHE, filtering what context Cody can see, routing model inference through a private endpoint, governing user access, and auditing egress. The rest of this guide walks through each of those layers in the order a deploying team actually encounters them.

Sizing and provisioning the Sourcegraph instance before connecting anything

Before any integration work begins, the Sourcegraph instance itself has to exist, and it has to be sized correctly for the organization running it. Under-provisioning at this stage does not cause problems immediately visible during setup. It cascades later into indexing failures and degraded context retrieval that are far harder to diagnose once GHE connections, context filters, and an LLM endpoint are already layered on top. Official system requirements scale across tiers from XS to XL, and the sizing decision should start with a straightforward mapping of user count and repository count to the appropriate tier, done before any connection work starts.

At this stage, the deployment model itself gets decided: self-hosted versus Sourcegraph-managed single-tenant cloud. The self-hosted option places the instance inside the organization's own data centers or VPC, and that placement is the precondition for keeping every subsequent data flow, from GHE indexing to Cody's model calls, inside the controlled boundary described above. If an organization operates under strict data-residency requirements, self-hosted is the option that actually satisfies the constraint. Sourcegraph supports this model so Cody Enterprise can live alongside self-hosted code hosts inside an organization's own infrastructure, so this is the standard path for private GHE environments, not an edge case that needs special handling. The Sourcegraph instance provisioned here becomes the platform both the GHE connection and the Cody LLM layer will be built on top of in the steps that follow.

Connecting Sourcegraph to a private GitHub Enterprise instance

Once the instance is sized and running, the next step is establishing an authenticated connection to the private GHE instance, and this is where repository indexing becomes possible for the first time. How that connection is authenticated sets the security posture for every piece of code intelligence Cody will later draw on. Cody Enterprise is built to connect to all major code hosts, including GitHub, GitLab, Bitbucket, Gerrit, Perforce, and Azure DevOps, and it supports multiple code hosts at once, so the GHE connection follows the same established pattern used across any other enterprise code host integration.

The detail that matters most here is where the connection actually points: the configuration needs to reach the private GHE instance's internal hostname or IP, not a public GitHub endpoint. This is the step where network routing inside the VPC or data center has to be correct, since a misrouted connection either fails outright or, worse, succeeds against the wrong target. Once the connection is live, Sourcegraph begins indexing repositories, and the scope of that indexing, which repositories and which branches, is a decision the team should make deliberately rather than accept as a default that indexes everything in sight.

This architecture is not unproven at scale. Qualtrics, a global Experience Management company with a large software engineering workforce, ran its own GitLab instance inside its own data centers, and Sourcegraph worked there without friction, an architecture directly comparable to a large private GHE deployment. That kind of outcome is part of why Sourcegraph, by its own reporting, now helps more than 2.5 million developers search, fix, and understand code. Self-hosted code host paired with self-hosted Sourcegraph is a validated combination, not a novel one being tested for the first time in a regulated environment.

Configuring Context Filters to control which repositories Cody can see

With Sourcegraph indexing from GHE, the next decision is not how much context Cody should have access to but which repositories, specifically, belong in that context. Leaving this configuration at its defaults after connecting to GHE means Cody can draw on whatever got indexed, including repositories holding auth services, payment processing logic, or internal tooling the organization never intended to expose to model inference.

Context Filters give teams per-repository control over that exposure. A repository can stay indexed in Sourcegraph for search purposes while being excluded from what Cody retrieves for model context, so the organization decides what the model sees instead of letting the model's reach be defined by whatever got connected. That distinction sets Context Filters apart from the org-wide privacy toggles some other tools offer: instead of an all-or-nothing switch, a team can apply Cody broadly across application-layer repositories while keeping repositories that handle cryptographic key management, compliance audit logs, or regulated PII out of the model's awareness. A deployment can grant Cody wide reach across the codebase a team actually works in daily while walling off the handful of repositories that carry disproportionate risk if exposed.

This configuration belongs in the deployment phase itself, not on a list of things to clean up after launch. A gap here means sensitive code is potentially present in LLM context from the first day Cody goes live, and closing that gap retroactively is a much harder problem than setting it correctly before anyone starts using the tool.

Enabling Cody on the Sourcegraph instance and configuring the LLM endpoint

With the code host connected and context boundaries set, the next step is turning Cody on and deciding what model it talks to, and this is where the deployment's data boundary either holds or breaks. Cody is enabled by setting "cody.enabled": true in the Site admin > Site configuration panel, an activation step that comes after the infrastructure and context decisions above, not before them.

The LLM provider itself is configured by the admin at the enterprise level. Individual users do not bring their own model keys, so the platform, not each developer's preference, decides which model is used. If you want a deployment that stays fully private, you point the LLM endpoint at a model running inside the organization's own VPC, using the bring-your-own-model-endpoint configuration that routes inference traffic to a private deployment of Claude or another supported model. Cody Enterprise supports this kind of LLM choice specifically to avoid vendor lock-in, including support for DeepSeek V2 for code completions, and the platform is built around the premise that a better model may ship tomorrow and the deployment should be able to adopt it without a full reconfiguration.

Teams unable to self-host an LLM can configure Cody with a bring-your-own-key arrangement against an external provider, but that choice reintroduces the external egress the self-hosted architecture was built to avoid. For regulated environments, the private VPC endpoint is the configuration that actually closes the boundary.

Managing user access and roles after Cody is live

With Cody active and the model endpoint configured, the remaining question is who inside the organization gets to use it. A deployment left without deliberate access control defaults to broad access for every user, which may not match the organization's actual intent to restrict AI assistance to specific teams or codebases.

Admins manage this through Site admin > Users & Auth > Roles, where Cody access can be turned on by default for all users or scoped into role-based subgroups with selective access. Because this model is admin-controlled, access becomes a platform governance decision: contractors, vendor teams, or users subject to elevated data-handling restrictions can be excluded from Cody specifically, without touching their underlying Sourcegraph access. Role-based access also supports a staged rollout, starting with a pilot group before expanding more broadly, which is standard practice for enterprise AI tool deployments where audit log review is part of the governance process. Audit logging, available at the Enterprise tier, should be confirmed as active at this stage, both to satisfy compliance requirements and to establish a baseline of usage patterns before the rollout widens.

The hidden egress problem: what still phones home in an otherwise private deployment

A deployment can get the GHE connection, the context filters, and the private LLM endpoint all correctly configured and still have outbound network calls that quietly violate the data boundary the rest of the setup was built to enforce. Certain Sourcegraph or Cody functions may attempt to reach external endpoints by default, independent of how carefully the rest of the configuration was done.

Telemetry, update checks, and license validation are common sources of this kind of unintended egress in self-hosted enterprise software. In an air-gapped or tightly controlled network, those calls either fail silently or succeed in ways the security team never accounted for. Teams deploying in genuinely air-gapped environments with no outbound internet access need to audit which endpoints the Sourcegraph instance attempts to reach and explicitly disable or reroute each one.

The highest-stakes point of exposure is the LLM endpoint configuration itself. If a fallback or default endpoint is configured alongside the private one, code context could be sent externally under failure conditions, precisely the outcome the private VPC deployment was meant to prevent. Configuration settings alone are not a sufficient safeguard here. Egress firewall rules that block all outbound traffic except to explicitly allowed internal endpoints serve as the reliable backstop, since they enforce the boundary at the network layer independent of whatever the application layer is set to do. This is a solvable problem with deliberate network controls. It only gets solved if someone goes looking for it, since a well-configured deployment can still carry this gap silently until it's audited.

Anatomy of a complete private GHE deployment

A correctly deployed self-hosted Cody instance in a private GHE environment is not the product of one configuration step but the sum of several independently verified layers, each addressing a distinct risk. The Sourcegraph instance is provisioned to the right size tier and deployed inside the organization's own infrastructure boundary. The GHE connection is authenticated with appropriately scoped credentials and indexes only the repositories the team has deliberately chosen to include. Context Filters exclude sensitive repositories from model inference, with that exclusion list reviewed and owned by a named team. Cody is enabled with a private LLM endpoint configured, routing all inference traffic within the VPC, with no external model API keys present anywhere in the configuration. User access is governed by role-based controls in Site admin, with audit logging active from day one. Egress is verified at the network layer, not just at the configuration layer, with firewall rules enforcing the data boundary independent of whatever the application settings claim.

Cody Enterprise carries SOC 2 Type II certification, ISO 27001:2022 certification, zero data retention, and a no-training policy on customer data. Those certifications describe the platform. They do not, on their own, describe a specific deployment. A given organization's private GHE environment only inherits the protection those certifications represent if each layer covered here, sizing, connection, context filtering, model routing, access control, and egress verification, has actually been configured and checked. The platform makes the guarantee possible. The deploying team makes it real.