Seqera Platform Feature Requests

Organizations using Azure often disable password-based access to Azure Container Registry and require workloads to authenticate using managed identities. Seqera Platform currently requires users to select stored container registry credentials when configuring an Azure Batch compute environment. This prevents customers from using private registries where username/password authentication is prohibited, even when an approved managed identity is already available for the compute environment. We would like workspace administrators to configure a private container registry by specifying its registry URL and selecting an Azure managed identity, without storing registry passwords or access tokens in Platform. The configured identity should be available consistently across every node pool used by the compute environment so that launcher and task container images can be pulled successfully. Desired outcomes: Private Azure Container Registry images can be used without storing registry passwords in Platform. Administrators can associate a registry URL with an approved managed identity. Authentication applies consistently to all relevant Azure Batch node pools. Access remains governed through Azure IAM and can be revoked or audited there. Platform provides a clear configuration or permissions error when the selected identity cannot access the registry. Existing credential-based registry authentication remains available for registries that require it.

As a user working with large HDF5 format files ( .h5 , .hdf5 ), I want to view them natively in Data Explorer using a browser plugin like H5Web which is a collection of React components.

Fast follow for Service Account creation - this Service Account can generate an API token which allows for job submission.

Enable the creation of a Service Account that doesn't require an active email address or associated user identity and can be managed by Admin users.

This would enable Seqera Support Portal to match Seqera Platform's SSO integration, and I expect would be a quality of life improvement widely useful for Enterprise customers.

In light of the recent announcement & development of a Seqera Platform Terraform Provider ( https://feedback.seqera.io/feature-requests/p/cli-tool-needs-an-export-all-import-all-function-or-a-terraform-like-state-manag ; https://github.com/seqeralabs/terraform-provider-seqera ) I thought this might be a good opportunity to extend the concept one step further and consider build a full scale Seqera Platform SDK. Similar to the one for AWS here https://github.com/aws/aws-sdk-go-v2 Since the underlying Terraform provider methods are essentially just hitting the API endpoints for Platform, and the provider is already written in Go by necessity for Terraform, it seems like it could be possible and appropriate to have the API client interface for Seqera Platform useable as an independent stand-alone Go library which could both be used by the Terraform provider, and imported for use in other custom programs. This would be a very nice compliment to seqerakit https://github.com/seqeralabs/seqerakit and would expand the ways in which users could programmatically interface with Seqera Platform, and integrate Seqera Platform deeper into the rest of their custom internal infra stacks.

We would like the ability to use multiple Azure Blob Storage Accounts in Nextflow with the az: syntax. Storage accounts within Azure each have their own unique credentials that are required by the Seqera Platform to access the storage account. Additionally, the Platform can only currently support one credential per compute environment, setting a hard limit on 1 CE only being able to access a single storage account based on the credential.

As a user, I want to be able to provide multiple subnet IDs when configuring an AWS Cloud compute environment, so that I can spread workloads across multiple Availability Zones for resilience and spot capacity availability. The AWS Cloud CE currently accepts only a single subnet ID ( subnetId ) at the API level, which flows through to both the UI (single string field) and the Terraform provider ( subnet_id string attribute). This means users cannot configure multi-AZ deployments from the UI, API, or Terraform today. By contrast, AWS Batch CEs (via forge config) already support subnets: []string in the API and a list attribute in Terraform. AWS Cloud CE should be brought to parity.

Users exploring Co-Scientist need formal training materials and documentation for onboarding their teams. Additionally, customers want clarity on deployment options (cloud vs. self-hosted) and what data leaves their environment during Co-Scientist interactions.

I would like to be able to edit an existing Compute Environment without the need to Clone and then make Primary again. It seems all options are greyed out once I try to open it to make changes. Resources can be changed on the fly in most cases on AWS. Being our environments are manual, we should be able to edit any piece as it will correspond to edits we have already made in the environment. This is especially important as we head into launching jobs from Seqera Platform. If I have 15 workflows, and I have to edit the CE, I now have to go through all workflows and change the CE. Imagine if we have 50 workflows?