Seqera Platform Feature Requests

I've noticed a recurrent error when running many workflows/jobs at the same time. AWS ECS seems to have trouble supporting pulling large numbers of containers from AWS ECR. When this happens, the AWS job fails (and doesn't retry) killing the workflow and reporting this error: Caused by: Task failed to start - CannotPullContainerError: context canceled Discussing with AWS support and they suggested that the job definition should be updated to include something along the lines of: > Sometimes this error could also be caused due to intermittent network connectivity issues, registry related issue when the ECS Agent/Docker Daemon is not able to connect to the registry and pull the image onto the host instance successfully. You can workaround this error by using the "Retry Mechanisim" in your job definition. Example: ********** "retryStrategy": { "attempts": 5, "evaluateOnExit": [ { "onStatusReason": "Host EC2*", "action": "RETRY" }, { "action": "RETRY", "onReason": "Task failed to start" (You can change the "onReason" statement as per error) }, { "onReason": "*", "action": "EXIT" } ] } ********** Is this something that can be updated in a future release so when the platform creates job definitions workflow don't fail due to not being able to pull a container and instead retries the container pull at least once?

Enterprise users need a private, self-hosted Nextflow module registry that supports pull-through from private GitHub repositories with authentication (PAT or app-based). The registry should allow organizations to centralize internal pipeline modules, support bulk import from one or multiple GitHub repos, and be deployable within the customer's network (Kubernetes/EKS preferred).

Nextflow data lineage is available in Seqera Platform v26.1 for AWS object storage (S3) and SQS message queues. It would be very helpful to expand this to other cloud providers (GCP, Azure, Oracle) and HPC environments with S3-compatible object storage (MinIO) and other messaging queues (like ElasticMQ).

As we look to migrate model training to AWS Batch, we would like the ability to use DataDog's new monitoring for model training. This requires a sidecar, which requires a multi-container job definition. https://docs.datadoghq.com/containers/guide/aws-batch-ecs-fargate/?tab=awswebui

Workspace administrators need the ability to gate Co-scientist access to specific users rather than enabling it for everyone in a workspace. This is critical for controlling token/usage consumption and ensuring only authorized users (e.g., pipeline developers) can invoke AI-assisted features. The UI should provide a dashboard or settings page to manage which users have Co-scientist access and optionally set per-user usage limits.

In our Seqera Platform pipelines, we frequently work with input parameters organized by functionality. It would be helpful to have the ability to dynamically reveal or hide certain parameters based on the value of another parameter. This approach would make the interface cleaner and focus only on the parameters relevant to the current pipeline configuration. Could this be achieved by modifying something in the schema?

I'm looking at joining some existing systems to the Seqera Platform, and building some new ones surrounding it. Users log in to those systems and they might request a Seqera Platform Nextflow pipeline to run, or to view the Nextflow Pipeline Run status and metadata, as well as metadata from other places. We're currently moving our SSO system to OpenID Connect through Okta, and having the ability to pass on the JWT based Access Token to Seqera Platform to make requests with a logged in users identity would make this much more possible. As a basic flow: A user logs in to Application A, and gains an Access Token and an Identity Token from Okta. The user views a Nextflow pipeline run, and surrounding metadata and decides to rerun it. In Application A, the user clicks rerun. A request is made to Seqera Platform with the users' Access Token as a Bearer token. Seqera Platform can either validate the JWT is correct or make a request to Okta to check its valid (or both). Seqera Platform validates access, kicking off a Nextflow Pipeline Run on the relevant compute environment. Application A polls the Seqera Platform for updates.

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 Service Account should be able to generate an API Token which allows for job submission.

We would like to be able to set job definition parameters within AWS Batch when building compute environments through Tower Forge: https://docs.aws.amazon.com/batch/latest/userguide/job_definition_parameters.html For example, I see no means by which I can adjust the hard and soft ulimit thresholds for AWS Batch jobs when creating Compute Environments via Tower Forge. Thank you!

We are taken to page 2 of the launch window while the run name needs to be edited on step 1 of the relaunch form. This adds a number of additional clicks for the end user and sometimes the user might just forget to edit the run name while triggering the run. If there was an ability to either edit the run name after it is finished, or customize the default run name (eg. {app_name}_{datetime} ), it would be tremendously helpful.