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.

We’d love to see Seqera Platform support cloud identity passthrough, allowing pipelines to securely access cloud resources (like storage, compute, secrets) using native identity mechanisms from AWS, Azure, and GCP — without needing to manage long-lived credentials. (Seqera Platform already supports this for HPC). This would allow access to cloud services to be governed directly by cloud IAM policies, improving both security and enterprise integration. Why this matters Today, jobs typically authenticate to cloud services using infrastructure-level credentials (e.g., an IAM role or service principal attached to the compute environment). These credentials are: Shared across users Often over-permissioned Not user-aware — cloud services can’t tell who requested access This limits enterprises from applying their existing IAM policies and can create operational or audit complexity. ✅ What we’re asking for Enable Seqera Platform to support cloud-native, credential-less authentication, such as: AWS: IAM Roles with identity federation (e.g., via IAM Identity Center or OIDC) Azure: System- and user-assigned Managed Identities GCP: Workload Identity Federation tied to user or workspace context This would allow: Per-user or per-pipeline IAM role/identity selection Fine-grained access controls to cloud resources, managed entirely in the cloud provider’s IAM system Removal of static secrets (like service principal keys or access tokens)

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

Enable OIDC SSO in Seqera Cloud Pro. Current Seqera Cloud only supports email, Google, and Github authentication providers. This would enable support for users to bring their own providers such as Azure AD, Okta, and Google Workspace for seamless integration with existing identity infrastructure.

We are migrating a couple of workspaces to a new organization. We like to migrate everything in the workspace, including, users, workflows, compute environment, and the history of the runs. Do you have any recommendations on how to do this? It seems that we can do most of these resources apart from migrating the history of the runs. Is there any workarounds?

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]

Many users develop their Python or R notebooks, or Nextflow pipelines in VSCode, on remote EC2 instances. Once a Studio session is in a running state, users should be able to run their local installation of the application but with the code and terminal running in the remote Studio session via a SSH tunnel to the EC2 instance. There is a VSCode plugin available that can be reviewed for inspiration.

Currently there is an option to disable data explorer completely or there is an option to selectively disable auto populating of buckets on specifically specified workspaces. It would be beneficial if we could have the the option to reverse that: globally turn off auto populating of buckets except for specific workspaces or organizations.

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.

Currently, all workflows in a shared workspace are shared with the entire organization. It would be helpful to provide more fine-grained sharing controls that allow both 1) a central way to modify/adjust pipelines across multiple workspaces 2) specific sharing options that provide access in a subset of the organisation's workspaces