Skip to main content
A development environment is a managed, interactive workspace provided by Siverse for writing code, debugging programs, exploring data, and validating dependencies before submitting a training task. The platform supports two types of development environments: JupyterLab and VSCS. Development environments run in a cluster and consume instance resources. Closing the browser only disconnects your access; it does not stop the environment. To release compute resources, stop the development environment in the console. For long-running or multi-node training tasks, we recommend debugging the code in the development environment before submitting the task.

​
Select a Development Environment Type

You can enable browser and SSH access to VSCS separately or at the same time. Both access methods connect to the same development environment and share the same files, Volumes, and mounted data.

​
How Development Environments Relate to Resources

​
Basic Usage Workflow

  1. Prepare instance resources, storage resources, images, datasets, or models.
  2. Choose JupyterLab or VSCS based on your development workflow.
  3. Create a development environment. Configure its resource specifications, image, Volume, and dataset or model mounts.
  4. When the environment is running, open JupyterLab or browser-based VS Code, or connect through SSH.
  5. Develop and debug your code in the environment, and write any files you want to keep to the Volume.
  6. When you finish debugging, stop, restart, update, clone, save an image, or delete the development environment as needed.
  7. For stable operation, queue scheduling, fault tolerance, or multi-node training, submit the work as a training task.

​
Usage Boundaries

  • Stopping a development environment releases compute resources but retains its configuration and data saved to the Volume.
  • Deleting a development environment removes its record and releases the resources it uses. Before deleting it, make sure important files have been saved to the Volume.
  • Notebook files save only code and output; they do not save Python processes, GPU state, or training progress. Save checkpoints for long-running experiments.
  • Saving an image lets you reuse installed system dependencies and tools, but does not back up mounted Volumes, process memory, or runtime state.
  • Do not use overlapping mount paths or overwrite system directories in the image, such as /opt, /workspace, or /usr.
  • Available resource pools, images, Volumes, datasets, and models may vary by region and cluster. Before creating a development environment, confirm that you can access the required resources.