diff --git a/release-guide.md b/release-guide.md
new file mode 100644
index 0000000000..0a1de628a5
--- /dev/null
+++ b/release-guide.md
@@ -0,0 +1,32 @@
+# KBS Release Guide
+
+The follow steps are a guide for releasing kbs:
+
+1. Identify a valid release candidate. This is partly a sanity-checking step.
+For example, assuming you want the most recent commit, start by checking the
+tests of the last PR that was merged, and verify that the tests all passed (or
+any failures were acceptable in that context). Similarly, locate the ghcr kbs
+images that were created by the PR.
+
+2. Copy the ghcr images you identified in step (1). The new copy will be the
+released version. For example, if you are satisfied with the "latest" images in
+ghcr, and assuming you are releasing v0.8.2, these would be the ghcr package
+mappings:
+```
+staged-images/kbs:latest -> key-broker-service:built-in-as-v0.8.2
+staged-images/kbs-grpc-as:latest -> key-broker-service:v0.8.2
+staged-images/rvps:latest -> reference-value-provider-service:v0.8.2
+staged-images/coco-as-grpc:latest -> attestation-service:v0.8.2
+staged-images/coco-as-restful:latest -> attestation-service:rest-v0.8.2
+```
+
+3. Create a PR for the release. This PR needs to update the kubernetes
+kustomization.yaml file: `kbs/config/kubernetes/base/kustomization.yaml`. The
+`newTag` should be bumped to reflect the new version, e.g.
+`built-in-as-v0.8.2`.
+
+4. After the PR passes all tests and is merged, use the kbs github page to tag
+the main branch with the release version.
+
+5. Use the github kbs page to also create a new release.
+