JetBrains CodeCanvas 2024.1 Help

Speed Up Dev Environment Startup

Normally, it takes a while to start up a dev environment, but you can significantly speed up the process by using:

  • Warm-up   – pre-creating environment snapshots with IDE indexes, project dependencies, and other data. Learn more

  • Standby pool   – keeping a pool of pre-created environments that are ready to use. Note that the standby pool allows stopping environments right after initialization, which lets you reduce pool costs by slightly extending startup time. Learn more

Of course, both warm-up and standby pool require additional resources, but they can save a lot of time.

Startup optimizations

For better understanding what parts of the dev environment startup can be optimized, see Startup time.

Keep in mind that warm-up and standby pool aren't personalized, for example, they can't use personal user secrets or parameters. Nevertheless, they let you create generic, semi-prepared dev environments that serve as a base for quicker personal setup.

Basic considerations

  • Warm-up

    Strongly recommended. It prepares a dev environment in advance by creating snapshots that include a cloned repository, pre-built IDE indexes, and other project data. Warm-up saves time and resources, as it eliminates the need for an IDE warm-up phase on individual dev environments.

  • Warm-up limitations

    While warm-up speeds up several startup stages, it doesn't eliminate all waits. For example, end users must still wait for resource provisioning in the cluster and container setup. The same is true for running an IDE  – it still takes time to start. See Startup time.

  • Standby pool

    Offers instant dev environment access but at a cost. Keeping dev environments running so that they're available on demand increases operational expenses.

  • Predicting standby pool size

    It's challenging to estimate the perfect number of dev environments to keep ready. Too many, and you're wasting resources; too few, and users end up waiting anyway.

  • Warm-up and standby pool together

    Using both together works best. Warm-up snapshots are used for all new dev environments, including those in the standby pool. This is why the pool can be replenished faster.

Startup time

The startup time depends on the size of the project  – the larger the repository, the longer it takes. The chart below shows which parts of the dev environment startup can be optimized using warm-up and standby pool.

Startup stages

In more detail:


Optimized by

1. Provisioning compute resources

CodeCanvas allocates resources for the environment in the target Kubernetes cluster. This may take up to 40 seconds (here and further, the time is approximate as it depends on many factors, including the configuration of your cluster).

Standby pool

2. Setting up the dev environment

This process may take up to several minutes or even longer.

2.1 Downloading IDE binaries

Up to 20 seconds.

Warm-up\Standby pool

2.2 Downloading IDE plugins

Depends on the number of plugins and their size.

Warm-up\Standby pool

2.3 Cloning the project repository

Depends on the repository size.

Warm-up\Standby pool

2.4 Running custom lifecycle scripts

Depends on the number of scripts and their complexity.

Standby pool

2.5 Starting the IDE backend

Depends on the dev environment resources and the number of plugins.

Standby pool

3. Preparatory computations

At this stage, the user connects to the dev environment. But it's not ready for work yet as some computations are still in progress. If at this point the user tries to build the sources or run unit tests in the IDE, they will have to wait until the computations are finished. This may take up to several or even tens of minutes, depending on the project size.

3.1 Importing the project

Depends on the project size as it includes downloading dependencies, loading project structure, build configuration, and so on.

Warm-up\Standby pool

3.2 Indexing the project

Depends on the project size and the number of files.

Warm-up\Standby pool

3.3 Building the project

Depends on the project size and build configuration.


Last modified: 17 May 2024