Seqera Platform Feature Requests

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.

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.

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

Co-Scientist's git connection currently only accepts GitHub personal access tokens. Teams whose code lives in GitLab can't connect their repositories, so they can't point Co-Scientist at their own pipelines. The request is to add GitLab support (personal access tokens, including self-hosted instances) so GitLab users get the same connect, clone, read, and push experience that GitHub users have today. Ideally this builds on the git credentials users already store in Seqera Platform, which supports GitHub, GitLab, and Bitbucket. Reusing those credentials would give Co-Scientist multi-provider support without a separate token flow per provider, and would extend naturally to Bitbucket as well.

This page: https://docs.seqera.io/platform-enterprise/enterprise/advanced-topics/manual-aws-batch-setup#create-the-batch-compute-environments suggests that graviton support is not possible in a manual CE setup. Is there any plan for this to be possible (and why is it not?), as we would be interested in swapping to graviton in the future.

I want to copy the co-scientist provided answer in a nice way. I can highlight the text, but it copies the (dark mode) font colors and the layout gets messed up when I try and paste into a third party system like Microsoft Teams.

I want to be able to share chat links with other people in my organization.

I'm in the process of moving data to a different storage location, and it would it be nice to bulk export a set of samplesheets

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