Container image templates
There are four container image templates provided: JupyterLab, R-IDE, Visual Studio Code, and Xpra. The image templates install a very limited number of packages when the Studio session container is built. You can install additional packages as needed during a Studio session.
The image template tag includes the version of the analysis application, an optional incompatibility flag, and the Seqera Connect version. Connect is the proprietary Seqera web server client that manages communication with the container. The tag string looks like this:
<tool_version>-[u<update_version>]-<connect_version>
<tool_version>: Third-party analysis application that follows its own semantic versioning<major>.<minor>.<patch>, such as4.2.5for JupyterLab.<update_version>: Optional analysis application update version, such asu1, for instances where a backwards incompatible change is introduced.<connect_version>: Seqera Connect client version, such as0.8or0.8.0.
Additionally, the Seqera Connect client version string has the format:
<major>.<minor>.<patch>
<major>: Signifies major version changes in the underlying Seqera Connect client.<minor>: Signifies breaking changes in the underlying Seqera Connect client.<patch>: Signifies patch (non-breaking) changes in the underlying Seqera Connect client.
When pushed to the container registry, an image template is tagged with the following tags:
<tool_version>-<major>.<minor>, such as4.2.3-0.8. When adding a new container template image this is the tag displayed in Seqera Platform.<tool_version>-<major>.<minor>.<patch>, such as4.2.3-0.8.4.
To view the latest versions of the images, see public.cr.seqera.io. You can also augment the Seqera-provided image templates or use your own custom container image templates. This approach is recommended for managing reproducible analysis environments. For more information, see Custom environments.
JupyterLab 4.2.5
The default user is the root account. The following conda-forge packages are available by default:
python=3.13.0pip=24.2jedi-language-server=0.41.4jupyterlab=4.2.5jupyter-collaboration=1.2.0jupyterlab-git=0.50.1jupytext=1.16.4jupyter-dash=0.4.2ipywidgets=7.8.4pandas[all]=2.2.3scikit-learn=1.5.2statsmodels=0.14.4itables=2.2.2seaborn[stats]=0.13.2altair=5.4.1plotly=5.24.1r-ggplot2=3.5.1nb_black=1.0.7qgrid=1.3.1
To install additional Python packages during a running Studio session, execute !pip install <packagename> commands in your notebook environment. Additional system-level packages can be installed in a terminal window using apt install <packagename>.
To see the list of all JupyterLab image templates available, including security scan results or to inspect the container specification, see public.cr.seqera.io/repo/platform/data-studio-jupyter.
R-IDE 4.4.1
The default user is the root account. To install R packages during a running Studio session, execute install.packages("<packagename>") commands in your notebook environment. Additional system-level packages can be installed in a terminal window using apt install <packagename>.
To see the list of all R-IDE image templates available, including security scan results or to inspect the container specification, see https://public.cr.seqera.io/repo/platform/data-studio-ride.
Visual Studio Code 1.93.1
Visual Studio Code is an integrated development environment (IDE) that supports many programming languages. The default user is the root account. The container template image ships with the latest stable version of Nextflow and the VS Code extension for Nextflow to make troubleshooting Nextflow workflows easier. To install additional extensions during a running Studio session, select Extensions. Additional system-level packages can be installed in a terminal window using apt install <packagename>.
To see the list of all Visual Studio Code image templates available, including security scan results or to inspect the container specification, see public.cr.seqera.io/platform/data-studio-vscode.
Docker-in-docker
A primary use case for VS Code in Studios is to develop new, and troubleshoot existing, Nextflow pipelines. This commonly requires running Docker in the Dockerized container. The recommended method is to:
1. Create an AWS Cloud compute environment: By default, this type of compute environment is optimized for running Nextflow pipelines.
Many standard nf-core pipelines such as nf-core/rnaseq require at least 4 CPUs and 16 GB memory. In Advanced options, specify an instance type with at least this amount of resources (e.g., m5d.xlarge).
2. Only have one running Studio session per compute environment: This allows the Studio session, and Nextflow, to maximize the available CPU and memory.
The template for nf-core pipelines has recently been updated, and many existing pipelines don't yet use the new multi-line shell command defined in nextflow.config. To ensure maximum compatibility with the latest version of Nextflow (that ships with the VS Code container template image), include the following in your pipeline nextflow.config file.
// Set bash options
process.shell = [
"bash",
"-C", // No clobber - prevent output redirection from overwriting files.
"-e", // Exit if a tool returns a non-zero status/exit code
"-u", // Treat unset variables and parameters as an error
"-o", // Returns the status of the last command to exit..
"pipefail" // ..with a non-zero status or zero if all successfully execute
]
Xpra 6.2.0
Xpra, known as screen for X, allows you to run X11 programs by giving you remote access to individual graphical applications. The container template image also installs NVIDIA Linux x64 (AMD64/EM64T) drivers for Ubuntu 22.04 for running GPU-enabled applications. To use these GPU drivers, your compute environment must specify GPU instance families.
The default user is the root account. The image is based on ubuntu:jammy. Additional system-level packages can be installed during a running Studio session in a terminal window using apt install <package_name>.
To see the list of all Xpra image templates available, including security scan results or to inspect the container specification, see public.cr.seqera.io/repo/platform/data-studio-xpra.
Limitations
EFS file systems
If you configured your compute environment to include an EFS file system with EFS file system > EFS mount path, the mount path must be explicitly specified. The mount path cannot be the same as your compute environment work directory. If the EFS file system is mounted as your compute environment work directory, snapshots cannot be saved and sessions fail.
To mount an EFS volume in a Studio session (for example, if your organization has a custom, managed, and standardized software stack in an EFS volume), add the EFS volume to the compute environment (system ID and mount path). The volume will be available at the specified mount path in the session.
For more information on AWS Batch configuration, see AWS Batch.