Sourcegraph deployment methods and products

Self-hosted

The majority of Sourcegraph’s paying users currently deploy Sourcegraph within their own infrastructure. This may be referred to as “on-prem”, “self-hosted”, or “in the customer’s cloud”. The main takeaway there is that unlike a traditional SaaS product, the software is not on infrastructure that Sourcegraph controls for those customers. This means:

• We cannot force updates (so customers may be running older releases). Our update process can be time-consuming (an hour or two), and users have to go sequentially (from 3.36->3.37->3.38, not 3.36->3.38), so this can limit what new functionality is available if the customer doesn’t stay on top of this. See our update documentation.
• We have limited insight into what’s on the instance (we can’t see exactly what the customer is doing, only aggregate ping info
• A customer or prospect may have multiple employees running instances on their own laptops to test

Customers can host Sourcegraph on any cloud provider or in their own data centers—it is useful to ask whether they use their own data center or a cloud provider, and if so which—this is just because we have setup instructions for specific cloud providers that can make things a little easier. (You can install Sourcegraph without them, but it can be nice to know exactly which buttons to click in the AWS console, etc.)

Managed instances

Our second-largest collection of Enterprise users use our Managed Instances product. This is exactly like a self-hosted Sourcegraph instance except that it’s hosted on servers the Sourcegraph team controls, not on the customer’s infrastructure. (This is managed by the Delivery team.) Any time you see customername.sourcegraph.com, that’s a managed instance.

Managed instances are single-tenant—that means unlike a traditional midmarket SaaS product, each customers has its own version of Sourcegraph, completely isolated from all the other managed instances. Customers still benefit from the security of that isolation, and gain the benefit of not having to manage infrastructure or upgrades themselves. The tradeoff is that the customer has to be okay with having Sourcegraph have control of copies of their source code (as we do control the servers). (That concern is similar to the concern you’d see with SaaS in general.)

Manage instances are upgraded once a month by Delivery; this is included in the managed instance hosting fee, which covers what we pay to host the instance as well as our developer time spent managing the instance. Your CE will determine the managed instance fee.

All managed instances are Docker Compose instances, which means there is a limit to the size of the customer which we can support on a managed instance. (Docker compose means you have to run everything on a single server, not multiple servers strung together—so the biggest instance you can support is determined by the biggest server that Google sells.)

If you have a customer who is interested in a managed instance, confer with your assigned CE. They will lead discovery. But initial signs that someone might be a good fit for managed instances:

• Mid-sized enterprise (think a software company with 500 devs, not a bank with 20,000)
• They use the cloud version of their code host (github.com versus hosting it in their own infrastructure—this means they’re already okay with source code outside their own servers)
• They ask if we offer something like this, or if we offer a cloud option

You can always ask if the customer tends to prefer cloud deployments or self-hosted deployments for other dev tools—that usually provides enough info for your CE to begin their work.

Cloud/dotcom

This is a more traditional SaaS product (free signup, multi-tenant, in Sourcegraph-controlled infrastructure). This is https://www.sourcegraph.com. Some features (Insights, Batch Changes) are not available there. Enterprise customers, other than small enterprises covered by the Commercial team, are not going to be candidates for Cloud except to use it to test overall functionality against public code.

Single container

This is the kind of Sourcegraph that will be installed if you follow our Quick start guide. It is not officially supported as a production install method. This is only for quickly installing on your laptop to check things out, but isn’t officially supported for a real production instance.

Docker compose

This is the install method our managed instances use. It can handle small to medium enterprises—above a certain size, customers are going to want the benefits of an install method like Kubernetes. If a customer isn’t too big and isn’t familiar with Kubernetes, you’ll likely see your CE push the customer towards this method. (It’s generally quick to spin up.)

Kubernetes

Kubernetes, or k8s, is a container orchestration platform. If a customer is very large, they will likely need to use Kubernetes for their install, because they can scale their instance up significantly in k8s, which they need to do to support large-scale search needs. We typically only recommend using k8s if the customer has experience with it, so if a customer is asking about k8s, it’s helpful to ask them if they have experience deploying k8s apps in their infrastructure, and what team typically manages that process. This will be useful info to coordinate a proof of concept, and will help your CE talk to the right people. Beyond that high-level info, you’ll be bringing in your CE to answer questions.