# Workstations, Images, & Containers ### Containers and Images Users of the Strong Compute ISC develop and launch experiments from inside containers. Containers store and facilitate access to users' project files, and allow installation of project dependencies. Just like ordinary containers, Strong Compute **containers** represent running instances of **images**. When you create a container, you select an image for your container to start from. Users can create containers based on public images available out-of-the-box in Strong Compute, or can import private images from Docker Hub, GitHub Container Registry, or custom/private container registries. Private images belong to the organisation selected in the top-right of the Control Plane page, and once imported are available to all members of the organisation. When the newly imported image status shows `stored` then containers can be created from that image. Users can import images by visiting **Workstations > Images** on Control Plane ().
Unlike ordinary containers, Strong Compute containers automatically persist their state when they are stopped and started, so you do not need to install your project dependencies all over again. Users can create and start containers by visiting **Workstations > Containers**.
Workstations are machines which are used to run user containers, as distinct from machines which are used for running experiments - for multi-node distributed training. ### Notes on Containers and Images Important things to note about containers and images on Strong Compute: * Containers are associated jointly with both users and organisations. Containers can be thought of as workspaces belonging to a user which are each associated with a specific organisation. * Containers can be thought of as a continuous (notwithstanding stopping and starting) instantiation of a running image. * Images are associated with organisations. Private images imported by any member of an organisation are visible and available for use by any other member of the organisation. * Users can create multiple containers associated with each organisation they belong to. * Containers have a maximum size limit of 50GB. To make larger data payloads available inside your container, it is recommended to create a [Dataset](/basic-concepts/datasets.md). * Container images are constructed of **layers**. A new layer is created each time the container is **stopped** and **saved** after changes have been made. The data stored with container images therefore will increase over the course of successive stops and starts (and saves), even if data is deleted from the container - that data still exists in the container layers. * Container images that have too many layers can be slow to start and stop due to the size and number of the layers. Container layers can be **squashed** by **stopping** or **restarting** container from the [ISC CLI](/basic-concepts/isc-commands-cli.md) with `isc container stop --squash` or `isc container restart --squash`, or by using the option toggles on the container **Stop or Restart** window.
* User container data is stored in cloud storage when the container is `Offline`, downloaded to a burst workstation or a cluster when the user requests to start the container, committed to the container image and shipped back to cloud storage when the container is stopped. * Containers are run in **interactive** mode on burst workstations or cluster workstations when a user clicks "Start". When the container is `Running` the user is able to create and make changes to files in the container via SSH. * Users are **billed** for **time** that the container is `Running` and for cloud **storage** of container data. Container data is committed to the container image and shipped to cloud storage when an experiment with `compute_mode="interruptible"` or `compute_mode="burst"` is launched, and when the container is stopped. See [Billing](/basic-concepts/billing.md) for more information about billing. * Containers can be deleted when the container status is `Offline`, which has the effect of permanently deleting all container image data from cloud storage and stopping billing for container storage. * Containers are run in **non-interactive** mode on training nodes (e.g. a "burst cluster") when the user launches an experiment. The container image committed for the experiment is run on each compute node, and the user's project files and data are made available **read-only** to the container. * Users can create containers based on public images available out-of-the-box in Strong Compute, or can import private images from Docker Hub, GitHub Container Registry, or custom/private container registries. This functionality includes significant differences from the nature and behaviour of containers on Strong Compute prior to 3 November 2025. Containers that were created prior to 3 November 2025 are no longer functional but can be converted to the new container format. Users with container created prior to 3 November 2025 that wish to have their containers converted to the new container format should contact Strong Compute. ### Container orientation The internal structure of containers include the following directories and files. * `/root` is the primary intended destination for user project files and data. * `/shared` is a secondary storage volume made available to container while running in interactive mode on a cluster workstation that is private to an organisation. This volume: * Is read-write accessible to all containers belonging to the same organisation running in interactive mode on a cluster. * Intended for use as a shared space for organisation members to securely share files and data. * Is **NOT** shipped to cloud storage, and is not available to compute nodes while running experiments. * Is limited to 100GB in size on a given cluster. ### Creating your container Users can create containers from the Containers section of the Workstations page in Control Plane.
## Starting your container on a Workstation A **Workstation** is a computer in a **Constellation Cluster** that runs user **Containers** in **interactive** mode. Workstations can either be "burst workstations" (cloud machines provisioned on-demand for the sole purpose of running a container in interactive mode) or cluster workstations (machines designated as workstation machines within a running cluster). ### Burst workstations Users can launch their container on a burst workstation by clicking "Start" on the container, selecting a burst shape from the "Select Burst Shapes" menu for the container, and clicking "Burst". The menu of available burst workstation machine types and their details and attributed is available on the "Burst" page in Control Plane. **Starting the burst workstation will take 5-10 minutes, so please be patient.** When you start your burst workstation, the ISC will provision the on-demand instance for you and ship your container (as well as any requested mounted dataset) to that workstation machine. When you **Stop** your container on a burst workstation, the ISC will ship your container back from the burst workstation to cloud storage. Stopping can also take 5-10 minutes. When started, your container SSH command will be displayed and the container status will show "running". Containers running on a burst workstation will have a volumes at `/shared` which is not available to other members of the user's organisation (their containers will be running on machines in a different cluster). This volume is **not** shipped from the container's home cluster but created **empty** on the burst workstation. Similarly, the `/shared` volume is not shipped back to the cloud storage when the container is stopped on the burst workstation. Users should save data in `/root` when working in a container in interactive mode to ensure that data is shipped back to cloud storage when stopped. Containers running on a burst workstation can launch experiments in `compute_mode = "burst"` but cannot launch experiments in `compute_mode = "cycle"` or `compute_mode = "interruptible"`. ### Cluster workstations Users can launch their container on a cluster workstation by clicking "Start" on the container, selecting a cluster from the "Select Cluster" menu for the container, and clicking "Start". Containers can be started with access to one or more GPUs, subject to the availability of GPUs on cluster workstations, by selecting from the "Select GPUs" menu. Containers running with **zero** **GPUs** share the system resources of the machine, such as CPU cores and memory, with other user containers running on that machine. Performance of containers running with zero GPUs may therefore be impacted at times by the number of other user containers also running on the same workstation. Containers running with **one or more GPUs** will have dedicated system resources such as CPU cores and memory. Performance of Containers running with one or more GPUs will not be impacted by other user activity. When your container has started, an SSH command will be shown with which you can connect to your running container and the container status will show "running". ### Mounting Datasets Users can also optionally select one or more **Datasets** to mount to their container when it is started from the "Select Datasets" menu. Datasets mounted to the Container are accessible within the Container at `/data`. ### Restarting containers Running containers can be restarted from the container **Stop or Restart** window in [Control Plane](#notes-on-containers-and-images), or using the ISC CLI with `isc container restart` which will [reduce the commit time](/basic-concepts/launching-experiments.md#cycle-sydney-strong-compute-cluster-only) for experiments launched with `compute_mode="cycle"`. Restarting the container saves any recent changes to the container image and restarts the container. Restarting the container terminates any active SSH connections, so users will need to SSH back into their container when it returns to a `running` state. ## Member containers Organisation Admin and Finance members can stop running member containers associated with that organisation by visiting the **Member Containers** section of the Workstations page. This allows organisation Admin and Finance members to manage the utilisation of organisation containers, including those running with one or more GPUs. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.strongcompute.com/basic-concepts/workstations-images-and-containers.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.