Self-hosted vs Cloud
Self-hosted
Your infrastructure. Your data stays on-premises or in your own cloud account. Full control over networking, storage, and upgrade timing. Requires a team capable of running containerized workloads.
Sourcegraph Cloud
Sourcegraph manages the infrastructure as a single-tenant instance. Automatic upgrades, monitoring, and backups. Requires your code hosts to be reachable from the Sourcegraph-managed environment.
- Your organization’s security policy prohibits code from leaving your network.
- You need to connect to code hosts on a private network that is not accessible from the internet.
- You require control over upgrade scheduling and data residency.
- You have an existing Kubernetes or Docker infrastructure and the operational expertise to manage it.
- You want to get started quickly without managing infrastructure.
- You prefer Sourcegraph to handle upgrades, backups, and monitoring.
- Your code hosts are publicly accessible or reachable from Sourcegraph’s network.
Data residency
In a self-hosted deployment, the following data stays within your infrastructure:- Source code (cloned from your code hosts to Sourcegraph’s gitserver)
- Search indexes (stored on persistent volumes attached to your cluster)
- User data, settings, and audit logs (stored in PostgreSQL databases)
- Batch Changes credentials and changeset data
- Precise code intelligence (SCIP/LSIF) uploads
Deployment types
Sourcegraph supports three primary deployment methods for self-hosted installations:Docker Compose
Single-node deployment using Docker Compose. Best for small to medium teams (up to a few thousand users). Simpler to operate than Kubernetes but less scalable. Runs all Sourcegraph services as Docker containers on one host.
Kubernetes (Helm)
Multi-node deployment using Helm charts on Kubernetes. Recommended for large enterprises. Supports horizontal scaling, high availability, and integrates with managed Kubernetes services (GKE, EKS, AKS).
Machine image deployments (AWS AMI, Google Compute Image) are available but will be sunset in Sourcegraph 7.0.0. If you are considering machine images, contact your account team to discuss Docker Compose or Kubernetes instead.
System requirements
Resource requirements depend on the number of users and repositories you are indexing. Use the resource estimator to calculate requirements for your scale.| Size | Users | Repositories | vCPU | Memory |
|---|---|---|---|---|
| XS | Up to 500 | Up to 5,000 | 8 | 32 GB |
| S | Up to 1,000 | Up to 10,000 | 16 | 64 GB |
| M | Up to 5,000 | Up to 50,000 | 32 | 128 GB |
| L | Up to 10,000 | Up to 100,000 | 48 | 192 GB |
| XL | Up to 20,000 | Up to 250,000 | 96 | 384 GB |
- Docker Compose: Docker v20.10.0 or later, Docker Compose v1.29.0 or later. Docker Swarm mode is not supported.
- Kubernetes/Helm: Kubernetes 1.19 or later, Helm 3 CLI, a CSI storage driver for persistent volumes, and an Ingress Controller.
- ARM / ARM64 architectures are not supported for production deployments.
External services
For production deployments, Sourcegraph can be configured to use external managed services instead of the bundled ones:- PostgreSQL: Use your own PostgreSQL server (version 12 or later). Three databases are required: the main application database, the code intelligence database, and the code insights database.
- Redis: Use external Redis instances for the cache and store services.
- Object storage: Use S3-compatible storage or Google Cloud Storage for precise code intelligence (SCIP/LSIF) uploads.
Licensing
A Sourcegraph Enterprise license is required for instances with more than 10 users. The license key is applied in site configuration:Next steps
Deployment guide
Step-by-step instructions for deploying Sourcegraph with Docker Compose or Kubernetes/Helm, including upgrade procedures.
Site configuration
Configure code host connections, authentication, search settings, and more after your instance is running.