Computing Platforms

A computing platform is a platform (e.g., a Kubernetes cluster in AWS EKS, GKE, and so on) where dev environments are running. For example, you can run dev environments in the same cluster with the CodeCanvas application but in a different namespace. You can also run dev environments in a separate cluster or even in multiple clusters. In any case, before users can create dev environments, you should explicitly connect your computing platforms to CodeCanvas.

Connect a computing platform to CodeCanvas

Select Administration in the header navigation, then in the sidebar menu, select Computing Platforms.
Click New connection and specify the platform Name and other settings:
- Kubernetes namespace – the Kubernetes namespace where the dev environments are running. For example, you can run dev environments in the same cluster with the CodeCanvas application but in a different namespace.
- Relay server – a relay server that is used to establish a secure connection between user machines and dev environments. A typical CodeCanvas installation implies that the relay server is running in the same cluster with the CodeCanvas application. To use it, choose Default relay. Alternatively, you can configure and use custom relay servers.
- Pod template YAML – the YAML file that describes the pod template for the worker pod. Customize this template to make worker pods better meet the requirements of your infrastructure. CodeCanvas will automatically add all required labels, annotations, environment variables, and volumes that are necessary for the pods to function correctly. Therefore, all you need is to add your custom configuration to the pod template.
  For example, the following snippet shows how to add a label, an annotation, and an environment variable to the pod template:
  apiVersion: v1 kind: Pod metadata: labels: codecanvas: true annotations: codecanvas: true spec: containers: - name: worker-main env: - name: CODECANVAS value: true restartPolicy: Never
  Note that a worker pod is not a dev environment itself. It is a management container that starts nested dev environment containers. If you need to pass environment variables or files from the worker container to the dev environment containers, you can use the following special environment variables:
  - WORKER_STEP_CONTAINER_PROPAGATION_ENV_VAR_KEYS for environment variables
  - WORKER_STEP_CONTAINER_PROPAGATION_PATHS for paths to files
  For example, the following configuration will propagate the MY_ENV_VAR_1 and MY_ENV_VAR_2 environment variables from a pod to dev environment containers:
  apiVersion: v1 kind: Pod spec: containers: - name: worker-main env: - name: WORKER_STEP_CONTAINER_PROPAGATION_ENV_VAR_KEYS value: "MY_ENV_VAR_1;MY_ENV_VAR_2"
  This template is applied to all worker pods in the computing platform. If you need separate configurations for different instance types, you can specify Pod template YAML on the instance type level.
Click Save. The platform will be added to the list but will be in the Inactive state as it is not yet connected to CodeCanvas.
Open the newly added platform. The settings page will display the connection snippet for the helm upgrade command.
Click Generate token to generate an access token for the connection.
Copy the connection snippet with the access token and run it in the terminal of the Kubernetes cluster where the dev environments are running.
To check the connection status, click Test connection. All checks must return Success.

Freeze or delete a connection

To delete a connection, click Delete on the platform settings page. This will permanently delete the connection and all dev environments that are running on this platform.

If you want to temporarily stop creating new dev environments on a specific platform, click Freeze on the platform settings page. Note that this will not affect the existing dev environments.

Migrate from one platform to another

When upgrading your infrastructure, you may need to migrate from one computing platform to another. You can't migrate the existing dev environments, but you can transfer configuration data, namely, instance types that use the deprecated platform and dev environment templates based on these instance types.

In the instructions below, we will call the platform that you want to stop using deprecated and the new platform new.

Freeze the deprecated platform: Open the platform settings in Administration | Computing Platforms and click Freeze.
Rename the instance types that use the deprecated platform:
1. In the platform settings, click Show list next to Instance types.
2. Click Select all to select all instance types.
3. Click Rename and in the dialog that opens, specify either a prefix or a suffix for the instance type names. For example, you can add the [deprecated] prefix.
4. Click Rename.
Rename the dev environment templates that use the deprecated instance types:
1. In the platform settings, click Show list next to Templates.
2. Click Select all to select all templates.
3. Click Rename and in the dialog that opens, specify either a prefix or a suffix for the template names. For example, you can add the [deprecated] prefix.
4. Click Rename.
Use the [deprecated] instance types to create new ones:
1. Select Administration in the header navigation, then in the sidebar menu, select Instance Types.
2. For each [deprecated] instance type: Open the instance type settings and click Copy. In the dialog, specify a new name for the instance type and select the new Computing platform. Click Create.
Use the [deprecated] templates to create new ones:
1. Select Administration in the header navigation, then in the sidebar menu, select Templates.
2. For each [deprecated] template: Click Copy. In the dialog, specify a new name for the template and select the new Instance type. Finish creating the template.

Last modified: 12 February 2025