diff --git a/.github/workflows/helm-deploy-eks.yaml b/.github/workflows/helm-deploy-eks.yaml
index 587a6f7..f1a2b99 100644
--- a/.github/workflows/helm-deploy-eks.yaml
+++ b/.github/workflows/helm-deploy-eks.yaml
@@ -46,6 +46,23 @@ on:
       aws_access_secret:
         required: true
 
+# Serialise deploys per (repository, environment, release_name). Two
+# `helm upgrade` calls targeting the same release cannot run concurrently
+# — helm rejects the second with "another operation (install/upgrade/
+# rollback) is in progress" (surfaced 2026-07-08 after the fire-and-
+# forget dispatch refactor decoupled deploy timing from Build timing).
+#
+# cancel-in-progress: false so the current deploy runs to completion.
+# Canceling an in-flight helm upgrade mid-flight risks leaving the
+# release in a weird state; queueing the next dispatch is safer.
+#
+# The group name is scoped to (repo, env, release_name) so unrelated
+# deploys don't block each other — a stg deploy for internal_api can
+# proceed while a stg deploy for catalog_api runs.
+concurrency:
+  group: helm-deploy-${{ github.repository }}-${{ inputs.environment }}-${{ inputs.release_name || github.event.repository.name }}
+  cancel-in-progress: false
+
 jobs:
   deploy:
     runs-on: ubuntu-latest
diff --git a/.github/workflows/helm-deploy.yaml b/.github/workflows/helm-deploy.yaml
index bc6e36e..963720e 100644
--- a/.github/workflows/helm-deploy.yaml
+++ b/.github/workflows/helm-deploy.yaml
@@ -49,6 +49,17 @@ on:
       k8s_token:
         required: true
 
+# Serialise deploys per (repository, environment, release_name). Two
+# `helm upgrade` calls targeting the same release cannot run concurrently
+# — helm rejects the second with "another operation (install/upgrade/
+# rollback) is in progress" (surfaced 2026-07-08 on helm-deploy-eks.yaml).
+# Same treatment applied here for consistency across shared helm
+# workflows. cancel-in-progress: false so the current deploy runs to
+# completion before the next dispatch takes over.
+concurrency:
+  group: helm-deploy-${{ github.repository }}-${{ inputs.environment }}-${{ inputs.release_name || github.event.repository.name }}
+  cancel-in-progress: false
+
 jobs:
   deploy:
     runs-on: ubuntu-latest
diff --git a/.github/workflows/helm-deployv2.yaml b/.github/workflows/helm-deployv2.yaml
index a1712ab..0c41ab9 100644
--- a/.github/workflows/helm-deployv2.yaml
+++ b/.github/workflows/helm-deployv2.yaml
@@ -42,6 +42,17 @@ on:
       kubeconfig:
         required: true
 
+# Serialise deploys per (repository, environment, release_name). Two
+# `helm upgrade` calls targeting the same release cannot run concurrently
+# — helm rejects the second with "another operation (install/upgrade/
+# rollback) is in progress" (surfaced 2026-07-08 on helm-deploy-eks.yaml).
+# Same treatment applied here for consistency across shared helm
+# workflows. cancel-in-progress: false so the current deploy runs to
+# completion before the next dispatch takes over.
+concurrency:
+  group: helm-deploy-${{ github.repository }}-${{ inputs.environment }}-${{ inputs.release_name || github.event.repository.name }}
+  cancel-in-progress: false
+
 jobs:
   deploy:
     runs-on: ubuntu-latest
diff --git a/.github/workflows/helm-rollback.yaml b/.github/workflows/helm-rollback.yaml
index e9530fc..24600ad 100644
--- a/.github/workflows/helm-rollback.yaml
+++ b/.github/workflows/helm-rollback.yaml
@@ -21,6 +21,15 @@ on:
       k8s_token:
         required: true
 
+# Serialise rollbacks per (repository, environment, deployment) so a
+# rollback can't race with a concurrent helm operation on the same
+# release — same "another operation in progress" class of failure as
+# on helm-deploy-eks.yaml. cancel-in-progress: false because canceling
+# a rollback mid-flight would be worse than queueing.
+concurrency:
+  group: helm-deploy-${{ github.repository }}-${{ inputs.environment }}-${{ inputs.deployment }}
+  cancel-in-progress: false
+
 jobs:
   deploy:
     runs-on: ubuntu-latest