Seqera Platform Feature Requests

Organizations using Azure often disable password-based access to Azure Container Registry and require workloads to authenticate using managed identities. Seqera Platform currently requires users to select stored container registry credentials when configuring an Azure Batch compute environment. This prevents customers from using private registries where username/password authentication is prohibited, even when an approved managed identity is already available for the compute environment. We would like workspace administrators to configure a private container registry by specifying its registry URL and selecting an Azure managed identity, without storing registry passwords or access tokens in Platform. The configured identity should be available consistently across every node pool used by the compute environment so that launcher and task container images can be pulled successfully. Desired outcomes: Private Azure Container Registry images can be used without storing registry passwords in Platform. Administrators can associate a registry URL with an approved managed identity. Authentication applies consistently to all relevant Azure Batch node pools. Access remains governed through Azure IAM and can be revoked or audited there. Platform provides a clear configuration or permissions error when the selected identity cannot access the registry. Existing credential-based registry authentication remains available for registries that require it.

As a user, I want to be able to provide multiple subnet IDs when configuring an AWS Cloud compute environment, so that I can spread workloads across multiple Availability Zones for resilience and spot capacity availability. The AWS Cloud CE currently accepts only a single subnet ID ( subnetId ) at the API level, which flows through to both the UI (single string field) and the Terraform provider ( subnet_id string attribute). This means users cannot configure multi-AZ deployments from the UI, API, or Terraform today. By contrast, AWS Batch CEs (via forge config) already support subnets: []string in the API and a list attribute in Terraform. AWS Cloud CE should be brought to parity.

Problem: Platform drives GKE clusters through the control plane's IP endpoint. Security-conscious customers increasingly run private-endpoint-only clusters ( enablePrivateEndpoint=true , often with privateEndpointEnforcementEnabled=true ), where the control plane has no public IP and no authorized-networks entry can admit Seqera Cloud. For these customers, GKE compute environment creation fails at the reachability probe, and today their only supported choices give something up: Google Batch (no Kubernetes), a re-enabled restricted public endpoint (posture change), the generic Kubernetes CE over the DNS endpoint (no Fusion, no Data Explorer on work dirs), or Enterprise (deployment change). Proposal: Every GKE cluster has a second control-plane endpoint: a DNS name ( controlPlaneEndpointsConfig.dnsEndpointConfig.endpoint , GA 2024-11-11, always present) served through Google Front End and authenticated by IAM ( container.clusters.connect ) instead of source IP. GKE compute environments should prefer it when enabled ( allowExternalTraffic=true ), falling back to the IP endpoint otherwise. That makes private-endpoint-only clusters work from Seqera Cloud with no change to the cluster's network posture and the full GKE feature set intact - Fusion, Wave, Data Explorer, log retrieval.

Related to the Feature Request about NVMe cache in the EC2 here https://feedback.seqera.io/feature-requests/p/nvme-free-disk-space-should-be-a-consumable-resource-for-intelligent-compute-sch and related to some past discussions, just wanted to get a dedicated Request for this as well. In many cases we are favoring "stability" of Nextflow task execution moreso than "optimization". To this end, I think a lot of headaches could be avoided if we were able to more easily force Nextflow jobs in AWS Batch to be scheduled on dedicated EC2 instances, instead of attempting to pack tons of jobs on fewer EC2's. This especially becomes a concern when things like NVMe starts getting heavily utilized and there are concerns that multiple jobs e.g. using Fusion heavily for large data could end up colliding and potentially cause degraded performance or failures if the NVMe fills up from multiple jobs running at once, or for other reasons. So overall, we would be interested to have the option to configure Intelligent Compute in a way that favors giving jobs their own dedicated EC2 instances, along with taking any other potential measures, to attempt to ensure stability of task execution. Thanks

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.

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.

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!

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.

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