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.

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

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.

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 .

Enable users to use pipeline secrets in the head node, for example in the post-run script so to enable automation and integration with 3rd party tools and APIs

To enhance the versatility of pipeline integrations, we propose the implementation of a feature that allows access to and use of secrets in the post-run script configuration. This enhancement is a crucial enabler for seamless integrations with third-party platforms such as DataDog and workflow automation. By incorporating this capability, users gain greater flexibility and efficiency in managing sensitive information across different components of their workflows, contributing to a more robust and adaptable system.

Add the ability to export the Run history of a workspace via the Seqera Platform user interface directly or via the API. I appreciate that all Runs save an execution trace, DAG and report to the specified output folder, but the nice thing about the Seqera Platform is, of course, the ability to see a history of all Runs within a workspace.

It is possible to encounter request timeouts in Seqera Platform as: ​Launching on the platform is a blocking operation There is only 1 connection to an HPC cluster over SSH permitted Creating an initial Nextflow job on a cluster may take many seconds which can lead to a timeout (this is cluster specific) If Seqera can make launching a not blocking action it may help reduce timeouts.

It would just be nice to have code or code-like elements in the HTML font to use monospaced fonts. Thanks!