Seqera Platform Feature Requests

Currently, Studios cannot be used with Fusion-enabled Kubernetes CEs (Amazon EKS and Google GKE). Adding this will allow for greater control and more direct management of CEs for compliance, scale, and cost management purposes.

Many users develop their Python or R notebooks, or Nextflow pipelines in VSCode, on remote EC2 instances. Once a Studio session is in a running state, users should be able to run their local installation of the application but with the code and terminal running in the remote Studio session via a SSH tunnel to the EC2 instance. There is a VSCode plugin available that can be reviewed for inspiration.

Devcontainers is a standard format developed by Microsoft to configure development environments for VSCode and GitHub codespaces . It’s also going to be supported by GitPod . It’s a JSON file that sits in the root of a repo in a directory called .devcontainer/ . It can contain VSCode extensions, etc but the key things are: Dockerfile, docker arguments, and launch run commands. Supporting these files in Studios allow users to programmatically encode settings for Studios using a well adopted standard.

Adding the ability to programmatically execute commands in running Studio sessions remotely would allow deeper integration into other products/features both across Seqera Platform and third-party applications/tools.

Within a running private Studio session, automatically use existing Git user credentials attached to the user to authenticate to a remote Git repository (e.g. Github, Gitlab, Bitbucket, Gitea).

When creating a Studio sessions, it is possible to associate key-value resource labels to the session. These resource labels are displayed in the UI as tags, but the list of Studios does not provide the ability to filter or sort the studios based on the key or value of these labels. For larger workspaces with many studios, it would be helpful to subset the available sessions to those with particular keys and/or particular values.

Once a Studio session is running, it incurs costs. Estimating the hourly cost of the session and clearly presenting that in the user interface will ensure that users are aware of the potential cost impacts. The estimated hourly cost could initially be estimated on the “Add Studio” page (when the CE is selected) and be displayed on the specific Studio session detail page once the session is in a running state. When the session is in a stopped state, the cost estimator is still visible, but considered inactive.

We would like to store 3-5 pre-built docker images in the dropdown with custom, user-friendly names for each. Our users would much prefer to interact with known, user-friendly names rather than docker URIs.

Once connecting VScode studios to a local VSCode IDE is possible via SSH tunneling, there are different potential user flows how to most easily connect to the running studio session. One very user-friendly and easy way could be to add a studio session view into the Nextflow extension for VSCode that shows running VScode studio sessions and lets a user connect to it via clicking, similar to Gitpod ( https://www.gitpod.io/docs/gitpod/editors/vscode ). This request relates to SSH connection to a running studio .

I have a concern about the use of the root user in studios. As I am planning to expose the sudios to users who are not experienced with UNIX systems, I am afraid they might accidentally modify system files. Unless strictly required, I would strongly recommend changing the user and group IDs in your default docker images.