diff --git a/pages/deployments/existing-cluster.md b/pages/deployments/existing-cluster.md
index ec252a05..e5b13e7e 100644
--- a/pages/deployments/existing-cluster.md
+++ b/pages/deployments/existing-cluster.md
@@ -37,6 +37,10 @@ We also strongly recommend you find a secure place to store the generated `value
 
 ## Configure Console Upgrades
 
-The Plural Console has the capability of self-managing its own upgrades in BYOK mode. This can be configured in the global settings page for deployments.
+The Plural Console has the capability of self-managing its own upgrades in BYOK mode. This can be configured in the global settings page for deployments under `/cd/settings/auto-upgrade`. It will ask you to copy in the values file then if it all looks correct, will create a service against our upstream helm chart with those values as overrides. The ui should look something like this:
 
-You can also self-manage the chart to control your own upgrade cadence. We recommend you use our self-management though to simplify this process and ensure your constantly up-to-date.
+![](/assets/deployments/auto-upgrade.png)
+
+You can then go to the service it creates at any time to tweak the values as you might need.
+
+You can also self-manage the chart to control your own upgrade cadence. We recommend you use our self-management though to simplify this process and ensure you are constantly up-to-date.
diff --git a/pages/deployments/helm.md b/pages/deployments/helm.md
new file mode 100644
index 00000000..fce2d4c9
--- /dev/null
+++ b/pages/deployments/helm.md
@@ -0,0 +1,52 @@
+---
+title: Helm Repository Sources
+description: Use Helm repositories in OCI or over HTTP as artifact sources
+---
+
+## Overview
+
+There are some use-cases where git is a clunky storage layer for kubernetes manifests, the most common one is when using third party vendored charts from an external helm repository. Plural builds on top of FluxCD's source controller to provide robust support for most of the helm storage formats, including standard HTTP repositories and OCI repos in most major registry providers.
+
+A quick rundown of what you can get by using a helm repository directly:
+
+- no need to manually vendor charts into git
+- easier mechanisms to manage multiple versions of the same app created via a helm chart across your fleet
+- leveraging OCI scanning capabilities built into your image registry
+
+This model isn't for all usecases as it still has drawbacks (introducing a new packaging mechanism into your deployment architecture), but some users will find it useful.
+
+## Install flux source controller
+
+The first step is to simply install the flux source controller. We already package an add-on for this. You should simply ensure it's installed in your management cluster to be able to get going.
+
+## Create initial helm repositories
+
+We recommend you manage the helm repositories via gitops, yourself. Defining them is a simple matter of crafting a crd in a git repo of your choice, we have an example [here](https://github.com/pluralsh/console/tree/master/test-apps/helm-repositories), and then creating a CD service to sync that folder into your management cluster.
+
+Here's a very simple repository CRD you can use for testing as well:
+
+```yaml
+apiVersion: source.toolkit.fluxcd.io/v1beta2
+kind: HelmRepository
+metadata:
+  name: podinfo
+spec:
+  interval: 5m0s
+  url: https://stefanprodan.github.io/podinfo
+```
+
+## Create a service from helm
+
+From there you should be able to use the same deploy service flow to create a new service, but select `helm` to toggle from git as the primary source, then chose the repository, chart, and version you want to provision. If you're creating it via the UI, we'll often be able to provide a full dropdown wizard of all this information for you like so:
+
+![](/assets/deployments/helm-service.png)
+
+## Overriding values
+
+You can provide your own values file in the service details UI or via our API directly.
+
+It's worth noting that this can also support templating secrets like a git-sourced helm service as well if you'd like to parameterize your values even more precisely.
+
+## Multi-Source Helm
+
+Occasionally you'll want to source the helm chart itself from an external helm repository, but store the values in git. This is also supported by configuring the service to have both a git and helm source, and using the `helm.valuesFiles` fields on the service to specify which files precisely should be used.
diff --git a/public/assets/deployments/auto-upgrade.png b/public/assets/deployments/auto-upgrade.png
new file mode 100644
index 00000000..a070e78b
Binary files /dev/null and b/public/assets/deployments/auto-upgrade.png differ
diff --git a/public/assets/deployments/helm-service.png b/public/assets/deployments/helm-service.png
new file mode 100644
index 00000000..cb6c0701
Binary files /dev/null and b/public/assets/deployments/helm-service.png differ
diff --git a/src/NavData.tsx b/src/NavData.tsx
index 070373d0..f57d8957 100644
--- a/src/NavData.tsx
+++ b/src/NavData.tsx
@@ -134,6 +134,10 @@ const rootNavData: NavMenu = deepFreeze([
             href: '/deployments/services-deploy',
             title: 'Deploy Services',
           },
+          {
+            href: '/deployments/helm',
+            title: 'Helm Repository Sources',
+          },
           {
             href: '/deployments/global-services',
             title: 'Configure Global Services',