diff --git a/.github/workflows/release-ghcr-files.yml b/.github/workflows/release-ghcr-files.yml
index 50f66342..ccce3a74 100644
--- a/.github/workflows/release-ghcr-files.yml
+++ b/.github/workflows/release-ghcr-files.yml
@@ -54,7 +54,7 @@ jobs:
 
             - README.md - Instructions for running the containers
             - ConfiguringOauthProviders.md - Guide for setting up OAuth providers
-            - docker-compose-ghcr.yml - For runing locally
+            - docker-compose-ghcr.yml - For running locally
             - docker-compose-ghcr-tailscale.yml - For running with Tailscale networking
 
             You can download either the individual files or the complete ZIP archive.
diff --git a/cspell.json b/cspell.json
index b9c79e8a..3cbe5cb4 100644
--- a/cspell.json
+++ b/cspell.json
@@ -29,6 +29,7 @@
         "Recents",
         "rollup",
         "skeletonlabs",
+        "softprops",
         "subcard",
         "tailscalecompose",
         "topbar",
diff --git a/docs/actionsWorkflows.md b/docs/actionsWorkflows.md
new file mode 100644
index 00000000..80e7fa5b
--- /dev/null
+++ b/docs/actionsWorkflows.md
@@ -0,0 +1,32 @@
+# Github Actions Workflows
+
+This project uses GitHub Actions continuous integration and continuous deployment (CI/CD) workflows. The goal of this document is to provide an overview of these workflows.
+
+As of May 2026 there are three workflows, located in `.github/workflows/`. Workflow 1 is considered mostly finalized, while workflows 2 and 3 are likely to change soon.
+
+Results from previous runs of the workflows can be found in the [Actions](https://github.com/AssetAtlasTracker/AssetAtlas/actions) tab of the project repo.
+
+---
+
+## 1. Run Lint and Tests with Coverage (`test.yml`)
+
+This is the most frequently run workflow by far.
+
+- runs every time a PR to [main](https://github.com/AssetAtlasTracker/AssetAtlas) is opened or merged
+- ensures there are no linting errors/warnings
+- ensures all tests pass
+- uploads a coverage report generated by the test runs
+
+---
+
+## 2. Build and Publish Docker Images (`docker-publish.yml`)
+
+This workflow runs whenever the [production](https://github.com/AssetAtlasTracker/AssetAtlas/tree/production) branch is updated and creates [these release packages](https://github.com/AssetAtlasTracker/AssetAtlas/pkgs/container/assetatlas). It takes a while (5-10 minutes) to run.
+
+**Important detail:** when a pull request to [production](https://github.com/AssetAtlasTracker/AssetAtlas/tree/production) is opened, it will trigger the build (but not publish). The image will only be published when the PR is merged. This helps us avoid publishing broken builds.
+
+---
+
+## 3. Create Release with Docker Files (`release-ghcr-files.yml`)
+
+This workflow also runs whenever the [production](https://github.com/AssetAtlasTracker/AssetAtlas/tree/production) branch is updated, and creates [these GHCR files](https://github.com/AssetAtlasTracker/AssetAtlas/releases/tag/ghcr-files-latest).
diff --git a/docs/gitWorkflow.md b/docs/gitWorkflow.md
deleted file mode 100644
index 9dd9e238..00000000
--- a/docs/gitWorkflow.md
+++ /dev/null
@@ -1,14 +0,0 @@
-# Git Workflow
-
-This project runs with a GitHub Actions continuous integration and continuous deployment systems and this document seeks to document the workings of said workflow. There are currently 2 main workflows used with integration and deployment, those workflows are documented in test.yml and docker-publish.yml
-
-## Test
-
-The most commonly used workflow is test.yml by far. It is run on every single commit and ensures that all tests still pass to prevent faulty code from being committed. The main events that occur in test are that it first checks out the repository before setting up Node and installing the necessary dependencies with `rm package-lock.json && npm install` then finally running the tests with `npm run test`. Additionally, it now also runs `npm run lint` for code coverage. It notably does not ensure that code has been auto formatted when committed as has been recently discovered.
-
-## Build and Publish
-
-This is the workflow triggered when a new build is being pushed to production. It takes a much longer time to run when compared to Test and has very different steps. This workflow also begins with
-checking out the repository following which it sets up QEMU (which enables cross-platform builds) with `uses: docker/setup-qemu-action@v2`. It then Logs in to GitHub’s container registry using `uses: docker/login-action@v2` and the
-automatically provided token. Following that it extracts the Docker metadata with `uses: docker/metadata-action@v4` and automatically generates image tags and labels. It then sets up Docker Buildx with `uses: docker/setup-buildx-action@v2`
-before finally building and pushing the Docker image using `uses: docker/build-push-action@v4` and pushes it to GitHub.  Note that pull requests targeting production will run the build but not push the image.