diff --git a/.github/workflows/deploy.yml b/.github/workflows/deploy.yml
index 0650c48..b06c76f 100644
--- a/.github/workflows/deploy.yml
+++ b/.github/workflows/deploy.yml
@@ -16,8 +16,6 @@ on:
         options:
         - production
         default: 'production'
-  release:
-    types: [released]
 
 jobs:
   build-and-publish-image:
diff --git a/README.md b/README.md
index 1c596b2..44a8c1b 100644
--- a/README.md
+++ b/README.md
@@ -28,9 +28,11 @@ In production, it's run from a scheduled task via its `./collect` executable.
 
 `bundle exec rspec`
 
-### Docs
+### Deployments
 
-[Deployments](docs/deployments.md)
+**This project requires manual deployment.**
+
+[More detailed information about deployments...](docs/deployments.md)
 
 ## Licence
 
diff --git a/docs/deployments.md b/docs/deployments.md
index fe6026c..de694ff 100644
--- a/docs/deployments.md
+++ b/docs/deployments.md
@@ -6,14 +6,18 @@ This project only runs in production and only has the one target environment for
 
 For this reason, deployment promotion between environments has no meaning for this project.
 
+## Automatic deployment
+
+**This project requires manual deployment.** (This is because the automatic deployment Github user, `govuk-ci`, doesn't have permission to deploy directly to production since it's designed to deploy to integration and take advantage of deployment promotion.)
+
+As with our other projects, when changes are merged, a new release tag is created. As we're deploying manually, there's technically no need to wait for that to complete, but it does make the action log easier to follow if we deploy releases.
+
 ## How deployment works
 
 Since the project is run from a scheduled task (a K8s `CronJob`), its deployment process differs slightly from that of our apps and some details might prove useful to be aware of if they're not already familiar to you.
 
 Everytime it's run on its schedule, a new Pod will pull a new copy of this project's Docker image from ECR. This differs from the way apps work in that an app's long-running Pods are reprovisioned with the new image once, during the deployment itself.
 
-As with our other projects, when changes are merged, a new release tag is created and in turn, the changes will be deployed automatically.
-
 ## Deploying to integration
 
 Because the scheduled task only usually runs in production, some changes are required to enable a version to be deployed to integration (e.g. for testing),