• Set up workspace infrastructure
• Create a workspace
• Connect to a workspace with SSH
  • Update your workspace container image
• Related topics
• Troubleshooting
  • Failed to renew lease when creating a workspace
  • No cluster agents available when creating workspaces

Workspace configuration

You can use workspaces to create and manage isolated development environments for your GitLab projects. Each workspace includes its own set of dependencies, libraries, and tools, which you can customize to meet the specific needs of each project.

Set up workspace infrastructure

Before you create a workspace, you must set up your infrastructure only once. To set up infrastructure for workspaces:

1. Set up a Kubernetes cluster that the GitLab agent supports. See the supported Kubernetes versions.
2. Ensure autoscaling for the Kubernetes cluster is enabled.
3. In the Kubernetes cluster:
   1. Verify that a default storage class is defined so that volumes can be dynamically provisioned for each workspace.
   2. Install an Ingress controller of your choice (for example, ingress-nginx).
   3. Install and configure the GitLab agent.
   4. Point dns_zone and *.<dns_zone> to the load balancer exposed by the Ingress controller.
   5. Set up the GitLab workspaces proxy.

Create a workspace

Prerequisites:

• Ensure your workspace infrastructure is already set up.
• You must have at least the Developer role in the root group.
• In each project where you want to create a workspace, create a devfile:
  1. On the left sidebar, select Search or go to and find your project.
  2. In the root directory of your project, create a file named devfile. You can use one of the example configurations.
• Ensure the container images used in the devfile support arbitrary user IDs.

To create a workspace:

1. On the left sidebar, select Search or go to and find your project.
2. Select Edit > New workspace.
3. From the Cluster agent dropdown list, select a cluster agent owned by the group the project belongs to.
4. From the Git reference dropdown list, select the branch, tag, or commit hash GitLab uses to create the workspace.
5. In Devfile location, enter the path to the devfile you use to configure the workspace. If your devfile is not in the root directory of your project, specify a relative path.
6. In Workspace automatically terminates after, enter the number of hours until the workspace automatically terminates. This timeout is a safety measure to prevent a workspace from consuming excessive resources or running indefinitely.
7. In Variables, enter the keys and values of the environment variables you want to inject into the workspace. To add a new variable, select Add variable.
8. Select Create workspace.

The workspace might take a few minutes to start. To open the workspace, under Preview, select the workspace. You also have access to the terminal and can install any necessary dependencies.

Connect to a workspace with SSH

Prerequisites:

• SSH must be enabled for the workspace.
• You must have a TCP load balancer that points to the GitLab workspaces proxy.

To connect to a workspace with an SSH client:

1. Get the name of the workspace:

   1. On the left sidebar, select Search or go to.
   2. Select Your work.
   3. Select Workspaces.
   4. Copy the name of the workspace you want to connect to.

2. Run this command:

   ssh <workspace_name>@<ssh_proxy>
   

3. For the password, enter your personal access token with at least the read_api scope.

When you connect to gitlab-workspaces-proxy through the TCP load balancer, gitlab-workspaces-proxy examines the username (workspace name) and interacts with GitLab to verify:

• The personal access token
• User access to the workspace

Update your workspace container image

To update your runtime images for SSH connections:

1. Install sshd in your runtime images.
2. Create a user named gitlab-workspaces to allow access to your container without a password.

FROM golang:1.20.5-bullseye

# Install `openssh-server` and other dependencies
RUN apt update \
    && apt upgrade -y \
    && apt install  openssh-server sudo curl git wget software-properties-common apt-transport-https --yes \
    && rm -rf /var/lib/apt/lists/*

# Permit empty passwords
RUN sed -i 's/nullok_secure/nullok/' /etc/pam.d/common-auth
RUN echo "PermitEmptyPasswords yes" >> /etc/ssh/sshd_config

# Generate a workspace host key
RUN ssh-keygen -A
RUN chmod 775 /etc/ssh/ssh_host_rsa_key && \
    chmod 775 /etc/ssh/ssh_host_ecdsa_key && \
    chmod 775 /etc/ssh/ssh_host_ed25519_key

# Create a `gitlab-workspaces` user
RUN useradd -l -u 5001 -G sudo -md /home/gitlab-workspaces -s /bin/bash gitlab-workspaces
RUN passwd -d gitlab-workspaces
ENV HOME=/home/gitlab-workspaces
WORKDIR $HOME
RUN mkdir -p /home/gitlab-workspaces && chgrp -R 0 /home && chmod -R g=u /etc/passwd /etc/group /home

# Allow sign-in access to `/etc/shadow`
RUN chmod 775 /etc/shadow

USER gitlab-workspaces

Related topics

• Quickstart guide for GitLab remote development workspaces
• Set up your infrastructure for on-demand, cloud-based development environments in GitLab

Troubleshooting

Failed to renew lease when creating a workspace

You might not be able to create a workspace due to a known issue in the GitLab agent for Kubernetes. The following error message might appear in the agent’s log:

{"level":"info","time":"2023-01-01T00:00:00.000Z","msg":"failed to renew lease gitlab-agent-remote-dev-dev/agent-123XX-lock: timed out waiting for the condition\n","agent_id":XXXX}

This issue occurs when an agent instance cannot renew its leadership lease, which results in the shutdown of leader-only modules including the remote_development module. To resolve this issue, restart the agent instance.

No cluster agents available when creating workspaces

When creating a workspace in a project, one of the following errors might occur:

• You can't create a workspace for this project when you attempt to create the workspace from Workspaces on the left sidebar.
• To set up this feature, contact your administrator. when you attempt to create the workspace in a specific project using the Edit function.
• An expected agent is not be present in the list of available agents.

Possible reasons for this error are:

• The user does not have at least Developer role for the workspace project and/or the agent project. To resolve this issue, ask the respective group or project owner to grant you access.
• The parent groups of the workspace project may not have any allowed agents. To resolve this issue, verify that the expected agents are allowed under the Workspace settings for any of the parent groups. To verify, you must have the Maintainer or Owner role for the group. If the agents are not allowed, you must allow a cluster agent for Workspaces in a group.
• The remote development module in the agent is disabled. To resolve this issue, please enable workspaces for this agent. Please refer to the remote development module settings on how this can be done.