This document provides technical details about Sourcegraph Managed Services Platform (MSP) and how it works.

To get started, please learn about MSP and its use cases at Sourcegraph in the Sourcegraph Managed Services Platform (MSP) page.

A technical deep dive video recording is also available from ‣ which goes over some of the contents of this page.

Service specifications

Each MSP service (i.e. services listed in Managed Services infrastructure) is defined in a service.yaml file in the sourcegraph/managed-services repository. This YAML specification is defined in dev/managedservicesplatform/spec and is used to define what resources are available to a service, such as the external domain, databases, and so on.

Each service specification specifies one or more environments. A simplified specification might look like:

service:
  id: msp-testbed
  name: MSP Testbed
  description: Testbed service for experimenting with MSP functionality
  owners: [core-services]

build:
  image: us.gcr.io/sourcegraph-dev/msp-example
  source:
    repo: github.com/sourcegraph/sourcegraph
    dir: cmd/msp-example

# Deploy new image versions first to 'dev', then to 'prod'    
rollout:
  stages:
    - environment: dev
    - environment: prod

# Specify environments to provision for this service - see 'Service environments'
environments:
- id: prod
  category: internal # See 'Environment categories'
  deploy:
    type: rollout
  domain:
    type: cloudflare
    cloudflare:
      subdomain: msp-testbed
      zone: sgdev.org
      proxied: true
  env:
    SRC_LOG_LEVEL: info
    VARIABLE: "foobar"
  instances:
    resources:
      cpu: 1
      memory: 1Gi
    scaling:
      maxCount: 1
      minCount: 1
  resources:
    postgreSQL:
      databases:
        - "primary"
    bigQueryDataset:
      datasetID: "msp_testbed"
      tables:
        - "example"
    redis:
      highAvailability: true
- id: dev
  # ...

Service environments

Each service specification will define one or more service environments, which are effectively replicas of a service. Services will often have a “development” (dev) and a “production” (prod) environment, though this is up to the service owner.

Each environment can currently declare a primary GCP region to use for the resources deployed within it.

Environment categories

Each environment is assigned a category by the service operator - one of test, internal, or external. The category is used to communicate some important traits:

1. The expected stability of the environment (see Environment categories for more details):
   • external: externally-facing environments, often used directly by customers or single-tenant Sourcegraph instances. Availability of these services are held to a very high bar, and issues with these environments are of high priority.
   • internal: internally-facing environments, typically used to support company processes or serve internal use cases. Availability of these environments are important, but downtime will not critically affect the business or be noticed by customers to the same degree as external services.
   • test: testing and development services, usually not dealing with production or customer data. Availability of these environments is only on a best-effort basis, and access is granted liberally.
2. The expected security requirements of an environment:
   • external: only read access to metrics, traces, and rollouts is granted by default to all engineers
   • internal: read-only access to most components are granted liberally to all engineers
   • test: access is granted liberally to all engineers

Elevated infrastructure access to each environment can be requested through Entitle - refer to the generated per-service guidance in Managed Services infrastructure for more details.

Additional reliability details are outlined in MSP platform availability.

Instance scaling