Seqera Platform Feature Requests

Currently, Seqera Platform can authenticate to Azure using a service principal. While fine, this requires long-lived keys. An enterprise (on premise) installation of Seqera Platform could use a managed identity for credential-less authentication. This would be more secure and provide significantly more security but is only available when running on an Azure hosted system. This is supported on AWS using the equivalent IAM roles: https://docs.seqera.io/platform/24.2/enterprise/advanced-topics/use-iam-role Azure supports a resource having >1 Managed Identity attached, therefore there are two ways this could work: Add a system assigned managed identity, users would still need to add Azure "credentials" for the Azure Storage and Batch account name, however they would not need to add any service principal details. Using multiple user-assigned managed identities, a user would still need to add Azure "credentials" for the Azure Storage and Batch account name, however they would also need to specify which managed identity they would like to use to authenticate 1 is easier to configure and more secure, however 2 provides far more control for system administrators. It might require more work on the user end to know which ID to use.

At the moment if you want to fix a Nextflow version, you have to use a pre-run script to export the NXF_VER environment version. This is fine, but it's not intuitive for what is a fairly central part of the experience of running Nextflow on Seqera Platform. Suggestion is to have a new field in the UI to set the Nextflow version. This could potentially be when creating a new Compute Environment, ideally with a secondary field which could be set when launching a workflow (either to set new or to override the default in the CE). The field should default to using the latest stable release of Nextflow, but give the option of using the latest edge release instead, or a specified exact release version.

When users submit jobs via Seqera Cloud (particularly with Google Batch executions), if there are underlying API request errors or IAM permission issues (e.g., request is denied or returns 403 errors), the Platform currently surfaces a generic message: "Unexpected error while processing request - Error ID: 6F1eRTX5WuqySP3zS6E5W6" This generic response is uninformative and forces users to reach out to Support to understand what went wrong. To enhance the user experience and reduce unnecessary support inquiries, we need to improve how these errors are surfaced to users. Infrastructure and DevOps teams at larger organizations also often need access to these error details to debug permission issues and misconfigurations on their end. Lack of clear error messages slows down troubleshooting and increases dependency on Seqera support. Instead of a generic error, display something like and potentially the response as well: "Error: Request denied due to insufficient IAM permissions. Please check your service account roles or quota settings."

We have issues where user submitted pipelines running in AWS Batch end up with misconfigured resource requests. This is especially the case when Nextflow pipelines use dynamic directives to automatically increase their CPU or Memory resource requirements on subsequent retried pipeline tasks. User's Nextflow tasks end up eventually requesting more CPU or Memory resources than is available by any of the EC2 types in the AWS Batch Compute Environment. This causes the jobs to get stuck in a RUNNABLE state. However, worse is that this causes the entire AWS Batch Job Queue to grind to a halt and stop running any Jobs at all. This is not a mistake on AWS's part, this is the accepted and expected behavior for AWS Batch; a single misconfigured Batch Job halts all job execution on the entire Job Queue. See the docs here; https://docs.aws.amazon.com/batch/latest/userguide/job_stuck_in_runnable.html The "solution" for this from AWS is that you need to update your AWS Batch Job Queue with jobStateLimitActions.action in order to have jobs stuck in RUNNABLE state automatically get canceled after some time limit if they are stuck due to MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE or MISCONFIGURATION:JOB_RESOURCE_REQUIREMENT . I am not aware of any alternative method for handling this, as this is the procedure recommended by AWS Support themselves. This is a problem because Seqera Platform's TowerForge interface for creating Compute Environments with AWS Batch via Platform does not appear to have any way to add these jobStateLimitActions. We cannot apply the jobStateLimitActions in a post-hoc manner ourselves because the TowerForge CE's are being actively managed by Platform, via the Platform UI, tw , and seqera-kit . We cant go making custom changes to the CE outside the scope of what TowerForge has set up since that breaks any notion of consistency in our deployment via "Infrastructure as Code". We also cannot even make these Job Queue changes ourselves since the AWS environment is managed and requires escalation and support tickets to IT to make such changes, which is infeasible if we need to re-deploy our CE's repeatedly via tw / seqerakit , etc.. Ultimately these features need to be baked into TowerForge so that we can apply this in our scripted Platform configs.

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?

Currently, when adding an AWS Batch compute environment and setting it to use Forge, if an SSH key pair is configured, the pipelines will fail right from the beginning, since the roles created by Forge do not include the necessary permissions to use the keys.

As of v24.2 Enterprise, if the AWS credentials supporting an AWS Batch Forge compute environment are deleted, the AWS resources will not be cleaned-up upon compute-environment deletion. This is absolutely logical, of course. However, I think non-technical users could benefit from a explicit warning regarding orphaned resources if credentials are deleted.

The inability to apply correct Git credentials is frequently reported by Seqera Platform users. This can cause pipeline executions to fail because Nextflow cannot successfully pull the pipeline code from the Git repository. Additionally, Seqera platform currently lacks real-time updates for compute environment (CE) statuses, resulting in CE being marked as "Available" even when they are not. This leads to a number of failed jobs or jobs remaining in a submitted status indefinitely. We aim to enhance this user experience by adding a credentials validation feature to the platform: Validation on Credentials Creation: When a user adds new Git credentials, the system must provide a test URL. The system will use this test URL to validate the credentials and either accept or reject them. Add a Validate Action in the Credentials List Page: Users will have the ability to validate their credentials and check if they remain valid over time. Implement System Periodic Checks: The system will periodically validate the credentials to ensure they are not expired. When the system detects non-functional credentials, a warning alert will be displayed on the list page, and, optionally, an email notification can be sent. Pipeline Git Credentials Reporting: When launching a pipeline, the platform will report which Git credentials have been applied to access the pipeline Git URL or display an error message if no credentials are found. Add a "refresh/check connectivity" button on the CE page to validate the actual availability of each compute environment. Additionally, leveraging periodic checks can ensure status accuracy without placing the entire responsibility on administrators.

Currently, Azure compute environments in our system are confined to a single pool, meaning jobs are executed solely on instances of the same type. Supporting multiple pools for Azure compute environments, each possessing the same customization properties currently available for the single pool implementation, would allow users to more flexibly shape their pipeline processes and direct processes to the most appropriate queue for execution. This would provide more versatility and contribute to increased efficiency and resource optimization for pipelines.

Introduce the support for the Microsoft Azure AKS computing platform executor. This addition significantly broadens the spectrum of supported Kubernetes platforms.