Seqera Platform Feature Requests

Currently, Seqera Platform can authenticate to Azure using a service principal. While fine, this requires long-lived keys. An enterprise (on premise) installation of Seqera Platform could use a managed identity for credential-less authentication. This would be more secure and provide significantly more security but is only available when running on an Azure hosted system. This is supported on AWS using the equivalent IAM roles: https://docs.seqera.io/platform/24.2/enterprise/advanced-topics/use-iam-role Azure supports a resource having >1 Managed Identity attached, therefore there are two ways this could work: Add a system assigned managed identity, users would still need to add Azure "credentials" for the Azure Storage and Batch account name, however they would not need to add any service principal details. Using multiple user-assigned managed identities, a user would still need to add Azure "credentials" for the Azure Storage and Batch account name, however they would also need to specify which managed identity they would like to use to authenticate 1 is easier to configure and more secure, however 2 provides far more control for system administrators. It might require more work on the user end to know which ID to use.

The current implementation of Studios requires wildcard certificates to manage the in-application URL routing. This can be a blocker for adoption at Enterprise organizations that cannot issue wildcard certificates due to security concerns.

Currently, Studios cannot be used with Fusion-enabled Kubernetes CEs (Amazon EKS and Google GKE). Adding this will allow for greater control and more direct management of CEs for compliance, scale, and cost management purposes.

Similar & related: https://feedback.seqera.io/feature-requests/p/ability-to-pass-data-from-the-oidc-user-token-info-into-the-compute-pipeline-con https://feedback.seqera.io/feature-requests/p/template-resource-labels Right now, Nextflow has the built-in implicit task , workflow , and nextflow variables that provide important information inside the pipeline about the execution contexts. (docs: https://www.nextflow.io/docs/latest/script.html#implicit-variables ) This should ideally be expanded, somehow (?), to give an easy and consistent interface to metadata about the Seqera Platform execution context. So that there could be perhaps an implicit variable such as workflow.tower or tower which could include things like Run ID, User, Pipeline details, etc.. As the linked Feature Request details, this could also encompass things such as Okta auth user metadata provided by Seqera Platform. And as the other linked Feature Request details, this information would be critical for inclusion in things like resourceLabels tagging for cloud resource labels and cost tracking. Along with whatever other purposes people typically use things like workflow and nextflow variables for. If there was some easy method to pass these critical metadata values into your Nextflow pipeline, then you could also easily leverage this by making Nextflow config files that utilize these metadata's in various ways at the config-level, so you wouldnt have to actually hard-code it into your main pipeline script. And these config files could be applied at the Compute Environment level ( https://feedback.seqera.io/feature-requests/p/allow-setting-nextflowconfig-settings-on-compute-environments-or-seqera-platform ) or based on other desired criteria. I dont know what "Category" to apply for this Feature Request so please update the category here if you are able to, thanks. ----- here is a tl;dr: with a real-world use case that would be able to utilize this to put all these things together make metadata available inside the Nextflow pipeline with some magic implicit variable use those implicit variables in a config file to apply things like resourceLabels for the AWS Batch cloud resource tagging stick those config files in the Compute Environment (in Tower) so that all pipelines executed on that CE automatically get their Batch jobs tagged

Currently, real-time in-notebook collaboration is only available in Jupyter, VS Code and Xpra containers because RStudio only supports this feature with a paid Pro license. Adding support in RStudio will require the ability to attach a Posit license to a Studio session.

It would be great to have the ability to create access tokens with custom-scoped permissions. Right now, tokens inherit all the permissions of the user who creates them, which can be risky in some situations. Determining specific permissions for each token would make things more secure and flexible.

We would like to build custom launch interfaces for nf-core pipelines in our Seqera Platform instance. By that I mean a restricted, minimal interface that only allows to set a minimal set of parameters while the rest is either frozen to a predefined default, or derived from these parameters. For instance, for the nf-core/demultiplex pipeline, the only thing we'd like launch users to be able to set is the flowcell ID, the filename of the samplesheet and to which project this flowcell belongs. The input and output path shall be derived from the flowcell and project ID, and other options (e.g. demultiplexer ) shall not be editable by the user. For instance, to derived the outdir from the project_id , we'd envisage something like params.outdir = "s3://some-company-namespace-${params.project_id}/demultiplex" . To achieve this, for now, we built a custom Nextflow pipeline that wraps the nf-core pipeline with a custom schema. Example . However, ideally, the same could be achieved directly in Seqera Platform. For that, I believe the following would be necessary: support for custom schemas outside the pipeline repo, see also support for custom nextflow.config outside the pipeline repo some sort of scripting to manipulate params and possibly input samplesheets (i.e. generate params and samplesheets from whatever is specified in the custom schema).

There is a character length limit for legal Datasets names. This limit can frustrate naming conventions in some groups which might include a lot of metadata in the dataset name. This metadata would be useful as search targets when searching for a datatset. Alternative (and perhaps preferable) solutions: Adding arbitrary metadata tags or key-value pairs to datasets: This metadata would need to be searchable Adding the "Description" to the elements to consider during search: This is less structured than the suggestion above, but perhaps more easily implemented.

Our primary use case for the Seqera Platform involves one user setting up a workspace with preconfigured pipelines, accessible to others in the organization. We aim to preconfigure pipelines to a large extent, yet allowing for minor, user-specific or pipeline-specific customizations. If variables could be included in paths, which are evaluated at pipeline launch, a tidier directory structure accommodating many different users and pipelines would be possible. Therefore, I propose that a distinct set of variables should be supported by Seqera Platform/Tower: username , pipelinename , pipelinerevision , workspacename and date come to my mind. All are "known" to the Platform when launching a pipeline, but may not exist yet. Therefore, the respective paths must be created automatically by the agent, if not available on the HPC / cloud provider. For instance, a work directory could be preconfigured as: /path/to/a/work/directory/{{username}}/{{pipelinename}}/{{runname}} Parameter files could be specific to a pipeline revision: /path/to/a/params/{{pipelinename}}/params-{{pipelinerevision}}.json and account for changing parameters. This would streamline the management of configurations, parameters, work directories, launch directories, and outputs across numerous users and pipeline runs.

This would allow quicker identification by eye. Additional options carried over from original feature request : Defined in Nextflow manifest BitBucket / GitLab organization icon