> ## Documentation Index
> Fetch the complete documentation index at: https://docs.scitix.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Development Environment Overview

> Learn about the JupyterLab and VSCS development environments in Siverse, and how they relate to compute resources, images, Volumes, datasets, and models.

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

| Type | Access method | Applicable scenarios |
| - | - | - |
| JupyterLab | Open the JupyterLab page in a browser. | Interactive notebook analysis, data exploration, visualization, single-GPU debugging, and lightweight experiments. |
| VSCS | Open VS Code in a browser, or connect using a local terminal, local VS Code, Cursor, or other tools after enabling SSH. | Multi-file project development, remote development with a local IDE, multi-GPU debugging, long-running debugging, and scenarios that require SSH. |

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

| Object | Relationship to the development environment | Considerations |
| - | - | - |
| Development environment | The JupyterLab or VSCS workspace you create. | When creating one, select a region, cluster, image, resource specifications, and mount configuration. |
| Instance resources and specifications | The CPU/GPU compute quota consumed while the development environment is running. | When you start or create an environment, the platform checks the resource pool quota. Resources requested by a single development environment must be schedulable on the same node. |
| Image | Determines the system environment, framework versions, dependency libraries, and development tools in the development environment. | Use validated images with fixed versions to prevent environment drift. |
| Volume | Stores code, Notebooks, dependency caches, output, and debugging artifacts persistently. | The workspace or default directory is only an access path. To retain files, write them to a mounted Volume. |
| Datasets and models | Usually mounted in the development environment as input for reading training data or model files. | Datasets and models are generally not used as output directories. Write output, caches, and intermediate results to a Volume. |

## 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.

## Related Documentation

* [Use the JupyterLab development environment](/siverse/development/use-jupyterlab-development-environment.md)
* [Use the VSCS development environment](/siverse/development/use-vscode-server-development-environment.md)
* [Create a training task](/siverse/training/create-training-tasks.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.