From 34202e77d8fb96079cced2759bc8a13d4ed6b7ea Mon Sep 17 00:00:00 2001 From: Justine Geffen Date: Fri, 20 Mar 2026 21:39:17 +0200 Subject: [PATCH 01/27] [feat] Revise production checklist for Seqera Platform [EDU-1080] Updated the production checklist for Seqera Platform, including changes to the last updated date and added sections on version pinning, compatibility, and connectivity requirements. Fixes https://seqera.atlassian.net/browse/EDU-1080 Signed-off-by: Justine Geffen --- .../getting-started/production-checklist.md | 119 +++++++++++++----- 1 file changed, 86 insertions(+), 33 deletions(-) diff --git a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md index cd57550e1..27927f9fe 100644 --- a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md +++ b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md @@ -2,11 +2,13 @@ title: "Production checklist" description: "A pre-production checklist for Seqera Platform." date created: "2025-07-03" -last updated: "2025-07-21" +last updated: "2026-03-20" tags: [production, checklist, deployment, limitations, retry] --- -This page provides guidance and best practices for your Seqera Platform deployment, and areas you should consider before you begin. We recommend working with your sales team for additional guidance around your particular infrastructure before going into production. +This page covers the Seqera Platform-specific configuration decisions that most commonly cause problems when moving from evaluation to production. It does not cover cloud infrastructure setup — your cloud team is responsible for networking, IAM, and compute configuration. + +For environment-specific production reviews, architecture guidance, or upgrade planning, contact your Seqera account team. ## Organizations and workspaces @@ -30,65 +32,116 @@ All users can be assigned roles that grant the type of access and permissions th It's a good idea to map out the expected users and their roles to ensure your plans are scalable. See [User roles](../orgs-and-teams/roles) for more information. -## Infrastructure +## Version pinning and compatibility + +Pin a specific Nextflow version for all production pipelines and document it alongside your Seqera Platform version. + +Incompatibilities between Nextflow and Platform versions are a leading cause of production failures, and often only surface during pipeline resumption after an interruption — not during normal runs. + +- Do not upgrade Nextflow and Seqera Platform at the same time. +- Validate any version change in a non-production environment before promoting to production. +- After any version change, test pipeline resumption explicitly: launch a representative pipeline, interrupt it, and confirm it resumes from the last successful task. + +:::warning +If you cannot resume a pipeline after a version upgrade, roll back to your last documented working version combination before investigating further. +::: + +## Credentials and token lifecycle -Infrastructure requirements vary widely depending on the workload you expect. See [Enterprise installation](../enterprise/overview) for an outline of Platform components. +Credentials in Seqera Platform require active management. Expired or rotated credentials that are not updated in Platform are a common cause of silent pipeline failures. -To begin, build out a proof of concept using the below recommendations and create a baseline of your capacity requirements. When you are ready to move to production, consider the increased workload. +**Before go-live:** -### Kubernetes +- Identify all credentials used by production pipelines: cloud provider credentials, Git tokens, container registry credentials, and API tokens. +- Record when each credential was created and when it expires. +- Assign a named owner responsible for rotating each credential. -When deploying Seqera Platform in a generic Kubernetes cluster we recommend starting with: +**When rotating credentials:** -- 4 vCPU -- 7 GB nodes +1. Add the new credential to the correct Seqera organization and workspaces. +2. Launch a test pipeline using the new credential and confirm it runs successfully. +3. Remove or deactivate the old credential only after step 2 is confirmed. -This sizing recommendation is a basic starting point. Your requirements may vary significantly based on the number of pipelines and concurrent processes you anticipate. See [Configure Pods and Containers](https://kubernetes.io/docs/tasks/configure-pod-container/) for information about increasing your resources. +:::warning +Do not rotate credentials during active pipeline runs. Schedule rotations during maintenance windows. +::: -### Docker +Use [Pipeline Secrets](../secrets/overview.mdx) to manage sensitive values such as API keys for third-party services. Secrets are injected at runtime and are not exposed in pipeline logs or configuration files. -When deploying Seqera Platform using Docker compose we recommend starting with: +## Compute environment permissions -- Instance size - `c5.2xlarge` -- External DB Aurora V3 provisioned - `db.t3.medium` -- External Redis - `cache.t2.micro` +Permissions within shared compute environments are a frequent source of unexpected behavior, particularly when multiple teams use the same workspace. -This sizing recommendation is a basic starting point. Your requirements may vary significantly based on the number of pipelines and concurrent processes you anticipate. See [Docker Resource constraints](https://docs.docker.com/engine/containers/resource_constraints/) for information about resource management in Docker. +- Use dedicated compute environments for production. Avoid sharing production compute environments with development or test workloads. +- Assign workspace roles at the level of access each user actually requires. The **Launch** role is appropriate for most researchers running established pipelines; **Maintain** is for users who need to configure compute environments and pipelines. +- Users in the same workspace can see and cancel each other's pipeline runs. If your organization requires run isolation between teams or projects, use separate workspaces. -### AWS +:::note +Admin-level workspace access grants the ability to modify compute environments and credentials, which can affect all pipelines in the workspace. Assign Admin only to users who are responsible for workspace configuration. +::: -When deploying Seqera Platform using AWS we recommend starting with: +For teams sharing pipelines across workspaces, use a [shared workspace](../orgs-and-teams/workspace-management#shared-workspaces) to centralize pipeline definitions and compute environments without duplicating configuration. -- Amazon Machine Image (AMI): Amazon Linux 2023 Optimized -- Instance type: `c5a.2xlarge` with 8 CPUs and 16 GB RAM -- A MySQL8 Community DB instance with minimum 2 vCPUs, 8 GB memory, and 30 GB SSD storage +## Cost tagging -This sizing recommendation is a basic starting point. Your requirements may vary significantly based on the number of pipelines and concurrent processes you anticipate. See [AWS Autoscaling documentation](https://aws.amazon.com/autoscaling/) for information about resource management in AWS. +Without resource labels, cloud billing reports cannot attribute compute costs to specific teams, projects, or pipelines. -### Azure +Define a tagging strategy before running production workloads. At minimum, tag by `environment`, `team`, and `pipeline`. Add `project` or `cost_center` tags if you need chargeback reporting. -When deploying Seqera Platform using Azure we recommend starting with: +Use [dynamic resource labels](../resource-labels/overview) to apply pipeline-specific tags to AWS Batch jobs automatically at run time. This enables cost attribution at the individual run level without manual configuration. -- Azure Linux VM with default values -- At least 2 CPUS and 8 GB RAM -- Ubuntu Server 22.04 LTS - Gen2 image -- A MySQL8 Community DB instance with minimum 2 vCPUs, 8 GB memory, and 30 GB SSD storage +:::warning +Cancelling a pipeline run in Seqera Platform does not guarantee immediate termination of the underlying cloud compute jobs. In some cases — particularly on AWS Batch — child jobs can continue running after Platform reports the run as cancelled or complete. Configure spend alerts in your cloud provider's billing tools independently of Platform, so that runaway compute costs are detected even if Platform does not surface them. +::: -These autoscale for pipeline runs, but the sizing recommendation will be based on the workload and can vary significantly based on the number of pipelines and concurrent processes you anticipate. See [Azure autoscaling documentation](https://learn.microsoft.com/en-us/azure/azure-monitor/autoscale/autoscale-get-started) for information about scaling in Azure. +:::note +The cost estimator in Seqera Platform is for indicative purposes only. For billing, budgeting, or chargeback, use your cloud provider's native cost reporting tools: AWS Cost Explorer, GCP Billing, or Azure Cost Management. +::: + +## Cost management and alerts + +Managing your compute spend upfront is a critical part of your production deployment. We recommend the following practices: + +- Utilize AWS Batch job tagging. This is facilitated by Nextflow's configuration and can be crucial in tracing costs back to specific pipelines. They can include dynamic variables and can be a valuable tool for helping diagnose and identify unexpected fees. This is especially helpful if you're using Nextflow outside of Seqera Platform. +- Note that CloudWatch fees are not included in your run cost estimates. ## Spot instance retry strategy One way to mitigate issues with Spot reclamation and the resulting interruptions is by having a robust retry and resume strategy. The are multiple options available to you: + - [Handle retries in Nextflow by setting `errorStrategy` and `maxRetries`](../tutorials/retry-strategy#handle-retries-in-nextflow-by-setting-errorstrategy-and-maxretries) - [Handle retries in AWS by setting `aws.batch.maxSpotAttempts`](../tutorials/retry-strategy#handle-retries-in-aws-by-setting-awsbatchmaxspotattempts) - [Implement Spot to On-Demand fallback logic](../tutorials/retry-strategy#implement-spot-to-on-demand-fallback-logic) Refer to [our retry strategy tutorial](../tutorials/retry-strategy) for more information. -## Cost management and alerts +## Connectivity requirements -Managing your compute spend upfront is a critical part of your production deployment. We recommend the following practices: +Seqera Platform requires outbound connectivity from compute worker nodes to specific endpoints. Blocked connections are a common cause of pipelines failing to start or stalling mid-run. + +Worker nodes must be able to reach: + +- Seqera Platform API and web endpoints — see [IP addresses and endpoints](../reference/endpoints.mdx) for the current list +- Your cloud provider's service endpoints — Batch, EC2 or Compute Engine, object storage, container registry +- Any container registries used by your pipelines (ECR, Artifact Registry, Docker Hub, or private registries) +- Any external data sources accessed at runtime + +If your environment uses SSL inspection or a corporate proxy, verify that it does not interfere with connections to Seqera Platform, object storage, or container registries. + +:::note +If pipelines fail to start or tasks cannot pull container images, connectivity to one of the above endpoints is the most common cause. Check worker node outbound access before investigating other causes. +::: + +## Before go-live + +- [ ] Nextflow version pinned and version combination documented +- [ ] Pipeline resumption tested after version validation +- [ ] All credentials inventoried with expiry dates and named owners +- [ ] New credentials tested before cutover; rotation procedure documented +- [ ] Production compute environments isolated from dev/test +- [ ] Workspace roles reviewed; Admin not granted broadly +- [ ] Resource labels defined and applied before first production run +- [ ] Cloud billing exports configured and spend alerts set +- [ ] Worker node outbound connectivity verified to all required endpoints -- Utilize AWS Batch job tagging. This is facilitated by Nextflow's configuration and can be crucial in tracing costs back to specific pipelines. They can include dynamic variables and can be a valuable tool for helping diagnose and identify unexpected fees. This is especially helpful if you're using Nextflow outside of Seqera Platform. -- Note that CloudWatch fees are not included in your run cost estimates. From d7eb7b754b40033622ecd9cbba86465b1d359225 Mon Sep 17 00:00:00 2001 From: Justine Geffen Date: Mon, 23 Mar 2026 12:11:18 +0200 Subject: [PATCH 02/27] Update platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md Co-authored-by: Chris Hakkaart Signed-off-by: Justine Geffen --- .../version-25.3/getting-started/production-checklist.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md index 27927f9fe..1039f8536 100644 --- a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md +++ b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md @@ -6,7 +6,7 @@ last updated: "2026-03-20" tags: [production, checklist, deployment, limitations, retry] --- -This page covers the Seqera Platform-specific configuration decisions that most commonly cause problems when moving from evaluation to production. It does not cover cloud infrastructure setup — your cloud team is responsible for networking, IAM, and compute configuration. +This page describes Seqera Platform-specific configuration decisions that commonly arise when transitioning from evaluation to production environments. Cloud infrastructure setup (e.g., networking, IAM, and compute configuration) is the responsibility of your cloud team and is not covered in this guide. For environment-specific production reviews, architecture guidance, or upgrade planning, contact your Seqera account team. From 4e36cecf34829ddda6d3105d1c80bd6d3aeaebdc Mon Sep 17 00:00:00 2001 From: Justine Geffen Date: Mon, 23 Mar 2026 12:11:28 +0200 Subject: [PATCH 03/27] Update platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md Co-authored-by: Chris Hakkaart Signed-off-by: Justine Geffen --- .../version-25.3/getting-started/production-checklist.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md index 1039f8536..db76849ba 100644 --- a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md +++ b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md @@ -34,10 +34,11 @@ It's a good idea to map out the expected users and their roles to ensure your pl ## Version pinning and compatibility -Pin a specific Nextflow version for all production pipelines and document it alongside your Seqera Platform version. - Incompatibilities between Nextflow and Platform versions are a leading cause of production failures, and often only surface during pipeline resumption after an interruption — not during normal runs. +Best practices for version pinning and compatibility include: + +- Pin a specific Nextflow version for all production pipelines and document it alongside your Seqera Platform version. - Do not upgrade Nextflow and Seqera Platform at the same time. - Validate any version change in a non-production environment before promoting to production. - After any version change, test pipeline resumption explicitly: launch a representative pipeline, interrupt it, and confirm it resumes from the last successful task. From 078ece9ce0de4c2a46dc3387478b90e1a2553153 Mon Sep 17 00:00:00 2001 From: Justine Geffen Date: Mon, 23 Mar 2026 12:11:36 +0200 Subject: [PATCH 04/27] Update platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md Co-authored-by: Chris Hakkaart Signed-off-by: Justine Geffen --- .../version-25.3/getting-started/production-checklist.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md index db76849ba..cbf8e01b2 100644 --- a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md +++ b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md @@ -73,9 +73,11 @@ Use [Pipeline Secrets](../secrets/overview.mdx) to manage sensitive values such Permissions within shared compute environments are a frequent source of unexpected behavior, particularly when multiple teams use the same workspace. -- Use dedicated compute environments for production. Avoid sharing production compute environments with development or test workloads. +Best practices for compute environment permissions include: + +- Use dedicated compute environments for production and avoid sharing production compute environments with development or test workloads. - Assign workspace roles at the level of access each user actually requires. The **Launch** role is appropriate for most researchers running established pipelines; **Maintain** is for users who need to configure compute environments and pipelines. -- Users in the same workspace can see and cancel each other's pipeline runs. If your organization requires run isolation between teams or projects, use separate workspaces. +- If your organization requires run isolation between teams or projects, use separate workspaces. Users in the same workspace can see and cancel each other's pipeline runs. :::note Admin-level workspace access grants the ability to modify compute environments and credentials, which can affect all pipelines in the workspace. Assign Admin only to users who are responsible for workspace configuration. From 54ece337e9fac4a5a6f3e6f788c71ead3094c9f2 Mon Sep 17 00:00:00 2001 From: Justine Geffen Date: Mon, 23 Mar 2026 12:11:50 +0200 Subject: [PATCH 05/27] Update platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md Co-authored-by: Chris Hakkaart Signed-off-by: Justine Geffen --- .../version-25.3/getting-started/production-checklist.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md index cbf8e01b2..9cb12a6b7 100644 --- a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md +++ b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md @@ -103,7 +103,9 @@ The cost estimator in Seqera Platform is for indicative purposes only. For billi ## Cost management and alerts -Managing your compute spend upfront is a critical part of your production deployment. We recommend the following practices: +Managing your compute spend upfront is a critical part of your production deployment. + +Best practices for cost management and alerts include: - Utilize AWS Batch job tagging. This is facilitated by Nextflow's configuration and can be crucial in tracing costs back to specific pipelines. They can include dynamic variables and can be a valuable tool for helping diagnose and identify unexpected fees. This is especially helpful if you're using Nextflow outside of Seqera Platform. - Note that CloudWatch fees are not included in your run cost estimates. From 35edda27b917cd34a19abf03ef671755f00fe066 Mon Sep 17 00:00:00 2001 From: Justine Geffen Date: Mon, 23 Mar 2026 12:11:58 +0200 Subject: [PATCH 06/27] Update platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md Co-authored-by: Chris Hakkaart Signed-off-by: Justine Geffen --- .../version-25.3/getting-started/production-checklist.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md index 9cb12a6b7..890dd1c77 100644 --- a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md +++ b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md @@ -88,10 +88,10 @@ For teams sharing pipelines across workspaces, use a [shared workspace](../orgs- ## Cost tagging Without resource labels, cloud billing reports cannot attribute compute costs to specific teams, projects, or pipelines. +Best practices for cost tagging include: -Define a tagging strategy before running production workloads. At minimum, tag by `environment`, `team`, and `pipeline`. Add `project` or `cost_center` tags if you need chargeback reporting. - -Use [dynamic resource labels](../resource-labels/overview) to apply pipeline-specific tags to AWS Batch jobs automatically at run time. This enables cost attribution at the individual run level without manual configuration. +- Define a tagging strategy before running production workloads. At minimum, tag by `environment`, `team`, and `pipeline`. Add `project` or `cost_center` tags if you need chargeback reporting. +- Use [dynamic resource labels](../resource-labels/overview) to apply pipeline-specific tags to AWS Batch jobs automatically at run time. This enables cost attribution at the individual run level without manual configuration. :::warning Cancelling a pipeline run in Seqera Platform does not guarantee immediate termination of the underlying cloud compute jobs. In some cases — particularly on AWS Batch — child jobs can continue running after Platform reports the run as cancelled or complete. Configure spend alerts in your cloud provider's billing tools independently of Platform, so that runaway compute costs are detected even if Platform does not surface them. From 60453e143df8cd6cf73f7d007804873685e1e7df Mon Sep 17 00:00:00 2001 From: Justine Geffen Date: Mon, 23 Mar 2026 12:12:06 +0200 Subject: [PATCH 07/27] Update platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md Co-authored-by: Chris Hakkaart Signed-off-by: Justine Geffen --- .../getting-started/production-checklist.md | 11 ----------- 1 file changed, 11 deletions(-) diff --git a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md index 890dd1c77..d8f97dd40 100644 --- a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md +++ b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md @@ -138,15 +138,4 @@ If your environment uses SSL inspection or a corporate proxy, verify that it doe If pipelines fail to start or tasks cannot pull container images, connectivity to one of the above endpoints is the most common cause. Check worker node outbound access before investigating other causes. ::: -## Before go-live - -- [ ] Nextflow version pinned and version combination documented -- [ ] Pipeline resumption tested after version validation -- [ ] All credentials inventoried with expiry dates and named owners -- [ ] New credentials tested before cutover; rotation procedure documented -- [ ] Production compute environments isolated from dev/test -- [ ] Workspace roles reviewed; Admin not granted broadly -- [ ] Resource labels defined and applied before first production run -- [ ] Cloud billing exports configured and spend alerts set -- [ ] Worker node outbound connectivity verified to all required endpoints From 78d875262bbaf8530cba34f128593dc2779669a1 Mon Sep 17 00:00:00 2001 From: Justine Geffen Date: Mon, 23 Mar 2026 12:12:36 +0200 Subject: [PATCH 08/27] Apply suggestion from @github-actions[bot] Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Signed-off-by: Justine Geffen --- .../version-25.3/getting-started/production-checklist.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md index d8f97dd40..1a59e38e6 100644 --- a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md +++ b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md @@ -6,7 +6,7 @@ last updated: "2026-03-20" tags: [production, checklist, deployment, limitations, retry] --- -This page describes Seqera Platform-specific configuration decisions that commonly arise when transitioning from evaluation to production environments. Cloud infrastructure setup (e.g., networking, IAM, and compute configuration) is the responsibility of your cloud team and is not covered in this guide. +This page describes Seqera Platform-specific configuration decisions that commonly arise when transitioning from evaluation to production environments. Cloud infrastructure setup (e.g., networking, IAM, and compute configuration) is the responsibility of your cloud team and is not covered in this guide. For environment-specific production reviews, architecture guidance, or upgrade planning, contact your Seqera account team. From 5632d49cf6a3170fac433440d460eb8a7880dec1 Mon Sep 17 00:00:00 2001 From: Justine Geffen Date: Mon, 23 Mar 2026 12:12:49 +0200 Subject: [PATCH 09/27] Apply suggestion from @github-actions[bot] Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Signed-off-by: Justine Geffen --- .../version-25.3/getting-started/production-checklist.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md index 1a59e38e6..1590c4c83 100644 --- a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md +++ b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md @@ -38,7 +38,7 @@ Incompatibilities between Nextflow and Platform versions are a leading cause of Best practices for version pinning and compatibility include: -- Pin a specific Nextflow version for all production pipelines and document it alongside your Seqera Platform version. +- Pin a specific Nextflow version for all production pipelines and document it alongside your Seqera Platform version. - Do not upgrade Nextflow and Seqera Platform at the same time. - Validate any version change in a non-production environment before promoting to production. - After any version change, test pipeline resumption explicitly: launch a representative pipeline, interrupt it, and confirm it resumes from the last successful task. From 864b53ef3eaa7e0c62f5d29064d13b1c99efd6e4 Mon Sep 17 00:00:00 2001 From: Justine Geffen Date: Mon, 23 Mar 2026 12:13:02 +0200 Subject: [PATCH 10/27] Update platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Signed-off-by: Justine Geffen --- .../version-25.3/getting-started/production-checklist.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md index 1590c4c83..45cd759e1 100644 --- a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md +++ b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md @@ -103,7 +103,7 @@ The cost estimator in Seqera Platform is for indicative purposes only. For billi ## Cost management and alerts -Managing your compute spend upfront is a critical part of your production deployment. +Managing your compute spend upfront is a critical part of your production deployment. Best practices for cost management and alerts include: From 21b66a6553d0ba2325a48e47ac9ea71679b55b39 Mon Sep 17 00:00:00 2001 From: Justine Geffen Date: Tue, 24 Mar 2026 23:07:58 +0200 Subject: [PATCH 11/27] Revise production checklist for Seqera Platform Updated the production checklist for Seqera Platform, including clarifications on organization structure, user roles, version compatibility, cache management, compute environment sizing, cost tagging, and connectivity requirements. Signed-off-by: Justine Geffen --- .../getting-started/production-checklist.md | 157 +++++++++++++----- 1 file changed, 113 insertions(+), 44 deletions(-) diff --git a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md index 45cd759e1..519382c99 100644 --- a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md +++ b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md @@ -2,62 +2,76 @@ title: "Production checklist" description: "A pre-production checklist for Seqera Platform." date created: "2025-07-03" -last updated: "2026-03-20" +last updated: "2026-03-24" tags: [production, checklist, deployment, limitations, retry] --- -This page describes Seqera Platform-specific configuration decisions that commonly arise when transitioning from evaluation to production environments. Cloud infrastructure setup (e.g., networking, IAM, and compute configuration) is the responsibility of your cloud team and is not covered in this guide. - -For environment-specific production reviews, architecture guidance, or upgrade planning, contact your Seqera account team. +This guide is for Platform administrators preparing a Seqera deployment for production use by scientific teams. It covers common configuration decisions, policies, and checks to consider before you run production workloads. Every deployment is different — your Seqera account team can help you tailor these recommendations to your environment and workloads. Cloud infrastructure setup such as networking, IAM, and compute provisioning is the responsibility of your infrastructure team and is not covered here. ## Organizations and workspaces -Organizations are the top-level structure and contain workspaces, members, and teams. +Organizations are the top-level structure in Seqera Platform and contain workspaces, members, and teams. You can create multiple organizations, each with multiple workspaces, to customize resource use and maintain access control across teams. + +Best practices for organizations and workspaces include: -You can create multiple organizations within Seqera Platform, each of which can contain multiple workspaces with shared users and resources. This means you can customize and organize the use of resources while maintaining an access control layer for users associated with a workspace. +- Plan your organization and workspace structure before go-live, considering the roles and work streams you expect to start with and scale to. +- Use separate workspaces to isolate production from development and test environments. +- Use a [shared workspace](../orgs-and-teams/workspace-management#shared-workspaces) to centralize pipeline definitions and compute environments without duplicating configuration across workspaces. -Before you create your organizations and workspaces, consider the various roles and work streams that you'd like to start with and scale to. See [Organizations](../orgs-and-teams/organizations) for more information. +See [Organizations](../orgs-and-teams/organizations) for more information. ## Users and roles -Once an organization is created, the user who created the organization is the default owner of that organization. Additional users can be assigned as organization owners. Owners have full read/write access to modify members, teams, collaborators, and settings within an organization. -Organization members have specific roles and permissions that define their access and capabilities: +Organization members are assigned roles that define their access and permissions within Platform. Each member has an organization role and can operate in one or more workspaces, where a participant role governs what they can do within that workspace. -- A member is a user who is internal to the organization. -- Members have an organization role and can operate in one or more organization workspaces. -- In each workspace, members have a participant role that defines the permissions granted to them within that workspace. -- Members can create their own workspaces within an organization and be part of a team. +Best practices for users and roles include: -All users can be assigned roles that grant the type of access and permissions they have to resources within Platform. +- Map out expected users and their roles before go-live to ensure your access model is scalable. +- Assign roles at the level of access each user actually requires rather than granting broad permissions by default. +- Limit organization owner assignment to users responsible for managing members, teams, and organization-level settings. -It's a good idea to map out the expected users and their roles to ensure your plans are scalable. See [User roles](../orgs-and-teams/roles) for more information. +See [User roles](../orgs-and-teams/roles) for more information. ## Version pinning and compatibility -Incompatibilities between Nextflow and Platform versions are a leading cause of production failures, and often only surface during pipeline resumption after an interruption — not during normal runs. +Incompatibilities between Nextflow and Platform versions are a leading cause of production failures, and often only surface during pipeline resumption after an interruption, not during normal runs. Best practices for version pinning and compatibility include: -- Pin a specific Nextflow version for all production pipelines and document it alongside your Seqera Platform version. -- Do not upgrade Nextflow and Seqera Platform at the same time. -- Validate any version change in a non-production environment before promoting to production. -- After any version change, test pipeline resumption explicitly: launch a representative pipeline, interrupt it, and confirm it resumes from the last successful task. +- Set the Nextflow version in the compute environment configuration before handing workspaces to scientific teams, and document it alongside the Seqera Platform version in use. +- Avoid performing Nextflow and Platform upgrades simultaneously, and validate all version changes in a non-production environment first. +- Coordinate with pipeline developers to confirm the current working version combination and agree on a rollback plan before any upgrade is scheduled. +- Before promoting a version change to production, ask pipeline teams to test resumption explicitly: launch a representative pipeline, interrupt it, and confirm it resumes from the last successful task. :::warning -If you cannot resume a pipeline after a version upgrade, roll back to your last documented working version combination before investigating further. +If pipeline teams cannot resume after a version upgrade, roll back to the last documented working version combination before investigating further. Resumption failure after an upgrade is typically a version incompatibility issue — contact your Seqera account team if you need help diagnosing it. ::: -## Credentials and token lifecycle +## Cache management + +Nextflow uses content-addressed caching to resume pipelines from the last successful task. Cache misconfiguration can lead to unexpected behavior during pipeline resumption. The administrator's role is to configure the storage environment that cache depends on, and to coordinate with pipeline teams to validate cache behavior before go-live. + +Best practices for cache management include: -Credentials in Seqera Platform require active management. Expired or rotated credentials that are not updated in Platform are a common cause of silent pipeline failures. +- Configure storage lifecycle policies to ensure that intermediate work directory objects are not removed while pipelines are still running or may need to resume. Coordinate these policies with your cloud team before go-live. +- Ask pipeline teams to validate cache integrity before go-live: run a representative pipeline, run it again, and confirm that cache hits occur and outputs match a clean run. +- Schedule Platform or Nextflow upgrades with pipeline teams in advance, and plan for the first post-upgrade production runs to take longer and cost more if cache is invalidated by a hash algorithm change. -**Before go-live:** +Your Seqera account team can help assess cache configuration for your specific workloads and storage setup. + +:::warning +After a Nextflow or Platform version upgrade, hash algorithms or cache key generation may change, causing all previously cached tasks to re-run. Inform pipeline teams before any upgrade so they can plan capacity and schedule accordingly — this is not a bug, but it will look like one if it happens without warning. +::: + +## Credentials and token lifecycle + +Credentials in Seqera Platform require active management. Expired or rotated credentials that are not updated in Platform are a common cause of silent pipeline failures. Before you go live: - Identify all credentials used by production pipelines: cloud provider credentials, Git tokens, container registry credentials, and API tokens. - Record when each credential was created and when it expires. - Assign a named owner responsible for rotating each credential. -**When rotating credentials:** +**When rotating credentials** 1. Add the new credential to the correct Seqera organization and workspaces. 2. Launch a test pipeline using the new credential and confirm it runs successfully. @@ -77,7 +91,7 @@ Best practices for compute environment permissions include: - Use dedicated compute environments for production and avoid sharing production compute environments with development or test workloads. - Assign workspace roles at the level of access each user actually requires. The **Launch** role is appropriate for most researchers running established pipelines; **Maintain** is for users who need to configure compute environments and pipelines. -- If your organization requires run isolation between teams or projects, use separate workspaces. Users in the same workspace can see and cancel each other's pipeline runs. +- Use separate workspaces if your organization requires run isolation between teams or projects. Users in the same workspace can see and cancel each other's pipeline runs. :::note Admin-level workspace access grants the ability to modify compute environments and credentials, which can affect all pipelines in the workspace. Assign Admin only to users who are responsible for workspace configuration. @@ -85,16 +99,38 @@ Admin-level workspace access grants the ability to modify compute environments a For teams sharing pipelines across workspaces, use a [shared workspace](../orgs-and-teams/workspace-management#shared-workspaces) to centralize pipeline definitions and compute environments without duplicating configuration. +## Compute environment sizing + +Correctly sizing compute environments before go-live prevents resource contention, job failures, and unexpected costs in production. + +Best practices for compute environment sizing include: + +- A typical starting range for max CPUs is 2000 to 5000, depending on your workload volume and concurrency needs. Your Seqera account team can advise on the best sizing for your environment. +- Consider enabling Fusion v2 with fast instance storage (NVMe) for I/O-intensive workloads on AWS. In tested benchmarks, this showed a 34% reduction in total pipeline runtime and up to 49% reduction in CPU hours compared to plain S3 storage. See [RNA-Seq performance benchmarks](../getting-started/rnaseq#nf-corernaseq-performance-in-platform) for details. +- Use the [pipeline optimization feature](../launch/optimization) to right-size resource allocations based on actual usage data. After a successful run, select the lightbulb icon next to the pipeline in the Launchpad to view and apply an optimized configuration profile. +- For GPU workloads such as protein structure prediction, use GPU-enabled instance families (`g4dn`, `g5`, or `p3` on AWS) and ensure the GPU ECS AMI is enabled in the compute environment configuration. + +:::warning +Studios do not support AWS Fargate. If you share a compute environment between pipelines and Studios, do not enable **Use Fargate for head job**. Enabling Fargate on a shared compute environment will prevent Studios sessions from starting. +::: + +:::note +Studio sessions compete for compute resources with pipeline runs in the same compute environment. For production workloads, use a dedicated compute environment for pipelines, or ensure the shared environment has sufficient capacity to accommodate both concurrently. +::: + +See [RNA-Seq](../getting-started/rnaseq) and [Protein structure prediction](../getting-started/proteinfold) for workload-specific compute environment recommendations. + ## Cost tagging Without resource labels, cloud billing reports cannot attribute compute costs to specific teams, projects, or pipelines. + Best practices for cost tagging include: - Define a tagging strategy before running production workloads. At minimum, tag by `environment`, `team`, and `pipeline`. Add `project` or `cost_center` tags if you need chargeback reporting. - Use [dynamic resource labels](../resource-labels/overview) to apply pipeline-specific tags to AWS Batch jobs automatically at run time. This enables cost attribution at the individual run level without manual configuration. :::warning -Cancelling a pipeline run in Seqera Platform does not guarantee immediate termination of the underlying cloud compute jobs. In some cases — particularly on AWS Batch — child jobs can continue running after Platform reports the run as cancelled or complete. Configure spend alerts in your cloud provider's billing tools independently of Platform, so that runaway compute costs are detected even if Platform does not surface them. +Cancelling a pipeline run in Seqera Platform does not guarantee immediate termination of the underlying cloud compute jobs. Configure spend alerts in your cloud provider's billing tools independently of Platform, so that runaway compute costs are detected even if Platform does not surface them. ::: :::note @@ -103,39 +139,72 @@ The cost estimator in Seqera Platform is for indicative purposes only. For billi ## Cost management and alerts -Managing your compute spend upfront is a critical part of your production deployment. +Managing compute spend before your workloads go live reduces the risk of unexpected charges in production. Best practices for cost management and alerts include: -- Utilize AWS Batch job tagging. This is facilitated by Nextflow's configuration and can be crucial in tracing costs back to specific pipelines. They can include dynamic variables and can be a valuable tool for helping diagnose and identify unexpected fees. This is especially helpful if you're using Nextflow outside of Seqera Platform. -- Note that CloudWatch fees are not included in your run cost estimates. +- Enable billing exports to your cloud provider's analytics tooling before running production workloads: AWS Cost Explorer or S3 export, GCP billing export to BigQuery, or Azure Cost Management. These give you the raw data needed to investigate unexpected charges. +- Set budget alerts in your cloud provider's billing tools to detect unexpected daily or weekly spend changes. On AWS, configure CloudWatch billing alarms; on GCP, use Cloud Monitoring budget alerts; on Azure, use Cost Management alert rules. +- On AWS, use [dynamic resource labels](../resource-labels/overview) to tag Batch jobs with pipeline-specific values at run time. Dynamic labels do not appear in AWS Cost Explorer's graphical UI — costs are tracked via AWS split cost allocation data in Cost and Usage Reports (CUR). Enable split cost allocation in the AWS billing console before expecting to see per-pipeline costs. See the [Seqera blog post on AWS labels cost tracking](https://seqera.io/blog/aws-labels-cost-tracking/) for setup guidance. +- On GCP, apply labels to Cloud Storage buckets, Filestore instances, and Compute Engine VMs in addition to Cloud Batch jobs. Label all resources consistently so BigQuery billing exports can attribute costs at the workload level. +- Account for CloudWatch fees separately on AWS as these are not included in Seqera Platform run cost estimates. ## Spot instance retry strategy -One way to mitigate issues with Spot reclamation and the resulting interruptions is by having a robust retry and resume strategy. The are multiple options available to you: +Spot reclamation interrupts pipeline execution when cloud providers reclaim capacity. The administrator configures the compute environment and Platform settings that make Spot workloads resilient; pipeline developers are responsible for the Nextflow-level retry configuration in their pipelines. Both should be in place before production runs begin. + +**Administrator configuration** +- Decide on the Spot vs On-Demand provisioning model for each production compute environment and configure the retry logic accordingly. +- Enable [Fusion Snapshots](https://docs.seqera.io/fusion/guide/snapshots) in the compute environment for Spot workloads. When a Spot instance is reclaimed, Fusion Snapshots allows the interrupted task to resume automatically from a checkpoint rather than restart from scratch. -- [Handle retries in Nextflow by setting `errorStrategy` and `maxRetries`](../tutorials/retry-strategy#handle-retries-in-nextflow-by-setting-errorstrategy-and-maxretries) -- [Handle retries in AWS by setting `aws.batch.maxSpotAttempts`](../tutorials/retry-strategy#handle-retries-in-aws-by-setting-awsbatchmaxspotattempts) -- [Implement Spot to On-Demand fallback logic](../tutorials/retry-strategy#implement-spot-to-on-demand-fallback-logic) +**Pipeline developer configuration** + +- `aws.batch.maxSpotAttempts` controls how many times a task is retried at the AWS Batch level before Nextflow sees it as a failure. See [Handle retries in AWS](../tutorials/retry-strategy#handle-retries-in-aws-by-setting-awsbatchmaxspotattempts). +- `errorStrategy` and `maxRetries` in Nextflow handle failures that survive all AWS-native retries. See [Handle retries in Nextflow](../tutorials/retry-strategy#handle-retries-in-nextflow-by-setting-errorstrategy-and-maxretries). +- Spot to On-Demand fallback logic should be implemented for tasks where interruption is unacceptable. See [Spot to On-Demand fallback](../tutorials/retry-strategy#implement-spot-to-on-demand-fallback-logic). + +:::note +`aws.batch.maxSpotAttempts` and Nextflow's `maxRetries` operate at independent layers. AWS-native Spot retries happen silently — Nextflow only sees the task as failed after all AWS retries are exhausted. Pipeline developers must set both values intentionally; neither is configured by Platform automatically. +::: -Refer to [our retry strategy tutorial](../tutorials/retry-strategy) for more information. +:::note +On GCP, Spot preemption notices can be as short as 6 seconds (compared to 120 seconds on AWS), making Fusion Snapshots especially important. Add the following to your Nextflow configuration: + +```groovy +fusion { + enabled = true + snapshots = true +} +``` +::: ## Connectivity requirements -Seqera Platform requires outbound connectivity from compute worker nodes to specific endpoints. Blocked connections are a common cause of pipelines failing to start or stalling mid-run. +Seqera Platform requires outbound connectivity from compute worker nodes to specific endpoints. Blocked connections are a common cause of pipelines failing to start or stalling mid-run. Worker nodes must be able to reach your cloud provider's service endpoints (Batch, EC2 or Compute Engine, object storage, container registry), any container registries used by your pipelines, and any external data sources accessed at runtime. -Worker nodes must be able to reach: +In addition, the following Seqera-operated domains must be reachable from your worker nodes. If your firewall supports DNS wildcards, add `*.seqera.io.cdn.cloudflare.net`. Otherwise, add each domain individually: -- Seqera Platform API and web endpoints — see [IP addresses and endpoints](../reference/endpoints.mdx) for the current list -- Your cloud provider's service endpoints — Batch, EC2 or Compute Engine, object storage, container registry -- Any container registries used by your pipelines (ECR, Artifact Registry, Docker Hub, or private registries) -- Any external data sources accessed at runtime +- `wave.seqera.io` and `community.wave.seqera.io` +- `fusionfs.seqera.io` +- `nf-xpack.seqera.io` +- `cr.seqera.io`, `public.cr.seqera.io`, and `auth.cr.seqera.io` +- `hub.seqera.io` +- `licenses.seqera.io` +- `registry.nextflow.io` — required from Nextflow 25.10 onwards +- `api.multiqc.info` +- For Seqera Cloud deployments: `cloud.seqera.io` and `api.cloud.seqera.io`. For Enterprise (self-hosted) deployments: your Platform instance hostname instead. -If your environment uses SSL inspection or a corporate proxy, verify that it does not interfere with connections to Seqera Platform, object storage, or container registries. +If your allowlist is based on IP addresses rather than DNS names, allow all Cloudflare IP ranges listed at [https://www.cloudflare.com/ips/](https://www.cloudflare.com/ips/). For a dynamic list of Seqera Platform egress IPs, query `https://meta.seqera.io`. -:::note -If pipelines fail to start or tasks cannot pull container images, connectivity to one of the above endpoints is the most common cause. Check worker node outbound access before investigating other causes. +If your environment uses SSL inspection or a corporate proxy, verify that it does not interfere with connections to Seqera Platform endpoints, object storage, or container registries. For Enterprise deployments in restricted or air-gapped environments, configure proxy settings on both the Platform instance and worker nodes, and provision an internal plugin registry to replace `registry.nextflow.io`. + +:::warning +From Nextflow 25.10, `registry.nextflow.io` is required for plugin resolution and is not included in older firewall allowlists. Pipelines will fail to start after upgrading to 25.10 if this domain is blocked. If your organization requires an internal plugin registry instead, see the [Nextflow 25.10 migration guide](https://www.nextflow.io/docs/latest/migrations/25-10.html). ::: +:::note +If pipelines fail to start or tasks cannot pull container images, connectivity to one of the above endpoints is the most common cause. Check worker node outbound access before investigating other causes. +See [Firewall configuration](../enterprise/advanced-topics/firewall-configuration) for the full allowlist reference. +::: From 2fc86d7d18b9415d2c2ed27db7f3bcfaee7667af Mon Sep 17 00:00:00 2001 From: Justine Geffen Date: Tue, 24 Mar 2026 23:16:09 +0200 Subject: [PATCH 12/27] Update production-checklist.md Signed-off-by: Justine Geffen --- .../version-25.3/getting-started/production-checklist.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md index 519382c99..cf937b0be 100644 --- a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md +++ b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md @@ -81,7 +81,7 @@ Credentials in Seqera Platform require active management. Expired or rotated cre Do not rotate credentials during active pipeline runs. Schedule rotations during maintenance windows. ::: -Use [Pipeline Secrets](../secrets/overview.mdx) to manage sensitive values such as API keys for third-party services. Secrets are injected at runtime and are not exposed in pipeline logs or configuration files. +Use [Pipeline Secrets](../secrets/overview) to manage sensitive values such as API keys for third-party services. Secrets are injected at runtime and are not exposed in pipeline logs or configuration files. ## Compute environment permissions From fad5c522294595c5ac1e26abcbf1fa2918c1f98b Mon Sep 17 00:00:00 2001 From: Justine Geffen Date: Tue, 24 Mar 2026 23:22:11 +0200 Subject: [PATCH 13/27] Update production-checklist.md Signed-off-by: Justine Geffen --- .../getting-started/production-checklist.md | 214 ++++++++++++++---- 1 file changed, 165 insertions(+), 49 deletions(-) diff --git a/platform-enterprise_docs/getting-started/production-checklist.md b/platform-enterprise_docs/getting-started/production-checklist.md index 1645a3785..cf937b0be 100644 --- a/platform-enterprise_docs/getting-started/production-checklist.md +++ b/platform-enterprise_docs/getting-started/production-checklist.md @@ -2,93 +2,209 @@ title: "Production checklist" description: "A pre-production checklist for Seqera Platform." date created: "2025-07-03" -last updated: "2026-01-30" +last updated: "2026-03-24" tags: [production, checklist, deployment, limitations, retry] --- -This page provides guidance and best practices for your Seqera Platform deployment, and areas you should consider before you begin. We recommend working with your sales team for additional guidance around your particular infrastructure before going into production. +This guide is for Platform administrators preparing a Seqera deployment for production use by scientific teams. It covers common configuration decisions, policies, and checks to consider before you run production workloads. Every deployment is different — your Seqera account team can help you tailor these recommendations to your environment and workloads. Cloud infrastructure setup such as networking, IAM, and compute provisioning is the responsibility of your infrastructure team and is not covered here. ## Organizations and workspaces -Organizations are the top-level structure and contain workspaces, members, and teams. +Organizations are the top-level structure in Seqera Platform and contain workspaces, members, and teams. You can create multiple organizations, each with multiple workspaces, to customize resource use and maintain access control across teams. -You can create multiple organizations within Seqera Platform, each of which can contain multiple workspaces with shared users and resources. This means you can customize and organize the use of resources while maintaining an access control layer for users associated with a workspace. +Best practices for organizations and workspaces include: -Before you create your organizations and workspaces, consider the various roles and work streams that you'd like to start with and scale to. See [Organizations](../orgs-and-teams/organizations) for more information. +- Plan your organization and workspace structure before go-live, considering the roles and work streams you expect to start with and scale to. +- Use separate workspaces to isolate production from development and test environments. +- Use a [shared workspace](../orgs-and-teams/workspace-management#shared-workspaces) to centralize pipeline definitions and compute environments without duplicating configuration across workspaces. + +See [Organizations](../orgs-and-teams/organizations) for more information. ## Users and roles -Once an organization is created, the user who created the organization is the default owner of that organization. Additional users can be assigned as organization owners. Owners have full read/write access to modify members, teams, collaborators, and settings within an organization. -Organization members have specific roles and permissions that define their access and capabilities: +Organization members are assigned roles that define their access and permissions within Platform. Each member has an organization role and can operate in one or more workspaces, where a participant role governs what they can do within that workspace. -- A member is a user who is internal to the organization. -- Members have an organization role and can operate in one or more organization workspaces. -- In each workspace, members have a participant role that defines the permissions granted to them within that workspace. -- Members can create their own workspaces within an organization and be part of a team. +Best practices for users and roles include: -All users can be assigned roles that grant the type of access and permissions they have to resources within Platform. +- Map out expected users and their roles before go-live to ensure your access model is scalable. +- Assign roles at the level of access each user actually requires rather than granting broad permissions by default. +- Limit organization owner assignment to users responsible for managing members, teams, and organization-level settings. -It's a good idea to map out the expected users and their roles to ensure your plans are scalable. See [User roles](../orgs-and-teams/roles) for more information. +See [User roles](../orgs-and-teams/roles) for more information. -## Infrastructure +## Version pinning and compatibility -Infrastructure requirements vary widely depending on the workload you expect. See [Enterprise installation](../enterprise/overview) for an outline of Platform components. +Incompatibilities between Nextflow and Platform versions are a leading cause of production failures, and often only surface during pipeline resumption after an interruption, not during normal runs. -To begin, build out a proof of concept using the below recommendations and create a baseline of your capacity requirements. When you are ready to move to production, consider the increased workload. +Best practices for version pinning and compatibility include: -### Kubernetes +- Set the Nextflow version in the compute environment configuration before handing workspaces to scientific teams, and document it alongside the Seqera Platform version in use. +- Avoid performing Nextflow and Platform upgrades simultaneously, and validate all version changes in a non-production environment first. +- Coordinate with pipeline developers to confirm the current working version combination and agree on a rollback plan before any upgrade is scheduled. +- Before promoting a version change to production, ask pipeline teams to test resumption explicitly: launch a representative pipeline, interrupt it, and confirm it resumes from the last successful task. -When deploying Seqera Platform in a generic Kubernetes cluster we recommend starting with: +:::warning +If pipeline teams cannot resume after a version upgrade, roll back to the last documented working version combination before investigating further. Resumption failure after an upgrade is typically a version incompatibility issue — contact your Seqera account team if you need help diagnosing it. +::: -- 4 vCPU -- 7 GB nodes +## Cache management -This sizing recommendation is a basic starting point. Your requirements may vary significantly based on the number of pipelines and concurrent processes you anticipate. See [Configure Pods and Containers](https://kubernetes.io/docs/tasks/configure-pod-container/) for information about increasing your resources. +Nextflow uses content-addressed caching to resume pipelines from the last successful task. Cache misconfiguration can lead to unexpected behavior during pipeline resumption. The administrator's role is to configure the storage environment that cache depends on, and to coordinate with pipeline teams to validate cache behavior before go-live. -### Docker +Best practices for cache management include: -When deploying Seqera Platform using Docker compose we recommend starting with: +- Configure storage lifecycle policies to ensure that intermediate work directory objects are not removed while pipelines are still running or may need to resume. Coordinate these policies with your cloud team before go-live. +- Ask pipeline teams to validate cache integrity before go-live: run a representative pipeline, run it again, and confirm that cache hits occur and outputs match a clean run. +- Schedule Platform or Nextflow upgrades with pipeline teams in advance, and plan for the first post-upgrade production runs to take longer and cost more if cache is invalidated by a hash algorithm change. -- Instance size - `c5.2xlarge` -- External DB Aurora V3 provisioned - `db.t3.medium` -- External Redis - `cache.t2.micro` +Your Seqera account team can help assess cache configuration for your specific workloads and storage setup. -This sizing recommendation is a basic starting point. Your requirements may vary significantly based on the number of pipelines and concurrent processes you anticipate. See [Docker Resource constraints](https://docs.docker.com/engine/containers/resource_constraints/) for information about resource management in Docker. +:::warning +After a Nextflow or Platform version upgrade, hash algorithms or cache key generation may change, causing all previously cached tasks to re-run. Inform pipeline teams before any upgrade so they can plan capacity and schedule accordingly — this is not a bug, but it will look like one if it happens without warning. +::: -### AWS +## Credentials and token lifecycle -When deploying Seqera Platform using AWS we recommend starting with: +Credentials in Seqera Platform require active management. Expired or rotated credentials that are not updated in Platform are a common cause of silent pipeline failures. Before you go live: -- Amazon Machine Image (AMI): Amazon Linux 2023 Optimized -- Instance type: `c5a.2xlarge` with 8 CPUs and 16 GB RAM -- A MySQL 8 Community DB instance with minimum 2 vCPUs, 8 GB memory, and 30 GB SSD storage +- Identify all credentials used by production pipelines: cloud provider credentials, Git tokens, container registry credentials, and API tokens. +- Record when each credential was created and when it expires. +- Assign a named owner responsible for rotating each credential. -This sizing recommendation is a basic starting point. Your requirements may vary significantly based on the number of pipelines and concurrent processes you anticipate. See [AWS Autoscaling documentation](https://aws.amazon.com/autoscaling/) for information about resource management in AWS. +**When rotating credentials** -### Azure +1. Add the new credential to the correct Seqera organization and workspaces. +2. Launch a test pipeline using the new credential and confirm it runs successfully. +3. Remove or deactivate the old credential only after step 2 is confirmed. -When deploying Seqera Platform using Azure we recommend starting with: +:::warning +Do not rotate credentials during active pipeline runs. Schedule rotations during maintenance windows. +::: -- Azure Linux VM with default values -- At least 2 CPUS and 8 GB RAM -- Ubuntu Server 22.04 LTS - Gen2 image -- A MySQL 8 Community DB instance with minimum 2 vCPUs, 8 GB memory, and 30 GB SSD storage +Use [Pipeline Secrets](../secrets/overview) to manage sensitive values such as API keys for third-party services. Secrets are injected at runtime and are not exposed in pipeline logs or configuration files. -These autoscale for pipeline runs, but the sizing recommendation will be based on the workload and can vary significantly based on the number of pipelines and concurrent processes you anticipate. See [Azure autoscaling documentation](https://learn.microsoft.com/en-us/azure/azure-monitor/autoscale/autoscale-get-started) for information about scaling in Azure. +## Compute environment permissions -## Spot instance retry strategy +Permissions within shared compute environments are a frequent source of unexpected behavior, particularly when multiple teams use the same workspace. + +Best practices for compute environment permissions include: + +- Use dedicated compute environments for production and avoid sharing production compute environments with development or test workloads. +- Assign workspace roles at the level of access each user actually requires. The **Launch** role is appropriate for most researchers running established pipelines; **Maintain** is for users who need to configure compute environments and pipelines. +- Use separate workspaces if your organization requires run isolation between teams or projects. Users in the same workspace can see and cancel each other's pipeline runs. + +:::note +Admin-level workspace access grants the ability to modify compute environments and credentials, which can affect all pipelines in the workspace. Assign Admin only to users who are responsible for workspace configuration. +::: + +For teams sharing pipelines across workspaces, use a [shared workspace](../orgs-and-teams/workspace-management#shared-workspaces) to centralize pipeline definitions and compute environments without duplicating configuration. + +## Compute environment sizing + +Correctly sizing compute environments before go-live prevents resource contention, job failures, and unexpected costs in production. + +Best practices for compute environment sizing include: -One way to mitigate issues with Spot reclamation and the resulting interruptions is by having a robust retry and resume strategy. The are multiple options available to you: +- A typical starting range for max CPUs is 2000 to 5000, depending on your workload volume and concurrency needs. Your Seqera account team can advise on the best sizing for your environment. +- Consider enabling Fusion v2 with fast instance storage (NVMe) for I/O-intensive workloads on AWS. In tested benchmarks, this showed a 34% reduction in total pipeline runtime and up to 49% reduction in CPU hours compared to plain S3 storage. See [RNA-Seq performance benchmarks](../getting-started/rnaseq#nf-corernaseq-performance-in-platform) for details. +- Use the [pipeline optimization feature](../launch/optimization) to right-size resource allocations based on actual usage data. After a successful run, select the lightbulb icon next to the pipeline in the Launchpad to view and apply an optimized configuration profile. +- For GPU workloads such as protein structure prediction, use GPU-enabled instance families (`g4dn`, `g5`, or `p3` on AWS) and ensure the GPU ECS AMI is enabled in the compute environment configuration. -- [Handle retries in Nextflow by setting `errorStrategy` and `maxRetries`](../tutorials/retry-strategy#handle-retries-in-nextflow-by-setting-errorstrategy-and-maxretries) -- [Handle retries in AWS by setting `aws.batch.maxSpotAttempts`](../tutorials/retry-strategy#handle-retries-in-aws-by-setting-awsbatchmaxspotattempts) -- [Implement Spot to On-Demand fallback logic](../tutorials/retry-strategy#implement-spot-to-on-demand-fallback-logic) +:::warning +Studios do not support AWS Fargate. If you share a compute environment between pipelines and Studios, do not enable **Use Fargate for head job**. Enabling Fargate on a shared compute environment will prevent Studios sessions from starting. +::: -Refer to [our retry strategy tutorial](../tutorials/retry-strategy) for more information. +:::note +Studio sessions compete for compute resources with pipeline runs in the same compute environment. For production workloads, use a dedicated compute environment for pipelines, or ensure the shared environment has sufficient capacity to accommodate both concurrently. +::: + +See [RNA-Seq](../getting-started/rnaseq) and [Protein structure prediction](../getting-started/proteinfold) for workload-specific compute environment recommendations. + +## Cost tagging + +Without resource labels, cloud billing reports cannot attribute compute costs to specific teams, projects, or pipelines. + +Best practices for cost tagging include: + +- Define a tagging strategy before running production workloads. At minimum, tag by `environment`, `team`, and `pipeline`. Add `project` or `cost_center` tags if you need chargeback reporting. +- Use [dynamic resource labels](../resource-labels/overview) to apply pipeline-specific tags to AWS Batch jobs automatically at run time. This enables cost attribution at the individual run level without manual configuration. + +:::warning +Cancelling a pipeline run in Seqera Platform does not guarantee immediate termination of the underlying cloud compute jobs. Configure spend alerts in your cloud provider's billing tools independently of Platform, so that runaway compute costs are detected even if Platform does not surface them. +::: + +:::note +The cost estimator in Seqera Platform is for indicative purposes only. For billing, budgeting, or chargeback, use your cloud provider's native cost reporting tools: AWS Cost Explorer, GCP Billing, or Azure Cost Management. +::: ## Cost management and alerts -Managing your compute spend upfront is a critical part of your production deployment. We recommend the following practices: +Managing compute spend before your workloads go live reduces the risk of unexpected charges in production. + +Best practices for cost management and alerts include: + +- Enable billing exports to your cloud provider's analytics tooling before running production workloads: AWS Cost Explorer or S3 export, GCP billing export to BigQuery, or Azure Cost Management. These give you the raw data needed to investigate unexpected charges. +- Set budget alerts in your cloud provider's billing tools to detect unexpected daily or weekly spend changes. On AWS, configure CloudWatch billing alarms; on GCP, use Cloud Monitoring budget alerts; on Azure, use Cost Management alert rules. +- On AWS, use [dynamic resource labels](../resource-labels/overview) to tag Batch jobs with pipeline-specific values at run time. Dynamic labels do not appear in AWS Cost Explorer's graphical UI — costs are tracked via AWS split cost allocation data in Cost and Usage Reports (CUR). Enable split cost allocation in the AWS billing console before expecting to see per-pipeline costs. See the [Seqera blog post on AWS labels cost tracking](https://seqera.io/blog/aws-labels-cost-tracking/) for setup guidance. +- On GCP, apply labels to Cloud Storage buckets, Filestore instances, and Compute Engine VMs in addition to Cloud Batch jobs. Label all resources consistently so BigQuery billing exports can attribute costs at the workload level. +- Account for CloudWatch fees separately on AWS as these are not included in Seqera Platform run cost estimates. + +## Spot instance retry strategy + +Spot reclamation interrupts pipeline execution when cloud providers reclaim capacity. The administrator configures the compute environment and Platform settings that make Spot workloads resilient; pipeline developers are responsible for the Nextflow-level retry configuration in their pipelines. Both should be in place before production runs begin. + +**Administrator configuration** + +- Decide on the Spot vs On-Demand provisioning model for each production compute environment and configure the retry logic accordingly. +- Enable [Fusion Snapshots](https://docs.seqera.io/fusion/guide/snapshots) in the compute environment for Spot workloads. When a Spot instance is reclaimed, Fusion Snapshots allows the interrupted task to resume automatically from a checkpoint rather than restart from scratch. + +**Pipeline developer configuration** + +- `aws.batch.maxSpotAttempts` controls how many times a task is retried at the AWS Batch level before Nextflow sees it as a failure. See [Handle retries in AWS](../tutorials/retry-strategy#handle-retries-in-aws-by-setting-awsbatchmaxspotattempts). +- `errorStrategy` and `maxRetries` in Nextflow handle failures that survive all AWS-native retries. See [Handle retries in Nextflow](../tutorials/retry-strategy#handle-retries-in-nextflow-by-setting-errorstrategy-and-maxretries). +- Spot to On-Demand fallback logic should be implemented for tasks where interruption is unacceptable. See [Spot to On-Demand fallback](../tutorials/retry-strategy#implement-spot-to-on-demand-fallback-logic). + +:::note +`aws.batch.maxSpotAttempts` and Nextflow's `maxRetries` operate at independent layers. AWS-native Spot retries happen silently — Nextflow only sees the task as failed after all AWS retries are exhausted. Pipeline developers must set both values intentionally; neither is configured by Platform automatically. +::: + +:::note +On GCP, Spot preemption notices can be as short as 6 seconds (compared to 120 seconds on AWS), making Fusion Snapshots especially important. Add the following to your Nextflow configuration: + +```groovy +fusion { + enabled = true + snapshots = true +} +``` +::: + +## Connectivity requirements + +Seqera Platform requires outbound connectivity from compute worker nodes to specific endpoints. Blocked connections are a common cause of pipelines failing to start or stalling mid-run. Worker nodes must be able to reach your cloud provider's service endpoints (Batch, EC2 or Compute Engine, object storage, container registry), any container registries used by your pipelines, and any external data sources accessed at runtime. + +In addition, the following Seqera-operated domains must be reachable from your worker nodes. If your firewall supports DNS wildcards, add `*.seqera.io.cdn.cloudflare.net`. Otherwise, add each domain individually: + +- `wave.seqera.io` and `community.wave.seqera.io` +- `fusionfs.seqera.io` +- `nf-xpack.seqera.io` +- `cr.seqera.io`, `public.cr.seqera.io`, and `auth.cr.seqera.io` +- `hub.seqera.io` +- `licenses.seqera.io` +- `registry.nextflow.io` — required from Nextflow 25.10 onwards +- `api.multiqc.info` +- For Seqera Cloud deployments: `cloud.seqera.io` and `api.cloud.seqera.io`. For Enterprise (self-hosted) deployments: your Platform instance hostname instead. + +If your allowlist is based on IP addresses rather than DNS names, allow all Cloudflare IP ranges listed at [https://www.cloudflare.com/ips/](https://www.cloudflare.com/ips/). For a dynamic list of Seqera Platform egress IPs, query `https://meta.seqera.io`. + +If your environment uses SSL inspection or a corporate proxy, verify that it does not interfere with connections to Seqera Platform endpoints, object storage, or container registries. For Enterprise deployments in restricted or air-gapped environments, configure proxy settings on both the Platform instance and worker nodes, and provision an internal plugin registry to replace `registry.nextflow.io`. + +:::warning +From Nextflow 25.10, `registry.nextflow.io` is required for plugin resolution and is not included in older firewall allowlists. Pipelines will fail to start after upgrading to 25.10 if this domain is blocked. If your organization requires an internal plugin registry instead, see the [Nextflow 25.10 migration guide](https://www.nextflow.io/docs/latest/migrations/25-10.html). +::: + +:::note +If pipelines fail to start or tasks cannot pull container images, connectivity to one of the above endpoints is the most common cause. Check worker node outbound access before investigating other causes. -- Utilize AWS Batch job tagging. This is facilitated by Nextflow's configuration and can be crucial in tracing costs back to specific pipelines. They can include dynamic variables and can be a valuable tool for helping diagnose and identify unexpected fees. This is especially helpful if you're using Nextflow outside of Seqera Platform. -- Note that CloudWatch fees are not included in your run cost estimates. +See [Firewall configuration](../enterprise/advanced-topics/firewall-configuration) for the full allowlist reference. +::: From 45ecab04c71a1050fae100d5bf721384d2664ccf Mon Sep 17 00:00:00 2001 From: Justine Geffen Date: Wed, 25 Mar 2026 15:28:10 +0200 Subject: [PATCH 14/27] Add production checklist to sidebar links Signed-off-by: Justine Geffen --- platform-enterprise_docs/enterprise-sidebar.json | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/platform-enterprise_docs/enterprise-sidebar.json b/platform-enterprise_docs/enterprise-sidebar.json index 156e7832a..a22110dc6 100644 --- a/platform-enterprise_docs/enterprise-sidebar.json +++ b/platform-enterprise_docs/enterprise-sidebar.json @@ -125,7 +125,8 @@ "getting-started/quickstart-demo/add-data", "getting-started/quickstart-demo/launch-pipelines", "getting-started/quickstart-demo/monitor-runs", - "getting-started/quickstart-demo/automation" + "getting-started/quickstart-demo/automation", + "getting-started/production-checklist" ] }, { From 37c65ece3411f1d9b078f98ffb826a6e3b9af59f Mon Sep 17 00:00:00 2001 From: Justine Geffen Date: Wed, 25 Mar 2026 15:28:47 +0200 Subject: [PATCH 15/27] Add production checklist to version 25.3 sidebars Signed-off-by: Justine Geffen --- .../version-25.3-sidebars.json | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/platform-enterprise_versioned_sidebars/version-25.3-sidebars.json b/platform-enterprise_versioned_sidebars/version-25.3-sidebars.json index 97626c65b..7f9fa31ad 100644 --- a/platform-enterprise_versioned_sidebars/version-25.3-sidebars.json +++ b/platform-enterprise_versioned_sidebars/version-25.3-sidebars.json @@ -125,7 +125,8 @@ "getting-started/quickstart-demo/add-data", "getting-started/quickstart-demo/launch-pipelines", "getting-started/quickstart-demo/monitor-runs", - "getting-started/quickstart-demo/automation" + "getting-started/quickstart-demo/automation", + "getting-started/production-checklist" ] }, { From 5e37943a9ddbe68113e2295dd77679821d8fd2ab Mon Sep 17 00:00:00 2001 From: Justine Geffen Date: Wed, 25 Mar 2026 15:59:47 +0200 Subject: [PATCH 16/27] Updated broken link --- .../getting-started/production-checklist.md | 2 +- .../version-25.3/getting-started/production-checklist.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/platform-enterprise_docs/getting-started/production-checklist.md b/platform-enterprise_docs/getting-started/production-checklist.md index cf937b0be..6b2360338 100644 --- a/platform-enterprise_docs/getting-started/production-checklist.md +++ b/platform-enterprise_docs/getting-started/production-checklist.md @@ -107,7 +107,7 @@ Best practices for compute environment sizing include: - A typical starting range for max CPUs is 2000 to 5000, depending on your workload volume and concurrency needs. Your Seqera account team can advise on the best sizing for your environment. - Consider enabling Fusion v2 with fast instance storage (NVMe) for I/O-intensive workloads on AWS. In tested benchmarks, this showed a 34% reduction in total pipeline runtime and up to 49% reduction in CPU hours compared to plain S3 storage. See [RNA-Seq performance benchmarks](../getting-started/rnaseq#nf-corernaseq-performance-in-platform) for details. -- Use the [pipeline optimization feature](../launch/optimization) to right-size resource allocations based on actual usage data. After a successful run, select the lightbulb icon next to the pipeline in the Launchpad to view and apply an optimized configuration profile. +- Use the [pipeline optimization feature](../pipeline-optimization/overview) to right-size resource allocations based on actual usage data. After a successful run, select the lightbulb icon next to the pipeline in the Launchpad to view and apply an optimized configuration profile. - For GPU workloads such as protein structure prediction, use GPU-enabled instance families (`g4dn`, `g5`, or `p3` on AWS) and ensure the GPU ECS AMI is enabled in the compute environment configuration. :::warning diff --git a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md index cf937b0be..6b2360338 100644 --- a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md +++ b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md @@ -107,7 +107,7 @@ Best practices for compute environment sizing include: - A typical starting range for max CPUs is 2000 to 5000, depending on your workload volume and concurrency needs. Your Seqera account team can advise on the best sizing for your environment. - Consider enabling Fusion v2 with fast instance storage (NVMe) for I/O-intensive workloads on AWS. In tested benchmarks, this showed a 34% reduction in total pipeline runtime and up to 49% reduction in CPU hours compared to plain S3 storage. See [RNA-Seq performance benchmarks](../getting-started/rnaseq#nf-corernaseq-performance-in-platform) for details. -- Use the [pipeline optimization feature](../launch/optimization) to right-size resource allocations based on actual usage data. After a successful run, select the lightbulb icon next to the pipeline in the Launchpad to view and apply an optimized configuration profile. +- Use the [pipeline optimization feature](../pipeline-optimization/overview) to right-size resource allocations based on actual usage data. After a successful run, select the lightbulb icon next to the pipeline in the Launchpad to view and apply an optimized configuration profile. - For GPU workloads such as protein structure prediction, use GPU-enabled instance families (`g4dn`, `g5`, or `p3` on AWS) and ensure the GPU ECS AMI is enabled in the compute environment configuration. :::warning From 7d26474ba511fd4fd046c11313b2c49c4babb667 Mon Sep 17 00:00:00 2001 From: Justine Geffen Date: Wed, 25 Mar 2026 18:58:38 +0200 Subject: [PATCH 17/27] updates and link fixes --- .../getting-started/production-checklist.md | 18 +++++++++--------- .../version-25.3/getting-started/overview.md | 2 +- .../getting-started/production-checklist.md | 18 +++++++++--------- .../version-25.3/limits/overview.md | 15 ++++++++------- .../orgs-and-teams/workspace-management.md | 8 ++++---- 5 files changed, 31 insertions(+), 30 deletions(-) diff --git a/platform-enterprise_docs/getting-started/production-checklist.md b/platform-enterprise_docs/getting-started/production-checklist.md index 6b2360338..2c1097a10 100644 --- a/platform-enterprise_docs/getting-started/production-checklist.md +++ b/platform-enterprise_docs/getting-started/production-checklist.md @@ -2,11 +2,11 @@ title: "Production checklist" description: "A pre-production checklist for Seqera Platform." date created: "2025-07-03" -last updated: "2026-03-24" +last updated: "2026-03-25" tags: [production, checklist, deployment, limitations, retry] --- -This guide is for Platform administrators preparing a Seqera deployment for production use by scientific teams. It covers common configuration decisions, policies, and checks to consider before you run production workloads. Every deployment is different — your Seqera account team can help you tailor these recommendations to your environment and workloads. Cloud infrastructure setup such as networking, IAM, and compute provisioning is the responsibility of your infrastructure team and is not covered here. +This guide is for Platform administrators preparing a Seqera deployment for production use by scientific teams. It covers common configuration decisions, policies, and checks to consider before you run production workloads. Because every deployment is different, your Seqera account team can help you tailor these recommendations to your environment and workloads. Cloud infrastructure setup such as networking, IAM, and compute provisioning is the responsibility of your infrastructure team and is not covered here. ## Organizations and workspaces @@ -14,15 +14,15 @@ Organizations are the top-level structure in Seqera Platform and contain workspa Best practices for organizations and workspaces include: -- Plan your organization and workspace structure before go-live, considering the roles and work streams you expect to start with and scale to. +- Plan your organization and workspace structure, considering the roles and work streams you expect to start with and scale to. - Use separate workspaces to isolate production from development and test environments. -- Use a [shared workspace](../orgs-and-teams/workspace-management#shared-workspaces) to centralize pipeline definitions and compute environments without duplicating configuration across workspaces. +- Use a [shared workspace](../orgs-and-teams/workspace-management#create-a-shared-workspace) to centralize pipeline definitions and compute environments without duplicating configuration across workspaces. See [Organizations](../orgs-and-teams/organizations) for more information. ## Users and roles -Organization members are assigned roles that define their access and permissions within Platform. Each member has an organization role and can operate in one or more workspaces, where a participant role governs what they can do within that workspace. +Roles define an organization member's access and permissions within Platform. Each member has an organization role and can operate in one or more workspaces, where a participant role governs what they can do within that workspace. Best practices for users and roles include: @@ -40,11 +40,11 @@ Best practices for version pinning and compatibility include: - Set the Nextflow version in the compute environment configuration before handing workspaces to scientific teams, and document it alongside the Seqera Platform version in use. - Avoid performing Nextflow and Platform upgrades simultaneously, and validate all version changes in a non-production environment first. -- Coordinate with pipeline developers to confirm the current working version combination and agree on a rollback plan before any upgrade is scheduled. +- Coordinate with pipeline developers to confirm the current working version combination and agree on a rollback plan before you schedule any upgrades. - Before promoting a version change to production, ask pipeline teams to test resumption explicitly: launch a representative pipeline, interrupt it, and confirm it resumes from the last successful task. :::warning -If pipeline teams cannot resume after a version upgrade, roll back to the last documented working version combination before investigating further. Resumption failure after an upgrade is typically a version incompatibility issue — contact your Seqera account team if you need help diagnosing it. +Resumption failure after an upgrade typically indicates a version incompatibility issue. If pipeline teams cannot resume after a version upgrade, roll back to the last documented working version combination before investigating further. ::: ## Cache management @@ -60,7 +60,7 @@ Best practices for cache management include: Your Seqera account team can help assess cache configuration for your specific workloads and storage setup. :::warning -After a Nextflow or Platform version upgrade, hash algorithms or cache key generation may change, causing all previously cached tasks to re-run. Inform pipeline teams before any upgrade so they can plan capacity and schedule accordingly — this is not a bug, but it will look like one if it happens without warning. +After a Nextflow or Platform version upgrade, hash algorithms or cache key generation may change, causing all previously cached tasks to re-run. Inform pipeline teams before any upgrade so they can plan capacity and schedule accordingly; this is not a bug, but it will look like one if it happens without warning. ::: ## Credentials and token lifecycle @@ -145,7 +145,7 @@ Best practices for cost management and alerts include: - Enable billing exports to your cloud provider's analytics tooling before running production workloads: AWS Cost Explorer or S3 export, GCP billing export to BigQuery, or Azure Cost Management. These give you the raw data needed to investigate unexpected charges. - Set budget alerts in your cloud provider's billing tools to detect unexpected daily or weekly spend changes. On AWS, configure CloudWatch billing alarms; on GCP, use Cloud Monitoring budget alerts; on Azure, use Cost Management alert rules. -- On AWS, use [dynamic resource labels](../resource-labels/overview) to tag Batch jobs with pipeline-specific values at run time. Dynamic labels do not appear in AWS Cost Explorer's graphical UI — costs are tracked via AWS split cost allocation data in Cost and Usage Reports (CUR). Enable split cost allocation in the AWS billing console before expecting to see per-pipeline costs. See the [Seqera blog post on AWS labels cost tracking](https://seqera.io/blog/aws-labels-cost-tracking/) for setup guidance. +- On AWS, use [dynamic resource labels](../resource-labels/overview) to tag Batch jobs with pipeline-specific values at run time. Dynamic labels do not appear in AWS Cost Explorer's graphical UI. Costs are tracked via AWS split cost allocation data in Cost and Usage Reports (CUR). Enable split cost allocation in the AWS billing console before expecting to see per-pipeline costs. See the [Seqera blog post on AWS labels cost tracking](https://seqera.io/blog/aws-labels-cost-tracking/) for setup guidance. - On GCP, apply labels to Cloud Storage buckets, Filestore instances, and Compute Engine VMs in addition to Cloud Batch jobs. Label all resources consistently so BigQuery billing exports can attribute costs at the workload level. - Account for CloudWatch fees separately on AWS as these are not included in Seqera Platform run cost estimates. diff --git a/platform-enterprise_versioned_docs/version-25.3/getting-started/overview.md b/platform-enterprise_versioned_docs/version-25.3/getting-started/overview.md index c655fa72d..a431d2481 100644 --- a/platform-enterprise_versioned_docs/version-25.3/getting-started/overview.md +++ b/platform-enterprise_versioned_docs/version-25.3/getting-started/overview.md @@ -1,7 +1,7 @@ --- title: "Run a pipeline" description: "An overview of Seqera Platform deployment versions and ways to run Seqera." -date: "15 September 2023" +date created: "2023-09-15" tags: [overview] --- diff --git a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md index 6b2360338..2c1097a10 100644 --- a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md +++ b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md @@ -2,11 +2,11 @@ title: "Production checklist" description: "A pre-production checklist for Seqera Platform." date created: "2025-07-03" -last updated: "2026-03-24" +last updated: "2026-03-25" tags: [production, checklist, deployment, limitations, retry] --- -This guide is for Platform administrators preparing a Seqera deployment for production use by scientific teams. It covers common configuration decisions, policies, and checks to consider before you run production workloads. Every deployment is different — your Seqera account team can help you tailor these recommendations to your environment and workloads. Cloud infrastructure setup such as networking, IAM, and compute provisioning is the responsibility of your infrastructure team and is not covered here. +This guide is for Platform administrators preparing a Seqera deployment for production use by scientific teams. It covers common configuration decisions, policies, and checks to consider before you run production workloads. Because every deployment is different, your Seqera account team can help you tailor these recommendations to your environment and workloads. Cloud infrastructure setup such as networking, IAM, and compute provisioning is the responsibility of your infrastructure team and is not covered here. ## Organizations and workspaces @@ -14,15 +14,15 @@ Organizations are the top-level structure in Seqera Platform and contain workspa Best practices for organizations and workspaces include: -- Plan your organization and workspace structure before go-live, considering the roles and work streams you expect to start with and scale to. +- Plan your organization and workspace structure, considering the roles and work streams you expect to start with and scale to. - Use separate workspaces to isolate production from development and test environments. -- Use a [shared workspace](../orgs-and-teams/workspace-management#shared-workspaces) to centralize pipeline definitions and compute environments without duplicating configuration across workspaces. +- Use a [shared workspace](../orgs-and-teams/workspace-management#create-a-shared-workspace) to centralize pipeline definitions and compute environments without duplicating configuration across workspaces. See [Organizations](../orgs-and-teams/organizations) for more information. ## Users and roles -Organization members are assigned roles that define their access and permissions within Platform. Each member has an organization role and can operate in one or more workspaces, where a participant role governs what they can do within that workspace. +Roles define an organization member's access and permissions within Platform. Each member has an organization role and can operate in one or more workspaces, where a participant role governs what they can do within that workspace. Best practices for users and roles include: @@ -40,11 +40,11 @@ Best practices for version pinning and compatibility include: - Set the Nextflow version in the compute environment configuration before handing workspaces to scientific teams, and document it alongside the Seqera Platform version in use. - Avoid performing Nextflow and Platform upgrades simultaneously, and validate all version changes in a non-production environment first. -- Coordinate with pipeline developers to confirm the current working version combination and agree on a rollback plan before any upgrade is scheduled. +- Coordinate with pipeline developers to confirm the current working version combination and agree on a rollback plan before you schedule any upgrades. - Before promoting a version change to production, ask pipeline teams to test resumption explicitly: launch a representative pipeline, interrupt it, and confirm it resumes from the last successful task. :::warning -If pipeline teams cannot resume after a version upgrade, roll back to the last documented working version combination before investigating further. Resumption failure after an upgrade is typically a version incompatibility issue — contact your Seqera account team if you need help diagnosing it. +Resumption failure after an upgrade typically indicates a version incompatibility issue. If pipeline teams cannot resume after a version upgrade, roll back to the last documented working version combination before investigating further. ::: ## Cache management @@ -60,7 +60,7 @@ Best practices for cache management include: Your Seqera account team can help assess cache configuration for your specific workloads and storage setup. :::warning -After a Nextflow or Platform version upgrade, hash algorithms or cache key generation may change, causing all previously cached tasks to re-run. Inform pipeline teams before any upgrade so they can plan capacity and schedule accordingly — this is not a bug, but it will look like one if it happens without warning. +After a Nextflow or Platform version upgrade, hash algorithms or cache key generation may change, causing all previously cached tasks to re-run. Inform pipeline teams before any upgrade so they can plan capacity and schedule accordingly; this is not a bug, but it will look like one if it happens without warning. ::: ## Credentials and token lifecycle @@ -145,7 +145,7 @@ Best practices for cost management and alerts include: - Enable billing exports to your cloud provider's analytics tooling before running production workloads: AWS Cost Explorer or S3 export, GCP billing export to BigQuery, or Azure Cost Management. These give you the raw data needed to investigate unexpected charges. - Set budget alerts in your cloud provider's billing tools to detect unexpected daily or weekly spend changes. On AWS, configure CloudWatch billing alarms; on GCP, use Cloud Monitoring budget alerts; on Azure, use Cost Management alert rules. -- On AWS, use [dynamic resource labels](../resource-labels/overview) to tag Batch jobs with pipeline-specific values at run time. Dynamic labels do not appear in AWS Cost Explorer's graphical UI — costs are tracked via AWS split cost allocation data in Cost and Usage Reports (CUR). Enable split cost allocation in the AWS billing console before expecting to see per-pipeline costs. See the [Seqera blog post on AWS labels cost tracking](https://seqera.io/blog/aws-labels-cost-tracking/) for setup guidance. +- On AWS, use [dynamic resource labels](../resource-labels/overview) to tag Batch jobs with pipeline-specific values at run time. Dynamic labels do not appear in AWS Cost Explorer's graphical UI. Costs are tracked via AWS split cost allocation data in Cost and Usage Reports (CUR). Enable split cost allocation in the AWS billing console before expecting to see per-pipeline costs. See the [Seqera blog post on AWS labels cost tracking](https://seqera.io/blog/aws-labels-cost-tracking/) for setup guidance. - On GCP, apply labels to Cloud Storage buckets, Filestore instances, and Compute Engine VMs in addition to Cloud Batch jobs. Label all resources consistently so BigQuery billing exports can attribute costs at the workload level. - Account for CloudWatch fees separately on AWS as these are not included in Seqera Platform run cost estimates. diff --git a/platform-enterprise_versioned_docs/version-25.3/limits/overview.md b/platform-enterprise_versioned_docs/version-25.3/limits/overview.md index 61ccae8be..10a6095de 100644 --- a/platform-enterprise_versioned_docs/version-25.3/limits/overview.md +++ b/platform-enterprise_versioned_docs/version-25.3/limits/overview.md @@ -1,15 +1,16 @@ --- title: "Usage limits" -description: "An overview of Seqera Cloud usage limits" -date: "19 Feb 2025" -tags: [limits] +description: "An overview of Seqera usage limits" +date created: "2025-02-19" +last updated: "2026-03-13" +tags: [limits, usage-limits, cloud-pro, cloud-enterprise] --- Seqera Platform elements and features have default limits per organization and workspace. ### Organizations -| Description | Basic | Cloud Pro + Enterprise | +| Description | Basic | Cloud Pro + Enterprise | | ----------------------- | ----- | ---------------------- | | Members | 3 | 50, or per license | | Workspaces | 50 | 50, or per license | @@ -18,8 +19,8 @@ Seqera Platform elements and features have default limits per organization and w | Active runs | 3 | 100, or per license | | Running Studio sessions | 1 | 1000, or per license | -:::info -Academic institutions and commercial organizations evaluating Seqera Platform are subject to custom usage limits. [Contact us](https://seqera.io/contact-us/) for more information. +:::info +Academic institutions and commercial organizations evaluating Seqera Platform are subject to custom usage limits. [Contact us](https://seqera.io/contact-us/) for more information. ::: ### Workspaces @@ -31,7 +32,7 @@ Academic institutions and commercial organizations evaluating Seqera Platform ar | Datasets | 100 | 1000, or per license | | Labels | 1000 | 1000, or per license | -:::note +:::note Some Enterprise instances on older licenses are limited to 100 labels per workspace. [Contact support](mailto:support@seqera.io) to upgrade your license. ::: diff --git a/platform-enterprise_versioned_docs/version-25.3/orgs-and-teams/workspace-management.md b/platform-enterprise_versioned_docs/version-25.3/orgs-and-teams/workspace-management.md index 2583aaa8a..e22e4cc5f 100644 --- a/platform-enterprise_versioned_docs/version-25.3/orgs-and-teams/workspace-management.md +++ b/platform-enterprise_versioned_docs/version-25.3/orgs-and-teams/workspace-management.md @@ -27,6 +27,10 @@ Organization owners and admins can create a new workspace within an organization 5. Under **Visibility**, select either **Private** or **Shared**. Private visibility means that workspace pipelines are only accessible to workspace participants. 6. Select **Add**. +### Create a shared workspace + +Creating a shared workspace is similar to the creation of a private workspace, with the exception of the **Visibility** option, which must be set to **Shared**. + :::tip As a workspace owner, you can modify optional workspace fields after workspace creation. You can either select **Edit** on an organization's workspaces list or the **Settings** tab within the workspace page. ::: @@ -84,10 +88,6 @@ The benefits of using a shared workspace within an organization include: - **Immediate update adoption**: Updated parameters for a shared pipeline become immediately available across the entire organization, reducing the risk of pipeline discrepancies. - **Computational resource provision**: Pipelines in shared workflows can be shared along with the required computational resources. This eliminates the need to duplicate resource setup in individual workspaces across the organization. Shared workspaces centralize and simplify resource sharing within an organization. -### Create a shared workspace - -Creating a shared workspace is similar to the creation of a private workspace, with the exception of the **Visibility** option, which must be set to **Shared**. - ### Create a shared pipeline When you create a pipeline in a shared workspace, associating it with a [compute environment](../compute-envs/overview) is optional. From fc250ff2089ce78414899f3ca6fe6239b1d584d5 Mon Sep 17 00:00:00 2001 From: Justine Geffen Date: Wed, 25 Mar 2026 22:15:01 +0200 Subject: [PATCH 18/27] Fixed broken links --- .../getting-started/production-checklist.md | 2 +- .../version-25.3/getting-started/production-checklist.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/platform-enterprise_docs/getting-started/production-checklist.md b/platform-enterprise_docs/getting-started/production-checklist.md index 2c1097a10..5c25f700c 100644 --- a/platform-enterprise_docs/getting-started/production-checklist.md +++ b/platform-enterprise_docs/getting-started/production-checklist.md @@ -97,7 +97,7 @@ Best practices for compute environment permissions include: Admin-level workspace access grants the ability to modify compute environments and credentials, which can affect all pipelines in the workspace. Assign Admin only to users who are responsible for workspace configuration. ::: -For teams sharing pipelines across workspaces, use a [shared workspace](../orgs-and-teams/workspace-management#shared-workspaces) to centralize pipeline definitions and compute environments without duplicating configuration. +For teams sharing pipelines across workspaces, use a [shared workspace](../orgs-and-teams/workspace-management#create-a-shared-workspace) to centralize pipeline definitions and compute environments without duplicating configuration. ## Compute environment sizing diff --git a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md index 2c1097a10..5c25f700c 100644 --- a/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md +++ b/platform-enterprise_versioned_docs/version-25.3/getting-started/production-checklist.md @@ -97,7 +97,7 @@ Best practices for compute environment permissions include: Admin-level workspace access grants the ability to modify compute environments and credentials, which can affect all pipelines in the workspace. Assign Admin only to users who are responsible for workspace configuration. ::: -For teams sharing pipelines across workspaces, use a [shared workspace](../orgs-and-teams/workspace-management#shared-workspaces) to centralize pipeline definitions and compute environments without duplicating configuration. +For teams sharing pipelines across workspaces, use a [shared workspace](../orgs-and-teams/workspace-management#create-a-shared-workspace) to centralize pipeline definitions and compute environments without duplicating configuration. ## Compute environment sizing From 6a990a6a2002f67af6aea511204f6300f0922ba0 Mon Sep 17 00:00:00 2001 From: Justine Geffen Date: Thu, 26 Mar 2026 11:14:43 +0200 Subject: [PATCH 19/27] Update platform-enterprise_docs/getting-started/production-checklist.md Co-authored-by: Chris Hakkaart Signed-off-by: Justine Geffen --- .../getting-started/production-checklist.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/platform-enterprise_docs/getting-started/production-checklist.md b/platform-enterprise_docs/getting-started/production-checklist.md index 5c25f700c..013f2f68b 100644 --- a/platform-enterprise_docs/getting-started/production-checklist.md +++ b/platform-enterprise_docs/getting-started/production-checklist.md @@ -6,7 +6,7 @@ last updated: "2026-03-25" tags: [production, checklist, deployment, limitations, retry] --- -This guide is for Platform administrators preparing a Seqera deployment for production use by scientific teams. It covers common configuration decisions, policies, and checks to consider before you run production workloads. Because every deployment is different, your Seqera account team can help you tailor these recommendations to your environment and workloads. Cloud infrastructure setup such as networking, IAM, and compute provisioning is the responsibility of your infrastructure team and is not covered here. +This guide is for Platform administrators preparing a Seqera deployment for production use by scientific teams. It covers common configuration decisions, policies, and checks to consider before you run production workloads. Because every deployment is different, your Seqera account team can help you tailor these recommendations to your environment and workloads. Cloud infrastructure setup, such as networking, IAM, and compute provisioning, is the responsibility of your infrastructure team and is not covered here. ## Organizations and workspaces From 311ae7369d8a0c0916e505af645278e7c83d9849 Mon Sep 17 00:00:00 2001 From: Justine Geffen Date: Thu, 26 Mar 2026 11:15:31 +0200 Subject: [PATCH 20/27] Update platform-enterprise_docs/getting-started/production-checklist.md Co-authored-by: Chris Hakkaart Signed-off-by: Justine Geffen --- .../getting-started/production-checklist.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/platform-enterprise_docs/getting-started/production-checklist.md b/platform-enterprise_docs/getting-started/production-checklist.md index 013f2f68b..eadd37b63 100644 --- a/platform-enterprise_docs/getting-started/production-checklist.md +++ b/platform-enterprise_docs/getting-started/production-checklist.md @@ -34,7 +34,7 @@ See [User roles](../orgs-and-teams/roles) for more information. ## Version pinning and compatibility -Incompatibilities between Nextflow and Platform versions are a leading cause of production failures, and often only surface during pipeline resumption after an interruption, not during normal runs. +Incompatibilities between Nextflow and Platform versions are a leading cause of production failures, and often only surface during pipeline resumption after an interruption. Best practices for version pinning and compatibility include: From 72db7b180b5145ef929b02f5208fe898646ed04e Mon Sep 17 00:00:00 2001 From: Justine Geffen Date: Thu, 26 Mar 2026 11:26:15 +0200 Subject: [PATCH 21/27] Update platform-enterprise_docs/getting-started/production-checklist.md Co-authored-by: Chris Hakkaart Signed-off-by: Justine Geffen --- .../getting-started/production-checklist.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/platform-enterprise_docs/getting-started/production-checklist.md b/platform-enterprise_docs/getting-started/production-checklist.md index eadd37b63..8f9c73e36 100644 --- a/platform-enterprise_docs/getting-started/production-checklist.md +++ b/platform-enterprise_docs/getting-started/production-checklist.md @@ -60,7 +60,7 @@ Best practices for cache management include: Your Seqera account team can help assess cache configuration for your specific workloads and storage setup. :::warning -After a Nextflow or Platform version upgrade, hash algorithms or cache key generation may change, causing all previously cached tasks to re-run. Inform pipeline teams before any upgrade so they can plan capacity and schedule accordingly; this is not a bug, but it will look like one if it happens without warning. +After a Nextflow or Platform version upgrade, hash algorithms or cache key generation may change, causing all previously cached tasks to re-run. Inform pipeline teams before any upgrade so they can plan capacity and schedule accordingly; this is an expected behavior, but it may cause alarm if it happens unexpectedly. ::: ## Credentials and token lifecycle From b64328df99a06fe20b861d2b8bafe1acc629cd7c Mon Sep 17 00:00:00 2001 From: Justine Geffen Date: Thu, 26 Mar 2026 11:26:43 +0200 Subject: [PATCH 22/27] Update platform-enterprise_docs/getting-started/production-checklist.md Co-authored-by: Chris Hakkaart Signed-off-by: Justine Geffen --- .../getting-started/production-checklist.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/platform-enterprise_docs/getting-started/production-checklist.md b/platform-enterprise_docs/getting-started/production-checklist.md index 8f9c73e36..f41e61c35 100644 --- a/platform-enterprise_docs/getting-started/production-checklist.md +++ b/platform-enterprise_docs/getting-started/production-checklist.md @@ -85,7 +85,7 @@ Use [Pipeline Secrets](../secrets/overview) to manage sensitive values such as A ## Compute environment permissions -Permissions within shared compute environments are a frequent source of unexpected behavior, particularly when multiple teams use the same workspace. +Permissions within shared compute environments can cause unexpected behavior, particularly when multiple teams use the same workspace. Best practices for compute environment permissions include: From 24d9e08dad72d18c1ca62a56d10aeb158ddf0830 Mon Sep 17 00:00:00 2001 From: Justine Geffen Date: Thu, 26 Mar 2026 11:27:20 +0200 Subject: [PATCH 23/27] Update platform-enterprise_docs/getting-started/production-checklist.md Co-authored-by: Chris Hakkaart Signed-off-by: Justine Geffen --- .../getting-started/production-checklist.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/platform-enterprise_docs/getting-started/production-checklist.md b/platform-enterprise_docs/getting-started/production-checklist.md index f41e61c35..1db8c76fb 100644 --- a/platform-enterprise_docs/getting-started/production-checklist.md +++ b/platform-enterprise_docs/getting-started/production-checklist.md @@ -193,7 +193,8 @@ In addition, the following Seqera-operated domains must be reachable from your w - `licenses.seqera.io` - `registry.nextflow.io` — required from Nextflow 25.10 onwards - `api.multiqc.info` -- For Seqera Cloud deployments: `cloud.seqera.io` and `api.cloud.seqera.io`. For Enterprise (self-hosted) deployments: your Platform instance hostname instead. +- For Seqera Cloud deployments: `cloud.seqera.io` and `api.cloud.seqera.io`. +- For Enterprise (self-hosted) deployments: your Platform instance hostname. If your allowlist is based on IP addresses rather than DNS names, allow all Cloudflare IP ranges listed at [https://www.cloudflare.com/ips/](https://www.cloudflare.com/ips/). For a dynamic list of Seqera Platform egress IPs, query `https://meta.seqera.io`. From 9cd98dbd47a083013a5d240cde4bd5be02e1add3 Mon Sep 17 00:00:00 2001 From: Justine Geffen Date: Thu, 26 Mar 2026 11:28:41 +0200 Subject: [PATCH 24/27] Update platform-enterprise_docs/getting-started/production-checklist.md Co-authored-by: Chris Hakkaart Signed-off-by: Justine Geffen --- .../getting-started/production-checklist.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/platform-enterprise_docs/getting-started/production-checklist.md b/platform-enterprise_docs/getting-started/production-checklist.md index 1db8c76fb..c6e849abd 100644 --- a/platform-enterprise_docs/getting-started/production-checklist.md +++ b/platform-enterprise_docs/getting-started/production-checklist.md @@ -181,7 +181,7 @@ fusion { ## Connectivity requirements -Seqera Platform requires outbound connectivity from compute worker nodes to specific endpoints. Blocked connections are a common cause of pipelines failing to start or stalling mid-run. Worker nodes must be able to reach your cloud provider's service endpoints (Batch, EC2 or Compute Engine, object storage, container registry), any container registries used by your pipelines, and any external data sources accessed at runtime. +Seqera Platform requires outbound connectivity from compute worker nodes to specific endpoints. Blocked connections cause pipelines to fail to start or stall mid-run. Worker nodes must be able to reach your cloud provider's service endpoints (Batch, EC2, or Compute Engine, object storage, container registry), any container registries used by your pipelines, and any external data sources accessed at runtime. In addition, the following Seqera-operated domains must be reachable from your worker nodes. If your firewall supports DNS wildcards, add `*.seqera.io.cdn.cloudflare.net`. Otherwise, add each domain individually: From 7f11fdd8c190dbbe3b49d378bae4a955d856bb83 Mon Sep 17 00:00:00 2001 From: Justine Geffen Date: Fri, 27 Mar 2026 21:58:32 +0200 Subject: [PATCH 25/27] Update platform-enterprise_docs/getting-started/production-checklist.md Co-authored-by: Ken Brewer Signed-off-by: Justine Geffen --- .../getting-started/production-checklist.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/platform-enterprise_docs/getting-started/production-checklist.md b/platform-enterprise_docs/getting-started/production-checklist.md index c6e849abd..e5571eb0b 100644 --- a/platform-enterprise_docs/getting-started/production-checklist.md +++ b/platform-enterprise_docs/getting-started/production-checklist.md @@ -134,7 +134,7 @@ Cancelling a pipeline run in Seqera Platform does not guarantee immediate termin ::: :::note -The cost estimator in Seqera Platform is for indicative purposes only. For billing, budgeting, or chargeback, use your cloud provider's native cost reporting tools: AWS Cost Explorer, GCP Billing, or Azure Cost Management. +The cost estimator in Seqera Platform is for estimation purposes and doesn't account for inefficiencies in how cloud batch executors provision instances. For billing, budgeting, or chargeback, use your cloud provider's native cost reporting tools: AWS Cost Explorer, GCP Billing, or Azure Cost Management. ::: ## Cost management and alerts From df7a0d06bf36c8ae1bced296199df5faf290cce4 Mon Sep 17 00:00:00 2001 From: Justine Geffen Date: Fri, 27 Mar 2026 21:58:43 +0200 Subject: [PATCH 26/27] Update platform-enterprise_docs/getting-started/production-checklist.md Co-authored-by: Ken Brewer Signed-off-by: Justine Geffen --- platform-enterprise_docs/getting-started/production-checklist.md | 1 - 1 file changed, 1 deletion(-) diff --git a/platform-enterprise_docs/getting-started/production-checklist.md b/platform-enterprise_docs/getting-started/production-checklist.md index e5571eb0b..30a5719ec 100644 --- a/platform-enterprise_docs/getting-started/production-checklist.md +++ b/platform-enterprise_docs/getting-started/production-checklist.md @@ -16,7 +16,6 @@ Best practices for organizations and workspaces include: - Plan your organization and workspace structure, considering the roles and work streams you expect to start with and scale to. - Use separate workspaces to isolate production from development and test environments. -- Use a [shared workspace](../orgs-and-teams/workspace-management#create-a-shared-workspace) to centralize pipeline definitions and compute environments without duplicating configuration across workspaces. See [Organizations](../orgs-and-teams/organizations) for more information. From 435761205844a73051b336df6e48f81220c8a05f Mon Sep 17 00:00:00 2001 From: Justine Geffen Date: Fri, 27 Mar 2026 21:58:51 +0200 Subject: [PATCH 27/27] Update platform-enterprise_docs/getting-started/production-checklist.md Co-authored-by: Ken Brewer Signed-off-by: Justine Geffen --- platform-enterprise_docs/getting-started/production-checklist.md | 1 - 1 file changed, 1 deletion(-) diff --git a/platform-enterprise_docs/getting-started/production-checklist.md b/platform-enterprise_docs/getting-started/production-checklist.md index 30a5719ec..f2785040a 100644 --- a/platform-enterprise_docs/getting-started/production-checklist.md +++ b/platform-enterprise_docs/getting-started/production-checklist.md @@ -96,7 +96,6 @@ Best practices for compute environment permissions include: Admin-level workspace access grants the ability to modify compute environments and credentials, which can affect all pipelines in the workspace. Assign Admin only to users who are responsible for workspace configuration. ::: -For teams sharing pipelines across workspaces, use a [shared workspace](../orgs-and-teams/workspace-management#create-a-shared-workspace) to centralize pipeline definitions and compute environments without duplicating configuration. ## Compute environment sizing