Seqera Platform Feature Requests

### 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 behaviour 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 behaviour 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.

As we look to migrate model training to AWS Batch, we would like the ability to use DataDog's new monitoring for model training. This requires a sidecar, which requires a multi-container job definition. https://docs.datadoghq.com/containers/guide/aws-batch-ecs-fargate/?tab=awswebui

We would like to be able to set job definition parameters within AWS Batch when building compute environments through Tower Forge: https://docs.aws.amazon.com/batch/latest/userguide/job_definition_parameters.html For example, I see no means by which I can adjust the hard and soft ulimit thresholds for AWS Batch jobs when creating Compute Environments via Tower Forge. Thank you!

AWS Cloud compute environments currently only expose EBS volume size as a configurable parameter but do not allow encryption to be set on the EBS block device, which can cause instance creation to fail in AWS accounts that enforce EBS encryption via an SCP. The ask has two parts: Enable encryption toggle and pass encrypted=true on the EBS block device. enforcement. AWS will use the account's default KMS key (AWS-managed or customer-designated CMK) automatically. Default here to be false. Optionally expose a KMS key ARN field in the AWS Cloud CE configuration UI, so customers who need a specific CMK (rather than the account default) can pass it explicitly. If if blank and encryption is enabled, use the account/region default key.

When AWS AMIs reach end-of-life (e.g., Amazon Linux 2 EOL), customers must manually update their Compute Environments to use new AMIs. BatchForge should provide automated notifications or optional auto-migration paths for AMI updates, reducing the operational burden on infrastructure teams that manage many CEs.

Can we get some consideration for support for Nvidia's job scheduler Run:ai ? Currently it seems that Nextflow / Seqera Platform does not have support for Run:ai. There seem to be some docs here . Let me know if this is possible and if any other details about Run:ai are needed. Thanks.

Workspaces with many Compute Environments make it difficult for users to know which CEs are appropriate for Studios sessions. Admins should be able to tag or filter CEs as "Studios-only" so that the Studios launch form only presents relevant CEs. This reduces user confusion and prevents accidental use of pipeline-oriented CEs for interactive sessions.

Allow the Seqera Platform's built-in implementation of "spot" instances to automatically failover to "on-demand" instances. This can be achieved with a Nextflow config but having a built-in implementation could help, especially when frequently creating or destroying compute environments.

Hi I have problem connecting with the cluster since Seqera supports only key + passphrase when login to cluster. The cluster I am trying to connect requires key + passphrase + password. https://www.hpc.dtu.dk/?page_id=4317#:~:text=ssh%2Dkeys%20%2B%20ssh%2Dkey%20passphrase%20%2B%20DTU%20password

Since AWS only allows 50 CE's per account (which translates to 25 usable CE's for Seqera Platform / Tower), the management of Computer Environments becomes really important. However, the current Compute Environments page is kinda sparse, only listing the Name, Status, Last Active, and ID, of each CE. It would be helpful if more details were viewable from the Compute Environments page, details for each CE such as how many pipelines are using it which pipelines are using it important attributes such as usage of Wave / Fusion, EBS AutoScale, types of EC2 instances, inclusion of GPU Hopefully some sort of compact-view could be developed to show these or other important attributes in the page for each CE. One of the real-world needs for this, is trying to consolidate CE's, to identify which have overlapping settings, and which might not be needed. Right now its pretty difficult to navigate this with the current UI.