JetBrains CodeCanvas 2024.1 Help


CodeCanvas was designed to deploy into Kubernetes clusters, emphasizing scalability and reliability. It is aimed for installation on major cloud providers such as Amazon EKS, Azure AKS, and Google GKE. Support for on-premises infrastructure is also planned.

CodeCanvas architecture

Core components

CodeCanvas application

The CodeCanvas application is the core component of the system. It is a web application that serves as a backend and provides the user interface for interactions with CodeCanvas.

Additional components:

  • Database (S3-compatible) – store the state of the CodeCanvas application.

  • Object storage (S3-compatible) – store user data and configuration. For more details, see Worker storage.

  • JetBrains Gateway – a client application that runs on end-user machines and let users create remote dev environments and connect to them. A user interacts with the IDE inside the dev environment through JetBrains Client.

    When the JetBrains Gateway connects to a dev environment, it first identifies the version of the IDE running in that environment. It then downloads the corresponding JetBrains Client build to ensure compatibility, launches the Client, and establishes a connection to the IDE.

Relay server

For security reasons, the dev environment cluster typically doesn't allow inbound connections from the outside. To enable communication between the IDE client on the user's machine and the dev environment, CodeCanvas uses a relay server.

Relay server is a component that acts as an intermediary between JetBrains Gateway on user machines and JetBrains IDEs within the dev environments. It is responsible for relaying WebSocket connections between JetBrains Gateway on the user's machine and the dev environment.

Jump server

For the same security reasons, direct SSH connections to dev environments may also be restricted in the network. To enable SSH connections from user machines, CodeCanvas uses a jump server.

Jump server is a component that acts as an intermediary for relaying SSH connections from a user machine to a dev environment. For example, for connecting to a dev environment using an SSH client or VS Code Remote SSH.

External services and integrations

Docker registry

The Docker registry is a service that stores Docker images necessary to run CodeCanvas and its services. By default, CodeCanvas uses a public Docker registry hosted by JetBrains. Alternatively, customers can publish the required images to their private registry.

JetBrains CDN

The JetBrains CDN is a service that hosts distribution packages for JetBrains IDEs and feeds that are used by CodeCanvas to get updates on the availability of new IDE versions. CodeCanvas periodically checks which IDE builds are available; worker instances download IDE distribution packages from this CDN.

Instead of using the JetBrains CDN, customers can configure CodeCanvas to use their own HTTP share to get IDE builds.

License server

The license server is a JetBrains service that verifies the validity of IDE licenses.

This is an optional component. CodeCanvas doesn't control how the customer provides licenses for JetBrains IDEs to user machines.

SMTP server

The SMTP server sends email notifications to users (e.g., warm-up failures, limit alerts) and for user management tasks like invitations and email confirmations. Managed by the customer.

Git hosting

CodeCanvas doesn't host Git repositories. Instead, it supports connections to external Git hosting services like GitHub, GitLab, BitBucket, and others. Managed by the customer.

(Optional) User directory

CodeCanvas integrates with user directories to provide user authentication and authorization. Supported protocols include OIDC, LDAP, AD, and SAML 2.0. Managed by the customer.


A worker in CodeCanvas is an agent application that constitutes an essential part of any dev environment or a warmup run. The worker connects to the CodeCanvas backend, gets the definition of a dev environment scheduled for start, and bootstraps its startup. After that, the worker monitors and reports the state of the dev environment to CodeCanvas. The bootstrap process of a dev environment includes:

  • starting required Docker containers, such as a dev container,

  • setting up a persistent disk for user data (see Worker storage),

  • downloading redistributable parts, such as the IDE.

In the case of Kubernetes installation, each dev environment is a pod with a single "worker" container. The worker application runs inside this container and uses the Docker daemon to spin up nested containers – the dev container and the auxiliary sidecar container. This model is known as Docker-in-Docker. In the future, this architecture will allow running dev environments on virtual machines in the same way.

Worker lifecycle

  1. A user creates or activates a dev environment or a warmup run.

  2. CodeCanvas adds the respective task to a queue.

  3. CodeCanvas schedules a Kubernetes pod with the worker for running this task.

  4. If there are available resources in the target Kubernetes cluster, the worker starts, connects to CodeCanvas, takes the task from the queue, and runs it.

  5. If there are no available resources, the dev environment stays in the "provisioning-resources" (pending) state until resources free up or additional nodes are added to the cluster. Note that CodeCanvas doesn't manage the lifecycle of Kubernetes nodes.

  6. After the dev environment is stopped or deleted, the worker terminates the nested containers and exits. The respective Kubernetes pod is terminated after that, ensuring that pods aren't reused for further or parallel tasks.

Worker storage

Storage lifecycle

This is how CodeCanvas manages user data storage in dev environments:

  1. Before creating a dev environment, CodeCanvas creates a persistent volume claim (PVC) for the user data.

  2. Kubernetes gets the PVC and creates a persistent volume (PV) for it using the related cloud object storage (e.g., Amazon EBS, Azure Disk, Google Persistent Disk).

  3. The volume is mounted to the worker pod and used by the dev environment.

  4. When the dev environment is stopped, CodeCanvas unmounts the volume from the worker pod.

  5. When the dev environment is restarted, CodeCanvas mounts the volume to the new worker pod.

Last modified: 17 May 2024