Demo Systems

The GitLab Demo Systems provide infrastructure for the GitLab Customer Success, Marketing, Sales, and Training teams to demonstrate GitLab features, value propositions, and workflows in a variety of asynchronous and live capacities.

Overview of Demo Systems

The GitLab Demo Systems provide infrastructure for the GitLab Customer Success, Marketing, Sales, and Training teams to demonstrate GitLab features, value propositions, and workflows in a variety of asynchronous and live capacities.

The Demo Systems were originally architected in October 2019. Currently, Logan Stucker, Maria Redmond, Seraphine Young on the Demo Architecture team and Scott Cosentino (GitLab University) have taken over as the primary maintainers of the Demo Systems, including supporting training instructors and students with GitLab Learn Labs.

For questions about demo sample projects, infrastructure, access requests, or help troubleshooting a failed pipeline job, ask in the #demo-architect-partners Slack channel.

For help with the Sandbox Cloud (AWS Accounts and GCP Projects), ask in the #sandbox-cloud-questions Slack channel.

Please consider this handbook documentation to be the single source of truth (“SSOT”) for all resources that use the gitlabdemo.com, gitlabdemo.cloud, and gitlabtraining.cloud domain names.

Why do we have demo systems?

  • Why shouldn’t we just use GitLab.com? Although you can use GitLab.com for showing most of the value of GitLab use cases, there are some administrative features that require the deployment of GitLab Omnibus infrastructure in AWS, GCP, or local VM/container. Many of our enterprise customers opt for self-managed over GitLab.com so we are mindful of “showing the customer what they’ll see in production”.

  • What’s special about our infrastructure? The demo systems infrastructure doesn’t do anything special that a customer or partner company couldn’t do themselves with the appropriate staffing and engineering investment.

  • Are there special engineering or scalability considerations with training classes and workshops? Yes. The GitLab product was designed for users to be doing different activities throughout the day and the smaller reference architectures are not designed for dozens or hundreds of users to click the same button and run the same background jobs or pipeline jobs at the same time. Our users are also ephemeral and have automated garbage collection requirements that are not customary for conventional GitLab product use cases. This requires special scalability considerations, notably with the Container Registry, Sidekiq, and Kubernetes, that we have to accommodate. Here are some of the things we’re looking for with scalability challenges.

    • Autoscaling runners for 500 simultaneous pipelines started in 10 seconds
    • Autoscaling Kubernetes nodes for 500 simultaneous review apps/deployments in 60 seconds
    • Auto DevOps pipelines that consume lots of wasted resources
    • Kubernetes services that are not needed (ex. Postgres database)
    • Intensive test jobs that are not needed during a workshop (ex. Code Quality, Dependency Scanning, etc.)
    • Project export/import queued job fails with 500 simultaneous project imports
    • Features in your project that have known issues with import/export process (ex. wikis)
    • Administrative access for students (alternative use cases)
    • Package registry caching and garbage collection
    • Container registry caching and garbage collection
    • CI images pulling from Docker Hub with rate limits
    • CI image versions that are incompatible or have been upgraded with bug fixes
    • Using CI/CD components in .gitlab-ci.yml without realizing the underlying job load
    • Using custom .gitlab-ci.yml files without comments of the actions being performed
    • Dependency proxy configuration (particularly for npm and maven dependencies)
    • Lack of step-by-step instructions that leads to student misconfigurations and errors

Shared Environments

These shared environments are referred to as the Demo Cloud or Training Cloud. Historically, training users used the Demo Cloud so the names are used interchangeably in some conversations.

The current list of shared instances, what each one is for, and who should request credentials is on the Sandbox Instance Request (internal only) page of the Demo Architect Portal. Keeping the list there means it stays current and is only visible to GitLab team members.

The primary shared Omnibus instance, listed as Sales CS, is available to all team members for creating groups, projects, and sandbox use. It is shared across the whole team, so treat the Admin area as read-only, except for enabling Can create top-level group on your own user as described in Access Shared Omnibus Instances. If you are enrolled in a self-paced training class, follow the invitation code redemption steps instead of requesting instance credentials.

Isolated Environments

  • AWS Account: See the instructions for provisioning your own isolated AWS account with the GitLab Sandbox Cloud.
  • GCP Project: See the instructions for provisioning your own isolated GCP project with the GitLab Sandbox Cloud.
  • AWS Elastic Kubernetes Service (EKS) Cluster: You can use your AWS account to provision an EKS cluster using the Adding EKS clusters GitLab documentation.
  • GCP Google Kubernetes Engine (GKE) Cluster: Ask in the Demo Systems Slack channel with questions about clusters that are in the group-cs GCP project. See the tutorial for configuring GitLab with group-level Kubernetes cluster to add your cluster to your GitLab group.

How to Get Started

Access to the shared environments is requested through the Demo Architect Portal (internal only).

Access Shared Omnibus Instances

These instructions provide you access to one or more of our shared environments (Omnibus self-managed instances).

  1. Visit the Demo Architect Portal (internal only) and click GitLab Team Member Login.
  2. Open the Sandbox Instance Request (internal only) form and select the instance you need. Sales CS is the shared instance for most team members.
  3. Submit the request.
  4. Once your credentials are ready, create a new record in your 1Password vault with them.
  5. Open the instance and sign in with the generated credentials.
  6. Bookmark the instance so you can reach it directly next time.
  7. After signing in, make sure your user can create top-level groups. In the Admin area, go to Overview > Users, select your own user, select Edit, and confirm Can create top-level group is checked. If it is not, check it for your own user only. This is the one intended exception to the read-only guidance for shared instances. Then create a top-level group to store your projects under. To help with namespace consistency and security best practices, please do not create additional top-level groups with custom names. You can create any subgroups or projects you’d like under your group or in your personal namespace.
  8. Each instance is pre-configured with shared GitLab Runners and a Kubernetes cluster. These are for consumption purposes when running CI/CD pipelines and you do not have administrative access to these in the shared environments.
  9. You can ask for help from other peers in the #demo-architect-partners Slack channel.

AWS Account or GCP Project (Sandbox Cloud)

See the Sandbox Realm handbook page for instructions on creating your own AWS account and/or GCP project that you can use for deploying your own infrastructure with the benefit of centralized billing.

Invitation Code Creation

Navigate to the Demo Architect Portal (internal only), sign in as a GitLab team member, and fill out the Content/Lab Request forms based on your needs. Please reach out in the #demo-architect-partners Slack channel with any questions.

Invitation Code Redemption

Warning for GitLab team members: This process uses an existing GitLab.com account so please ensure this is set up beforehand.

  1. Visit the Demo Architect Portal (internal only) and click the Workshop/Lab Redemption button.
  2. Click Sign In With GitLab.
  3. Type in the invitation code that was provided by your instructor or in your course materials.
  4. Press Submit Code.
  5. Click the blue My Group button to open a new tab with the URL of your GitLab group on Learn Labs.

Workshop Preparation

The workshop process has iterated multiple times. The latest version of the workshop preparation process has been simplified into a self-service model.

As the workshop presenter and supporting team member, you are responsible for importing and testing your sample projects and lab guide content. There is no support provided for misconfigured projects, failing pipelines and jobs, or GitLab Runner error messages specific to projects and jobs.

There is no more peer review or approval process other than scheduling coordination with the field marketing team. These instructions provide best practice guidance. If you need assistance, please ask in the #demo-architect-partners Slack channel to get help from other team members that have delivered similar workshops.

Workshop preparation steps will be linked on the resulting issue after completing the request form (internal only).

Workshop lab guide catalog

All of the workshop content that is created officially can be found in the Content Discovery section on the Demo Architect Portal (internal only).

Version Upgrades and Maintenance

We perform version upgrades on the weekend following the monthly release. The weekend upgrades are performed at a random time on Saturday or Sunday based on engineer availability and last for approximately 30 minutes.

We delay the upgrade window for updates that we consider risky or occur during holidays. This occurs during May each year, which aligns with the US Memorial Day holiday, in December around the Christmas Holiday, and in January at the end of the fiscal year when we have a configuration freeze until sales demos are completed.

For patch and security updates, we will usually only perform upgrades for critical updates and will announce maintenance windows in the #demo-systems channel on Slack.

Legacy Version Support

We keep our shared environment up-to-date with the latest versions to help showcase the value that the newest features and solutions offer.

For demo and sandbox use cases requiring an older version, you can deploy a GitLab instance in a container in the Container Sandbox or using Omnibus in the Compute Sandbox. We do not offer any data migration or parity configuration support.

GitLab Duo features

GitLab Duo is enabled for the demo cloud environments. You may assign a seat to yourself and other users in the Admin settings.

Tutorials

Sample Data

Historically, there has not been a consistent set of demo data. Each of our Solutions Architects is responsible for creating their own demo data or forking projects from other team members.

See the handbook page for Demo Readiness and Existing Demonstrations to get started.

Please see the Solutions Architecture Initiatives issue tracker for more information on the crowd sourced OKRs that are in progress and the development of our Communities of Practice.

Projects and Code Repositories

These are the projects that make the Demo Systems possible behind the scenes. You are welcome to study and learn from any of our source code. Each project is classified as Public or Private depending on the security risk of the source code or information contained within.

Demo Systems v2

Demo Systems v1 (Deprecated)

The Demo Systems v1 repositories can be found in gitlab.com/gitlab-com/customer-success/demo-systems.

Help and Support

We use Slack for real-time support and quick fixes. If in doubt of how to get help, ask in #demo-systems. The issue trackers are used for tasks and projects that take longer than 30 minutes. We do not use email for internal team communications.

  • Demo Systems Issue Tracker
  • #demo-systems Slack channel (for Demo Cloud announcements, questions, and technical support with Demo Cloud)
  • #demo-systems-ps-education Slack channel (for ILT/SPT training lab discussions)
  • #demo-systems-workshops Slack channel (for workshop discussions)
  • #sandbox-cloud Slack channel (for Sandbox Cloud announcements)
  • #sandbox-cloud-questions Slack channel (for Sandbox Cloud questions and technical support)
  • demo-systems-admin@gitlab.com (for non-Slack users)
Demo Systems Onboarding
This guide is meant for getting any new hire to the CS Org set up on demo systems and prepared to start demoing the product. The full walkthroughs are maintained in the internal Demo Systems Initial Set Up project.
Demo Systems Tutorials
The GitLab Demo Systems tutorials provide step-by-step instructions for accessing and using our infrastructure and related business processes.
Environments
Infrastructure
Last modified September 4, 2026: Fix grammar and outdated instructions on Demo Systems pages (bf6a7a81)
View page source - Edit this page - please contribute. Creative Commons License