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

Problem / motivation Creating a Google Cloud compute environment (the single-VM google-cloud type, which is the only GCP CE that Studios supports) requires the provisioning credential to hold resourcemanager.projects.setIamPolicy - i.e. the "Project IAM Admin" role. Several customers consider this too broad to grant, since whoever holds it can bind any role to any principal across the whole project. There is currently no way to provision this CE type without it. for exactly this reason. Current behavior The google-cloud CE is always Forge-provisioned ( isForgeEnv is unconditionally true). During creation, Forge: Creates a new, per-CE service account ( iam.serviceAccounts.create ). Grants it roles/storage.objectAdmin on the work-dir bucket (bucket-level setIamPolicy ). Edits the project IAM policy to grant that SA four roles — logging.logWriter , monitoring.metricWriter , storage.bucketViewer , storage.objectViewer — which is what requires resourcemanager.projects.setIamPolicy . The same project-level setIamPolicy is invoked again at teardown to remove the bindings before deleting the SA. GoogleCloudConfig.serviceAccountEmail exists but is an output (populated by Forge), not an input — there is no path for a user to supply an existing SA and have Forge skip steps 1 and 3. Code (platform/master): modules/platform-compute-platforms/impl/src/main/groovy/io/seqera/tower/service/platform/gcp/GoogleCloudForgeClientImpl.groovy — createServiceAccount L392; project setIamPolicy L520; removal L570 .../service/forge/GoogleCloudForgeDelegate.groovy — isForgeEnv L125; serviceAccountEmail set from Forge result L68 Requested behavior Add an option on the Google Cloud (single-VM) CE to use a customer-provided service account instead of creating one. When a service account is supplied: Forge skips SA creation and skips the project-level IAM policy edit. The customer is responsible for pre-granting that SA the required roles (we document the exact set). Provisioning then only needs permissions to attach the existing SA to the VM, not resourcemanager.projects.setIamPolicy . This mirrors how the Google Batch CE already behaves — it reuses the credential's own service account ( GoogleBatchPlatformProvider.groovy:717 ) and never touches the project IAM policy. Acceptance criteria A google-cloud CE can be created with a user-supplied service account and no use of resourcemanager.projects.setIamPolicy at create or delete time. When no SA is supplied, behaviour is unchanged (Forge creates and binds as today), so this is backward compatible. Docs list the exact roles the supplied SA must already hold. Teardown does not attempt to remove project bindings it did not create. Notes / scope This is the CE that GCP Studios runs on; there is no GoogleBatchStudioProvider , so customers can't sidestep it by switching CE type. setIamPolicy is inherently project-scoped, so a narrower-scope grant is not possible — a BYO-SA path is the only way to remove the requirement.

I've noticed a recurrent error when running many workflows/jobs at the same time. AWS ECS seems to have trouble supporting pulling large numbers of containers from AWS ECR. When this happens, the AWS job fails (and doesn't retry) killing the workflow and reporting this error: Caused by: Task failed to start - CannotPullContainerError: context canceled Discussing with AWS support and they suggested that the job definition should be updated to include something along the lines of: > Sometimes this error could also be caused due to intermittent network connectivity issues, registry related issue when the ECS Agent/Docker Daemon is not able to connect to the registry and pull the image onto the host instance successfully. You can workaround this error by using the "Retry Mechanisim" in your job definition. Example: ********** "retryStrategy": { "attempts": 5, "evaluateOnExit": [ { "onStatusReason": "Host EC2*", "action": "RETRY" }, { "action": "RETRY", "onReason": "Task failed to start" (You can change the "onReason" statement as per error) }, { "onReason": "*", "action": "EXIT" } ] } ********** Is this something that can be updated in a future release so when the platform creates job definitions workflow don't fail due to not being able to pull a container and instead retries the container pull at least once?