Fix grammar and outdated instructions on Demo Systems pages

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](https://gitlab.com/lfstucker) & [Seraphine Young](https://gitlab.com/seraphiney) on the ([Demo Architecture](/handbook/solutions-architects/center-of-excellence/demo-architecture/)) team and [Scott Cosentino](https://gitlab.com/scottcosentinogitlab) ([GitLab University](https://university.gitlab.com)) have taken over as the primary maintainers of the Demo Systems, including supporting training instructors and students with [GitLab Learn Labs](https://gitlab.com/gitlab-learn-labs).

The Demo Systems were originally architected in October 2019. Currently, [Logan Stucker](https://gitlab.com/lfstucker), [Maria Redmond](https://gitlab.com/mredmond), [Seraphine Young](https://gitlab.com/seraphiney) on the [Demo Architecture](/handbook/solutions-architects/center-of-excellence/demo-architecture/) team and [Scott Cosentino](https://gitlab.com/scottcosentinogitlab) ([GitLab University](https://university.gitlab.com)) have taken over as the primary maintainers of the Demo Systems, including supporting training instructors and students with [GitLab Learn Labs](https://gitlab.com/gitlab-learn-labs).

For questions about what demo sample projects are available or peer assistance with troubleshooting your failed pipeline job, please ask in the `#demo-architect-partners` Slack channel.

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

Please tag `@Logan Stucker` in one of the following Slack channels with any questions or requests related to infrastructure or access requests.

- `#demo-systems` is for SA, CSM, and PSE team members with questions or needing technical assistance. No longer for training/workshop related posts.

- `#demo-architect-partners` is for workshop-related discussions.

- `#demo-systems-ps-education` is for ILT/SPT/etc related discussions for Professional Services.

- `#sandbox-cloud-questions` is for help and support with the [Sandbox Cloud](/handbook/company/infrastructure-standards/realms/sandbox/) (AWS Accounts and GCP Projects).

For help with the [Sandbox Cloud](/handbook/company/infrastructure-standards/realms/sandbox/) (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.

- **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 running 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 for. Here's some of the things we're looking for with scalability challenges.

- **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 workshop (ex. Code Quality, Dependency Scanning, etc.)

  - 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)

  - 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 templates in `.gitlab-ci.yml` without realizing the underlying job load.

  - 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 interchangably in some conversations.

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.

{{% panel header="**Demo Systems v1 Deprecation**" header-bg="warning" %}}

The <code>gitlab-core.us.gitlabdemo.cloud</code> instance was deprecated on 2021-04-20 and destroyed on 2021-06-03. No data back up is available. See <a href="#access-shared-omnibus-instances">Access Shared Omnibus Instances</a> instructions for accessing the <code>cs.gitlabdemo.cloud</code> instance (direct replacement).

{{% /panel %}}

The current list of shared instances, what each one is for, and who should request credentials is on the [Sandbox Instance Request](https://cloud.gitlabdap.com/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.

- `cs.gitlabdemo.cloud` - This is the primary GitLab Omnibus instance that all team members have access to for creating groups, projects, and sandbox purposes on a self-managed Omnibus instance. Please keep in mind that this is a shared environment across all team members and you should treat the Admin areas as read-only.

- `cs-gitlabamazonq.com` - This is used for enablement and demos focused on Amazon Q

- `gitlab-amazonq.com` - This is used as a public facing Amazon Q Instance

- `ilt.gitlabtraining.cloud` - This is used for instructor-led training classes. You should generate credentials for this instance if you are an instructor and need admin access to be able to import sample projects and/or see the groups for all of the students in a class.

- `spt.gitlabtraining.cloud` - This is used for self-paced training classes that are published in EdCast. You should only generate credentials for this instance if you are involved with instructional design or certification grading of self-paced student courses. If you are enrolled in a self-paced training class, you should follow the instructions for [redeeming an invitation code](#invitation-code-redemption) to generate temporary credentials that can be used for accessing the instance that has been pre-configured for the training lab guide steps.

- `workshop.gitlabtraining.cloud` - This is used for enablement and field marketing workshops that are delivered on a routine basis. You should generate credentials for this instance if you are involved creating lab sample projects, lab guides, presenting, or supporting a workshop.

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](#access-shared-omnibus-instances). If you are enrolled in a self-paced training class, follow the [invitation code redemption](#invitation-code-redemption) steps instead of requesting instance credentials.

## Isolated Environments

- **AWS Account**: See the [instructions](#aws-account-or-gcp-project-sandbox-cloud) for provisioning your own isolated AWS account with the GitLab Sandbox Cloud.

- **GCP Project**: See the [instructions](#aws-account-or-gcp-project-sandbox-cloud) 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](https://docs.gitlab.com/ee/user/project/clusters/add_eks_clusters.html) GitLab documentation.

- **GCP Google Kubernetes Enginge (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](/handbook/customer-success/demo-systems/tutorials/getting-started/configuring-group-cluster/) to add your cluster to your GitLab group.

- **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](/handbook/customer-success/demo-systems/tutorials/getting-started/configuring-group-cluster/) to add your cluster to your GitLab group.

## How to Get Started

These instructions are for Demo Systems v2 that uses the [gitlabdemo.cloud](https://gitlabdemo.cloud) Portal. The Demo Systems v1 infrastructure that used [gitlabdemo.com](https://gitlabdemo.com) has been deprecated except for training class invitation codes.

Access to the shared environments is requested through the [Demo Architect Portal](https://cloud.gitlabdap.com/) (internal only).

### Access Shared Omnibus Instances

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

> The Demo Cloud Portal and provisioning system is powered by [gitlabdemo-cloud-app](https://gitlab.com/gitlab-com/demo-systems/management-apps/gitlabdemo-cloud-app), an open source project.

1. Visit the GitLab Demo Cloud Portal ([https://gitlabdemo.cloud](https://gitlabdemo.cloud)) and sign in with your Okta credentials.

1. Navigate to the Environments top navigation link or click on the **View Environments** button on the dashboard.

1. Locate the Environment Instance that you wish to access and click the **Generate Credentials** button.

1. After the credentials have been generated, click the **View Credentials** button.

1. Create a new record in your 1Password vault with your generated credentials.

1. Click the **Access Instance** button to open a new tab with the URL of the GitLab Omnibus instance.

1. Bookmark the Omnibus instance that you can use to easily access this in the future. You do not need to access the [https://gitlabdemo.cloud](https://gitlabdemo.cloud) portal each time you want to access the instance since this is only for access requests (credential generation).

1. After signing in, a group has been pre-created for you to store your projects under. To help with namespace consistency and security best practices, please do not create other top-level groups with custom names. You can create any subgroups or projects you'd like under your pre-created group or in your personal namespace.

1. Visit the [Demo Architect Portal](https://cloud.gitlabdap.com/) (internal only) and click **GitLab Team Member Login**.

1. Open the [Sandbox Instance Request](https://cloud.gitlabdap.com/sandbox_instance_request) (internal only) form and select the instance you need. Sales CS is the shared instance for most team members.

1. Submit the request.

1. Once your credentials are ready, create a new record in your 1Password vault with them.

1. Open the instance and sign in with the generated credentials.

1. Bookmark the instance so you can reach it directly next time.

1. 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.

1. 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.

1. You can ask for help from other peers in the `#cs-questions` Slack channel.

1. You can ask for help from other peers in the `#demo-architect-partners` Slack channel.

### AWS Account or GCP Project (Sandbox Cloud)

### Invitation Code Creation

Navigate to https://cloud.gitlabdap.com/, 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.

Navigate to the [Demo Architect Portal](https://cloud.gitlabdap.com/) (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 [https://cloud.gitlabdap.com/](https://cloud.gitlabdap.com/) and click the **Workshop/Lab Redemption** button.

1. Click **Sign In With GitLab**

1. Visit the [Demo Architect Portal](https://cloud.gitlabdap.com/) (internal only) and click the **Workshop/Lab Redemption** button.

1. Click **Sign In With GitLab**.

1. Type in the invitation code that was provided by your instructor or in your course materials.

1. Press **Submit Code**.

1. Click the blue **My Group** button to open a new tab with the URL of the your GitLab group living on Learn Labs.

1. Click the blue **My Group** button to open a new tab with the URL of your GitLab group on Learn Labs.

### Workshop Preparation

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 [here](https://cloud.gitlabdap.com/)

Workshop preparation steps will be linked on the resulting issue after completing the [request form](https://cloud.gitlabdap.com/) (internal only).

### Workshop lab guide catalog

All of the workshop content that are created officially can be found in the Content Discovery section on the [Demo Architect Portal](https://cloud.gitlabdap.com/)

All of the workshop content that is created officially can be found in the Content Discovery section on the [Demo Architect Portal](https://cloud.gitlabdap.com/) (internal only).

## Version Upgrades and Maintenance

We perform version upgrades on the weekend following the [monthly release](/handbook/engineering/releases/). The weekend upgrades are performed at a random time on Saturday or Sunday based on engineer availablility and lasts for approximately 30 minutes.

We perform version upgrades on the weekend following the [monthly release](/handbook/engineering/releases/). 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 that 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.

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.

### GitLab Duo features

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

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 are responsible for creating their own demo data or forking projects from other team members.

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](/handbook/solutions-architects/demonstrations/#demo-readiness) and [Existing Demonstrations](/handbook/solutions-architects/demonstrations/#existing-demonstrations) to get started.

## 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` depenending on the security risk of the source code or information contained within.

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 (Deprecated)

### Demo Systems v2

- `Public` Underlying Terraform Modules and Ansible Role

  - [terraform-modules](https://gitlab.com/gitlab-com/demo-systems/terraform-modules)