Seqera Platform Feature Requests

Related to the Feature Request about NVMe cache in the EC2 here https://feedback.seqera.io/feature-requests/p/nvme-free-disk-space-should-be-a-consumable-resource-for-intelligent-compute-sch and related to some past discussions, just wanted to get a dedicated Request for this as well. In many cases we are favoring "stability" of Nextflow task execution moreso than "optimization". To this end, I think a lot of headaches could be avoided if we were able to more easily force Nextflow jobs in AWS Batch to be scheduled on dedicated EC2 instances, instead of attempting to pack tons of jobs on fewer EC2's. This especially becomes a concern when things like NVMe starts getting heavily utilized and there are concerns that multiple jobs e.g. using Fusion heavily for large data could end up colliding and potentially cause degraded performance or failures if the NVMe fills up from multiple jobs running at once, or for other reasons. So overall, we would be interested to have the option to configure Intelligent Compute in a way that favors giving jobs their own dedicated EC2 instances, along with taking any other potential measures, to attempt to ensure stability of task execution. Thanks

Just wanted to put a dedicated Feature Request for this one, related to the request for Fusion here https://feedback.seqera.io/feature-requests/p/nextflow-fusion-needs-a-stage-in-method-to-optionally-copy-the-full-input-file-l For the upcoming Seqera Intelligent Compute scheduler, it would be great if the scheduler could keep track of the NVMe disk usage in the EC2's which are running jobs, to ensure that new jobs dont get allocated to EC2 that might have a full or low free space in the NVMe. Not sure if this was already a noted feature or not. Thanks!

We have been using Fusion for a while now and overall its fantastic. However, it seems like one of the more common edge-cases we ended up debugging is for tasks and processes that are reading or writing data to/from disk at incredibly high rates. In these cases, the data IO speed seems like it can sometimes degrade when Fusion is in use, and one of the "work arounds" can sometimes end up being to try to force the Nextflow task to manually download the entire S3 file locally first, so that the scripts and tools used in the Nextflow task can take advantage of the full speed of the local NVMe cache without the overhead of streaming data in from S3 in the background. This goes against the core purpose of Fusion, and I know the Fusion dev team is working to deal with these situations better, but it also makes me wonder if its worth having some sort of "stage in method" for Fusion (possibly configured from the Nextflow script?) in order to indicate that some specific input files should just automatically get fully downloaded ahead of time in the background by Fusion instead of trying to stream them in as normal. I know this would surface other issues, such as the NVMe cache potentially filling up, so I am not sure if this is an ideal solution to the problem. However at least for debugging, it would actually be very helpful to be able to easily enable a feature like this. Let me know what you guys think. Maybe some alternatives that keep Fusion's core functionality better, might be the ability to ensure that it is pre-cache'ing larger chunks of data than might be the default setting.

Currently, AWS Batch without Fargate and AWS Cloud CE are the only supported compute environments (CE) for Studios. Adding support for HPC environments (like Slurm) would benefit many customers who want to adopt interactive analyses within their HPC deployments.

Currently, Seqera Studio requires users to set a session lifespan at the time of creation, and this cannot be changed once the session is running. This limitation can lead to inefficiencies when workflows take longer than expected or finish earlier than planned. Feature Request: Add functionality to adjust the session stop time (extend or shorten) for an active session without restarting it. This would allow users to: Extend sessions when additional compute time is needed. Shorten sessions to save resources if work completes early. Benefits: Improved flexibility for dynamic workloads. Reduced resource waste and cost. Better user experience for long-running or unpredictable tasks.

When Platform launches a run on an AWS Batch compute environment, it creates a temporary AWS Secrets Manager secret for each selected workspace or user secret and removes it when the run completes. These secrets are created with the default AWS-managed key, and there is currently no option to have Platform encrypt them with a customer-managed KMS key (CMK). This prevents workspace secrets from working in any AWS account that enforces CMK encryption on Secrets Manager. We have hit this at an enterprise customer whose account runs an automated governance policy that deletes any secret not encrypted with a CMK. The policy removes Platform's secret within seconds of it being created, before the Nextflow head job reads it, so every run that uses a secret fails with Unable to find a secret with name '<x>' — with no indication that the secret was created and then deleted by a third party. The request is to add an option to specify a customer-managed KMS key for these secrets, applied at creation time (the KmsKeyId parameter of the Secrets Manager CreateSecret API). A per-compute-environment setting fits best, since the key is account- and region-specific, with an optional global default. The equivalent capability for GCP Secret Manager would be valuable too. The compute roles that read these secrets already require kms:Decrypt, so no read-path changes should be needed. The only current workaround is for the customer to exempt Platform's secret name prefix (tower-*) from their CMK-enforcement policy. Security teams in regulated environments often will not grant that exemption, which leaves affected customers unable to use workspace secrets on AWS at all.

Currently Data Explorer preview supports common formats. For the image analysis community, a big win would be to be able to visualize large, multiplexed images directly on s3 storage with something like: https://github.com/hms-dbmi/viv https://avivator.gehlenborglab.org/ The value of this will become more assessable as we onboard more clients doing image analysis.

When launching a pipeline, some parameters depend on the value of other parameters (e.g., selecting a genome assembly should filter available annotation files, or selecting a project should populate available sample lists). Currently, all parameter values must be statically defined in the schema. Add support for dynamic parameter lookup — where selecting a value in one field triggers an API call or lookup to populate dependent fields — so users see only valid, context-appropriate options without manual entry.

This is an overarching request for improvements to the Actions feature in Seqera Platform. We aim to improve how actions are supported in Seqera Platform, streamlining user interactions and making them more efficient. To achieve this goal, we have several objectives: Allow users to clone actions from the UI, providing a quick and convenient feature enhancement. Enable users to specify additional fields in action calls, such as the run name (supported by the API). Add additional Actions triggers, including cron/scheduled hooks, pipeline lifecycle events (start, complete, fail), and changes in data. Add additional Actions responses, including running a script/function. Implement the ability to import/export actions as JSON, providing users an easy way to manage and share actions. These enhancements will enhance user experiences and make managing actions in Seqera platform more versatile and user-friendly.

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).