Seqera Platform Feature Requests

We’d love to see a “pre-flight check” feature in Seqera Platform that helps users catch common issues before a pipeline is submitted. This would improve the success rate of runs by validating key parts of the configuration and cloud environment up front. Specifically, this check could: Generate a clear, consolidated summary of the final configuration (combining Nextflow config, Platform overrides, workspace settings, etc.) Verify authentication and authorization to external resources (e.g., object storage, compute queues) Flag missing or potentially conflicting settings Suggest fixes or helpful links if something looks off This would help users answer questions like: “What credentials will my job use?” “Am I allowed to access this S3 bucket / Azure container?” “Which compute environment is actually going to run this?” It could be surfaced as: A button in the UI before submitting a pipeline A CLI command (e.g., nextflow nf-launch --check) Or even integrated into the pipeline submission flow as an optional step This kind of validation would be especially valuable in cloud or enterprise environments with complex policies and configurations. It would reduce frustration, support burden, and unnecessary trial-and-error.

This project will introduce versioning capabilities to Seqera Platform, allowing users to create, save, and reference different versions of pipelines based on their configuration and parameters. Planned Features Automatic Version Tracking Automatic version creation whenever a pipeline is created, modified, or launched with edited restricted parameters Checksum-based tracking for pipeline integrity and provenance Version Management Users with pipeline edit capabilities can assign custom labels to pipeline versions Ability to set any version as the default for launch Option to save completed workflow runs as new versions Restricted Parameter Control Users with pipeline edit capabilities can modify restricted parameters at the pipeline level Locked configurations for users with launch-only permissions to ensure controlled pipeline execution Support for custom nextflow_schema.json files to define editable parameters Version Selection at Launch Default version shown in launch form for all users Users with pipeline edit capabilities can select and launch any version Launch-only users can select from available labelled versions Commit ID Tracking Store commit IDs alongside revision information for deterministic pipeline execution Option to pin to specific commits or use latest branch updates Target Users This functionality is intended for bioinformaticians who customise platform pipelines for themselves or their users, applicable to all customers including Enterprise requiring pipeline execution control.

Currently there are two ways to launch a pipeline via the API: Populate the body of a POST /workflow/launch request , which requires getting a number of details such as the compute environment and configuration Create an action and POST /actions/${actionId}/launch , which only take pipeline params as options It would be nicer to reconcile the two and have a simpler flow: Create pipeline on Seqera Platform Launch specified pipeline using an endpoint, e.g. POST /pipeline/${pipelineId}/launch Importantly you would only be able to modify a very limited subset of options with this option, e.g. the pipeline parameters. This would save the automation developer the time and effort in writing a number of requests to GET settings before launching a pipeline via automation. The revision, compute environment, working directory, staging options and many other settings would be fixed and require addition of a new pipeline for a launch. This has some overlap with some other feature requests such as: API equivalent of this feature request

In our current internally-developed system that we are migrating away from, we have two views which are very valuable to our bio-operations team: An inline module execution status display view: this shows workflow runs with integrated module status in-line, which is colour-coded. A live DAG in the website equivalent to the Seqera Platform: this shows the status of the module execution, again colour-coded according to the status of the module execution. Both of these features would really help the operations team. Ticket attachments: [Redacted for privacy]

This post consolidates multiple related requests around managing pipeline run data on the Seqera Platform, specifically in the areas of log persistence and cleanup of scratch/intermediate data. Persistent Logs After Run Completion Support for archiving essential execution data — including .log, .timeline, .sh scripts, and reports — to a persistent S3 bucket (Tower-managed or user-defined). Allows run logs and metadata to remain visible in the Tower UI after work directories are deleted. Enables integration with custom lifecycle rules for scratch storage. Preserves artifacts critical for auditability, troubleshooting, and provenance. Manual Clean-Up via Tower UI ( A “Clean” action in the run details interface to: ) Trigger cleanup of intermediate files and caches (e.g., nextflow clean -l <run_name> ). Reclaim storage post-execution while retaining archived logs. Offer fine-grained control over data cleanup, one run at a time. Auto Clean-Up Option at Launch A toggle in the pipeline launch form to enable automatic cleanup when a run completes. Useful for test or debug workflows where data retention is not required. Prevents accumulation of scratch data without manual intervention. Clean-Up on Run Deletion An optional checkbox when deleting a run to also remove associated scratch/workdir data. Ensures that run deletion can include cleanup of underlying execution storage. Offers a single-step way to retire a workflow and its resource footprint. Out of Scope Automatic deletion of archived logs when a run is deleted. Cleanup functionality for in-progress or running workflows. Advanced or rule-based retention policies; current scope is limited to manual actions and simple toggles.

This is a feature request and the work probably applies to both the Seqera Platform and Nextflow. We would like to capture the time being spent on stageIn and stageOut and make them visible in Seqera Platform/Tower. Right now we can see there's a difference in duration and realtime , but we can't drill down into how much is actually spent on waiting vs stageIn vs stageOut . The timeline has some visualization that helps, but still doesn't distinguish waiting vs stageIn . Knowing how long stageIn and stageOut take will inform whether we decide to use scratch/stageInMode or not.

Nextflow supports using an S3-compatible endpoint as the work directory, even when using an HPC executor such as SLURM/PBS. Despite this feature, Platform will prevent a user submitting runs using an HPC executor using an S3 bucket as the work directory. As object storage becomes more popular in academic settings, it may be helpful to make this error message a warning rather than a run-stopping error.

We recently started using a newer version of Seqera Platform/Tower, which included a redesign of how Pipeline Runs are browsed. When navigating to a Pipeline Run results/detail page from the second page in the list of Pipeline Runs, upon going back to the list of Pipeline Runs you will be dropped back to the first page. This makes it very difficult to switch between Runs that are not on the first page. In addition it might also be nice option to add page numbers to the bottom navigation, in addition to only Next and Previous .

Currently, when the pipeline optimization feature is used on the Platform, there’s no clear indication in the UI that it has been applied to a given run. The only way to verify this is by inspecting the resolved configuration and manually checking for process directives associated with the optimized profile. It would be helpful to make this more visible directly in the run details, for example, in the Run Info section or alongside the run’s labels so users can quickly confirm whether optimization was applied without digging into the config. The resolved config can be very lengthy for certain pipelines. Why this matters: Helps users verify that performance improvements (e.g. faster runtimes, cost savings) are expected Helps in troubleshooting by confirming whether optimization was applied Supports reproducibility and auditability in production/regulated settings

In each workflow run, there's a table of individual tasks within the "Tasks" section. Some workflow runs may involve thousands of individual processes, and enabling search and filtering by process, tag, status, and more would greatly assist users in managing and analyzing their tasks, similar to how you can search and filter the list of workflow runs. The current Task widget presents a large amount of data in a confined space. Users must navigate the table through pagination, which can be cumbersome. Additionally, the absence of sorting options in the table can prevent effective pattern recognition. To address these issues, we propose several enhancements. Firstly, we recommend incorporating an expand/collapse feature for the table, allowing users to view it in full-screen mode for a more comprehensive and user-friendly experience. Additionally, where supported, we suggest enabling sorting of table columns. Finally, we propose the implementation of a data export to csv. These improvements will enhance the user experience by providing more effective ways to manage and analyze the data associated with individual tasks within workflow runs.