Warm-up
Dev environments can significantly increase the speed of development by removing the IDE warm-up phase: a period of time when the IDE builds indexes, and does other background activities like resolving project dependencies. You can put all these routines into a dev environment warm-up and run it on schedule. The result of the warm-up is a warm-up snapshot (a Docker volume) that is then mounted to a dev environment. Make sure the warm-up is run regularly: The fresher the index data is, the faster a dev environment will be ready for work.
When creating a dev environment, users will be able to choose the warm-up snapshot to start from.
Configure the warm-up
To configure warm-up, use the Startup performance | Warm-up section of a dev environment template.
Here:
Instance type – the resources allocated to the dev environment that will be used for creating the warm-up snapshot. As performance is not critical for the warm-up dev environments, you can choose a smaller instance type than for user dev environments.
Create project indexes for IDE – if enabled, the warm-up will build project indexes for the IDE specified in the template. Important:
If you disable this option, make sure to provide a warm-up script in Script. Otherwise, the warm-up will be useless.
If the template has multiple repositories, the warm-up will build indexes for all of them.
Creating project indexes for VS Code/Cursor is not supported.
Run custom script – if enabled, the warm-up will run your custom shell script specified in Script. For example, you can use it to build your project with
./gradlew buildor to configure the IDE. Important:In the script, you can use the environment variables defined in the template and the predefined environment variables.
As the script runs without a user, it doesn't have access to any personal parameters (secrets). If you need to provide sensitive data to the warm-up, see Provide secrets to a warm-up dev environment.
Don't use the script to install additional tools (e.g., with
apt get) – this data will not be saved in the snapshot.The warm-up first builds IDE indexes and runs the script only then.
If you run
dockercommands in the script, always runcanvas await-dockerdfirst, e.g.:canvas await-dockerd docker login ...This command ensures that the Docker daemon is ready to accept commands.
Script working directory – a path to the working directory where the Script will run. This path is relative to the
/mnt/jetbrains/workdirectory. If not specified, the script will run in/mnt/jetbrains/work. See directory structureParameters – environment variables that will be available in the warm-up. Use them to provide sensitive data to the warm-up environment like user credentials or access tokens. Learn more
Execution timeout (minutes) – CodeCanvas stops the warm-up and considers it failed if it takes longer than the specified time.
Run warm-up on schedule – if enabled, the warm-up will run on schedule specified with Cron triggers. Use the crontab format to specify the schedule (CodeCanvas server OS timezone). For example,
0 1 * * 1-5runs the warm-up every day at 1:00AM except for weekends. Learn moreSkip if no repository changes – if enabled, the warm-up will not run if there have been no changes in the Git repository since the last warm-up. If the template has multiple repositories, the warm-up will run only if there are changes in at least one of them.
Disable scheduling if – allows you to automatically disable warm-up scheduling if the warm-up fails for a specified number of runs or if the resulting snapshot is not used for a specified number of hours. Learn more
How the warm-up works
When the warm-up is triggered, CodeCanvas creates a dev environment based on the template settings: the specified container image, environment variables, and so on. Important: the environment can't be personalized for a particular user, that is, it can't use personal parameters. If you need to provide sensitive data to the warm-up, use warm-up parameters.
In this warm-up environment, CodeCanvas:
Checks out the project source code.
Runs your custom shell script if you specified it in the Script field. The warm-up will proceed to the next step only if the script exits successfully with a zero status code.
Runs the IDE specified in the template and builds project indexes.
Project indexes are specific for each IDE and most often for each IDE version. For the warm-up, CodeCanvas uses the IDE version specified in the IDE version parameter of the template. If it's Default, the warm-up will build indexes for the default IDE version.
If you don't want the warm-up to build project indexes, clear the Create project indexes for IDE checkbox.
Saves a snapshot of the file system – a warm-up snapshot.
Warm-up snapshot
A warm-up snapshot is an unmounted dev environment storage (a Docker volume). It includes the working directory, the user's home directory with project indexes, and the directory with CodeCanvas system data. Learn more about the directory structure
All other data is discarded. For this reason, don't use the warm-up to install additional tools (e.g., with apt get). If you need custom tools, use custom dev environment images instead.
Important notes:
CodeCanvas stores only the latest warm-up snapshot for each combination of an IDE and a Git branch. An IDE version is not taken into account. For example, a project has two branches:
mainandfeature-branch. Suppose some developers use JetBrains Rider and some use IntelliJ IDEA. There can be four snapshots maximum:main+ Rider,main+ IDEA,feature-branch+ Rider, andfeature-branch+ IDEA.Dev environments started from the same snapshot are independent of each other and don't share their state in any way.
The way snapshots are taken depends on the infrastructure. For example, in AWS, dev environment disks and snapshotting are based on EBS.
To view warm-up snapshots available in a namespace
Select Namespaces in the header navigation, then select the namespace you need.
In the sidebar namespace menu, select Warm-up Snapshots.
To delete a warm-up snapshot
Select Namespaces in the header navigation, then select the namespace you need.
In the sidebar namespace menu, select Warm-up Snapshots.
Find the snapshot and click

Delete.
Trigger the warm-up
There are two ways to trigger the warm-up: manually in the CodeCanvas UI and by schedule.
Select Namespaces in the header navigation, then select the namespace you need.
In the sidebar namespace menu, select Warm-up Snapshots.
Click New warm-up snapshot.
In the dialog, specify the required dev environment template and repository branch, and click Create.
The Cron triggers parameter of a dev environment template specifies the warm-up schedule. During the warm-up, CodeCanvas will use the environment settings (including the branch) specified in the template.
When specifying the schedule, use the crontab format (MIN HOUR DAY MONTH DAYOFWEEK). For example, to run warm-up every Friday at 23:59, specify 59 23 * * FRI. The time is set in the timezone of the CodeCanvas server OS.
To add one more trigger, click Add trigger and specify the schedule.
Auto-disable warm-up scheduling
To reduce resource costs, you can automatically disable the warm-up schedule. In the Startup performance | Warm-up section of a dev environment template, use the following options under Disable scheduling if:
Warm-up fails – disables warm-up scheduling after the specified number of failed warm-up runs. Default:
3Warm-up snapshot is unused – disables warm-up scheduling if no one used the resulting snapshot for the specified number of hours. Default:
72hours
After the schedule is disabled, the snapshot will not be updated automatically. You can still run the warm-up manually.
To be notified about scheduling being disabled, you can subscribe to the Warm-up schedule disabled event. See Notifications for more information.
Provide secrets to a warm-up dev environment
Your project might require sensitive data, like user credentials or access tokens, for example, for getting dependencies from a private repository or for accessing a database. While you can use personal user parameters for individual user dev environments, warm-up dev environments also require this data for their work. You define the required warm-up parameters on the namespace level and then assign them to the corresponding environment variables in the warm-up settings.
To define a warm-up parameter
Select Namespaces in the header navigation, then select the namespace you need.
In the sidebar namespace menu, select Settings, then Warm-up Parameters.
Click New parameter.
Specify
Key: a parameter name. You will use this name to reference this parameter in the warm-up settings.
Value: a parameter value.
Notes:
Parameters are stored in the encrypted form.
Parameters are used only during the warm-up with no user access to them.
Parameters exist only in the scope of a particular namespace. So, if you create a parameter in one namespace, you can't use them in other namespaces.
Parameter keys must be unique within a namespace.
A key must be no longer than 128 characters and can only contain alphanumeric characters (
[a-z],[A-Z],[0-9]), dashes (-), or underscores (_).Keys are case-insensitive.
Max secret's or parameter's value size is 30KB.
To add a parameter to a template
In the template settings, open the Startup performance section.
In the warm-up settings, under Parameters, click Add parameter.
Specify parameter settings:
Type– select the type of the variable: Variable (environment variable) or File.
Name – the name of the environment variable or an absolute path to a file on the warm-up environment.
Warm-up parameter – a reference to a warm-up parameter defined on the namespace level.
Create a warm-up snapshot for a custom branch
By default, the warm-up snapshot is created for the branch specified in the dev environment template. If you need to create a snapshot for another branch, you can do it manually.
Select Namespaces in the header navigation, then select the namespace you need.
In the sidebar namespace menu, select Warm-up Snapshots.
Click New warm-up snapshot.
In the dialog:
Specify the required dev environment template
Click Add branch override and specify the branch. In the case of multiple repositories, you can specify a custom branch for each repository.
Click Create.