diff --git a/README.md b/README.md
index fd678e77c3..220186a2e8 100644
--- a/README.md
+++ b/README.md
@@ -51,7 +51,7 @@ use Flux already then you can easily add Weave GitOps to create a platform manag
Mac / Linux
```console
-curl --silent --location "https://github.com/weaveworks/weave-gitops/releases/download/v0.28.0/gitops-$(uname)-$(uname -m).tar.gz" | tar xz -C /tmp
+curl --silent --location "https://github.com/weaveworks/weave-gitops/releases/download/v0.29.0/gitops-$(uname)-$(uname -m).tar.gz" | tar xz -C /tmp
sudo mv /tmp/gitops /usr/local/bin
gitops version
```
diff --git a/charts/gitops-server/Chart.yaml b/charts/gitops-server/Chart.yaml
index 44dfa10461..059134add4 100644
--- a/charts/gitops-server/Chart.yaml
+++ b/charts/gitops-server/Chart.yaml
@@ -13,9 +13,9 @@ type: application
# This is the chart version. This version number should be incremented each time you make changes
# to the chart and its templates, including the app version.
# Versions are expected to follow Semantic Versioning (https://semver.org/)
-version: 4.0.26
+version: 4.0.27
# This is the version number of the application being deployed. This version number should be
# incremented each time you make changes to the application. Versions are not expected to
# follow Semantic Versioning. They should reflect the version the application is using.
# It is recommended to use it with quotes.
-appVersion: "v0.28.0"
+appVersion: "v0.29.0"
diff --git a/charts/gitops-server/values.yaml b/charts/gitops-server/values.yaml
index b4b39a47ba..9d35f3ed61 100644
--- a/charts/gitops-server/values.yaml
+++ b/charts/gitops-server/values.yaml
@@ -10,7 +10,7 @@ image:
repository: ghcr.io/weaveworks/wego-app
pullPolicy: IfNotPresent
# Overrides the image tag whose default is the chart appVersion.
- tag: "v0.28.0"
+ tag: "v0.29.0"
imagePullSecrets: []
nameOverride: ""
fullnameOverride: ""
diff --git a/package-lock.json b/package-lock.json
index dd210e49ad..51734dbca8 100644
--- a/package-lock.json
+++ b/package-lock.json
@@ -1,12 +1,12 @@
{
"name": "@weaveworks/weave-gitops",
- "version": "0.29.0-rc.1",
+ "version": "0.29.0",
"lockfileVersion": 2,
"requires": true,
"packages": {
"": {
"name": "@weaveworks/weave-gitops",
- "version": "0.29.0-rc.1",
+ "version": "0.29.0",
"dependencies": {
"@material-ui/core": "^4.12.3",
"@material-ui/icons": "^4.11.2",
diff --git a/package.json b/package.json
index 9214fa4035..a63fde982b 100644
--- a/package.json
+++ b/package.json
@@ -1,6 +1,6 @@
{
"name": "@weaveworks/weave-gitops",
- "version": "0.29.0-rc.1",
+ "version": "0.29.0",
"description": "Weave GitOps core",
"targets": {
"default": {
diff --git a/ui/components/__tests__/__snapshots__/Footer.test.tsx.snap b/ui/components/__tests__/__snapshots__/Footer.test.tsx.snap
index e4f9bfdc7e..179fa48617 100644
--- a/ui/components/__tests__/__snapshots__/Footer.test.tsx.snap
+++ b/ui/components/__tests__/__snapshots__/Footer.test.tsx.snap
@@ -368,7 +368,7 @@ exports[`Footer snapshots no api version 1`] = `
/>
@@ -379,7 +379,7 @@ exports[`Footer snapshots no api version 1`] = `
- v0.29.0-rc.1
+ v0.29.0
diff --git a/website/docs/open-source/getting-started/install-OSS.mdx b/website/docs/open-source/getting-started/install-OSS.mdx
index b8c27b1115..7760f3aae2 100644
--- a/website/docs/open-source/getting-started/install-OSS.mdx
+++ b/website/docs/open-source/getting-started/install-OSS.mdx
@@ -126,7 +126,7 @@ import TabItem from "@theme/TabItem";
```bash
-curl --silent --location "https://github.com/weaveworks/weave-gitops/releases/download/v0.28.0/gitops-$(uname)-$(uname -m).tar.gz" | tar xz -C /tmp
+curl --silent --location "https://github.com/weaveworks/weave-gitops/releases/download/v0.29.0/gitops-$(uname)-$(uname -m).tar.gz" | tar xz -C /tmp
sudo mv /tmp/gitops /usr/local/bin
gitops version
```
diff --git a/website/docs/references/cli-reference/gitops.md b/website/docs/references/cli-reference/gitops.md
index d7c11d1d10..21c0229f73 100644
--- a/website/docs/references/cli-reference/gitops.md
+++ b/website/docs/references/cli-reference/gitops.md
@@ -50,4 +50,4 @@ Command line utility for managing Kubernetes applications via GitOps.
* [gitops suspend](gitops_suspend.md) - Suspend a resource
* [gitops version](gitops_version.md) - Display gitops version
-###### Auto generated by spf13/cobra on 19-Jul-2023
+###### Auto generated by spf13/cobra on 2-Aug-2023
diff --git a/website/docs/references/cli-reference/gitops_beta.md b/website/docs/references/cli-reference/gitops_beta.md
index 33f33fc487..3743388569 100644
--- a/website/docs/references/cli-reference/gitops_beta.md
+++ b/website/docs/references/cli-reference/gitops_beta.md
@@ -24,4 +24,4 @@ This component contains unstable or still-in-development functionality
* [gitops](gitops.md) - Weave GitOps
* [gitops beta run](gitops_beta_run.md) - Set up an interactive sync between your cluster and your local file system
-###### Auto generated by spf13/cobra on 19-Jul-2023
+###### Auto generated by spf13/cobra on 2-Aug-2023
diff --git a/website/docs/references/cli-reference/gitops_beta_run.md b/website/docs/references/cli-reference/gitops_beta_run.md
index 9c468fc9f2..fe42052ca1 100644
--- a/website/docs/references/cli-reference/gitops_beta_run.md
+++ b/website/docs/references/cli-reference/gitops_beta_run.md
@@ -54,13 +54,13 @@ gitops beta run ./charts/podinfo --timeout 3m --port-forward namespace=flux-syst
--dashboard-port string GitOps Dashboard port (default "9001")
--decryption-key-file string Path to an age key file used for decrypting Secrets using SOPS.
--disable-compression If true, opt-out of response compression for all requests to the server
- --flux-version string The version of Flux to install. (default "0.37.0")
+ --flux-version string The version of Flux to install. (default "2.0.1")
-h, --help help for run
--no-bootstrap Disable bootstrapping at shutdown.
--no-session Disable session management. If not specified, the session will be enabled by default.
--port-forward string Forward the port from a cluster's resource to your local machine i.e. 'port=8080:8080,resource=svc/app'.
--root-dir string Specify the root directory to watch for changes. If not specified, the root of Git repository will be used.
- --session-name string Specify the name of the session. If not specified, the name of the current branch and the last commit id will be used. (default "run-main-adda33ef-dirty")
+ --session-name string Specify the name of the session. If not specified, the name of the current branch and the last commit id will be used. (default "run-main-3dd7cb6e-dirty")
--session-namespace string Specify the namespace of the session. (default "default")
--skip-dashboard-install Skip installation of the Dashboard. This also disables the prompt asking whether the Dashboard should be installed.
--skip-resource-cleanup Skip resource cleanup. If not specified, the GitOps Run resources will be deleted by default.
diff --git a/website/docs/references/cli-reference/gitops_check.md b/website/docs/references/cli-reference/gitops_check.md
index 691d78f6bf..538fbc63e0 100644
--- a/website/docs/references/cli-reference/gitops_check.md
+++ b/website/docs/references/cli-reference/gitops_check.md
@@ -36,4 +36,4 @@ gitops check
* [gitops](gitops.md) - Weave GitOps
-###### Auto generated by spf13/cobra on 19-Jul-2023
+###### Auto generated by spf13/cobra on 2-Aug-2023
diff --git a/website/docs/references/cli-reference/gitops_completion.md b/website/docs/references/cli-reference/gitops_completion.md
index cbcd4427c3..19ed36493e 100644
--- a/website/docs/references/cli-reference/gitops_completion.md
+++ b/website/docs/references/cli-reference/gitops_completion.md
@@ -33,4 +33,4 @@ See each sub-command's help for details on how to use the generated script.
* [gitops completion powershell](gitops_completion_powershell.md) - Generate the autocompletion script for powershell
* [gitops completion zsh](gitops_completion_zsh.md) - Generate the autocompletion script for zsh
-###### Auto generated by spf13/cobra on 19-Jul-2023
+###### Auto generated by spf13/cobra on 2-Aug-2023
diff --git a/website/docs/references/cli-reference/gitops_completion_bash.md b/website/docs/references/cli-reference/gitops_completion_bash.md
index 66e6c0517f..cf6d06d9ac 100644
--- a/website/docs/references/cli-reference/gitops_completion_bash.md
+++ b/website/docs/references/cli-reference/gitops_completion_bash.md
@@ -52,4 +52,4 @@ gitops completion bash
* [gitops completion](gitops_completion.md) - Generate the autocompletion script for the specified shell
-###### Auto generated by spf13/cobra on 19-Jul-2023
+###### Auto generated by spf13/cobra on 2-Aug-2023
diff --git a/website/docs/references/cli-reference/gitops_completion_fish.md b/website/docs/references/cli-reference/gitops_completion_fish.md
index c95765a53f..693480a22e 100644
--- a/website/docs/references/cli-reference/gitops_completion_fish.md
+++ b/website/docs/references/cli-reference/gitops_completion_fish.md
@@ -43,4 +43,4 @@ gitops completion fish [flags]
* [gitops completion](gitops_completion.md) - Generate the autocompletion script for the specified shell
-###### Auto generated by spf13/cobra on 19-Jul-2023
+###### Auto generated by spf13/cobra on 2-Aug-2023
diff --git a/website/docs/references/cli-reference/gitops_completion_powershell.md b/website/docs/references/cli-reference/gitops_completion_powershell.md
index ee10d46cc0..34c4fe3c75 100644
--- a/website/docs/references/cli-reference/gitops_completion_powershell.md
+++ b/website/docs/references/cli-reference/gitops_completion_powershell.md
@@ -40,4 +40,4 @@ gitops completion powershell [flags]
* [gitops completion](gitops_completion.md) - Generate the autocompletion script for the specified shell
-###### Auto generated by spf13/cobra on 19-Jul-2023
+###### Auto generated by spf13/cobra on 2-Aug-2023
diff --git a/website/docs/references/cli-reference/gitops_completion_zsh.md b/website/docs/references/cli-reference/gitops_completion_zsh.md
index dcb48caa57..7aea8681fe 100644
--- a/website/docs/references/cli-reference/gitops_completion_zsh.md
+++ b/website/docs/references/cli-reference/gitops_completion_zsh.md
@@ -13,7 +13,7 @@ to enable it. You can execute the following once:
To load completions in your current shell session:
- source <(gitops completion zsh); compdef _gitops gitops
+ source <(gitops completion zsh)
To load completions for every new session, execute once:
@@ -54,4 +54,4 @@ gitops completion zsh [flags]
* [gitops completion](gitops_completion.md) - Generate the autocompletion script for the specified shell
-###### Auto generated by spf13/cobra on 19-Jul-2023
+###### Auto generated by spf13/cobra on 2-Aug-2023
diff --git a/website/docs/references/cli-reference/gitops_create.md b/website/docs/references/cli-reference/gitops_create.md
index e700adb139..839ede0e81 100644
--- a/website/docs/references/cli-reference/gitops_create.md
+++ b/website/docs/references/cli-reference/gitops_create.md
@@ -46,4 +46,4 @@ gitops create terraform my-resource \
* [gitops create dashboard](gitops_create_dashboard.md) - Create a HelmRepository and HelmRelease to deploy Weave GitOps
* [gitops create terraform](gitops_create_terraform.md) - Create a Terraform object
-###### Auto generated by spf13/cobra on 19-Jul-2023
+###### Auto generated by spf13/cobra on 2-Aug-2023
diff --git a/website/docs/references/cli-reference/gitops_create_terraform.md b/website/docs/references/cli-reference/gitops_create_terraform.md
index 84e6753f1a..ff545afe3d 100644
--- a/website/docs/references/cli-reference/gitops_create_terraform.md
+++ b/website/docs/references/cli-reference/gitops_create_terraform.md
@@ -50,4 +50,4 @@ gitops create terraform -n default my-resource --source GitRepository/my-project
* [gitops create](gitops_create.md) - Creates a resource
-###### Auto generated by spf13/cobra on 19-Jul-2023
+###### Auto generated by spf13/cobra on 2-Aug-2023
diff --git a/website/docs/references/cli-reference/gitops_delete.md b/website/docs/references/cli-reference/gitops_delete.md
index 57fbdfe166..fc4d311cc2 100644
--- a/website/docs/references/cli-reference/gitops_delete.md
+++ b/website/docs/references/cli-reference/gitops_delete.md
@@ -24,4 +24,4 @@ Delete a resource
* [gitops](gitops.md) - Weave GitOps
* [gitops delete terraform](gitops_delete_terraform.md) - Delete a Terraform object
-###### Auto generated by spf13/cobra on 19-Jul-2023
+###### Auto generated by spf13/cobra on 2-Aug-2023
diff --git a/website/docs/references/cli-reference/gitops_delete_terraform.md b/website/docs/references/cli-reference/gitops_delete_terraform.md
index 1b78acf2b5..391bd02f9a 100644
--- a/website/docs/references/cli-reference/gitops_delete_terraform.md
+++ b/website/docs/references/cli-reference/gitops_delete_terraform.md
@@ -38,4 +38,4 @@ gitops delete terraform -n default my-resource
* [gitops delete](gitops_delete.md) - Delete a resource
-###### Auto generated by spf13/cobra on 19-Jul-2023
+###### Auto generated by spf13/cobra on 2-Aug-2023
diff --git a/website/docs/references/cli-reference/gitops_get.md b/website/docs/references/cli-reference/gitops_get.md
index 112eb9e665..ced3b77c71 100644
--- a/website/docs/references/cli-reference/gitops_get.md
+++ b/website/docs/references/cli-reference/gitops_get.md
@@ -37,4 +37,4 @@ echo -n $PASSWORD | gitops get bcrypt-hash
* [gitops get bcrypt-hash](gitops_get_bcrypt-hash.md) - Generates a hashed secret
* [gitops get config](gitops_get_config.md) - Prints out the CLI configuration for Weave GitOps
-###### Auto generated by spf13/cobra on 19-Jul-2023
+###### Auto generated by spf13/cobra on 2-Aug-2023
diff --git a/website/docs/references/cli-reference/gitops_get_bcrypt-hash.md b/website/docs/references/cli-reference/gitops_get_bcrypt-hash.md
index 235e6b9e9e..174660d4d6 100644
--- a/website/docs/references/cli-reference/gitops_get_bcrypt-hash.md
+++ b/website/docs/references/cli-reference/gitops_get_bcrypt-hash.md
@@ -36,4 +36,4 @@ echo -n $PASSWORD | gitops get bcrypt-hash
* [gitops get](gitops_get.md) - Display one or many Weave GitOps resources
-###### Auto generated by spf13/cobra on 19-Jul-2023
+###### Auto generated by spf13/cobra on 2-Aug-2023
diff --git a/website/docs/references/cli-reference/gitops_logs.md b/website/docs/references/cli-reference/gitops_logs.md
index b458214013..6b69c82003 100644
--- a/website/docs/references/cli-reference/gitops_logs.md
+++ b/website/docs/references/cli-reference/gitops_logs.md
@@ -24,4 +24,4 @@ Get logs for a resource
* [gitops](gitops.md) - Weave GitOps
* [gitops logs terraform](gitops_logs_terraform.md) - Get the runner logs of a Terraform object
-###### Auto generated by spf13/cobra on 19-Jul-2023
+###### Auto generated by spf13/cobra on 2-Aug-2023
diff --git a/website/docs/references/cli-reference/gitops_logs_terraform.md b/website/docs/references/cli-reference/gitops_logs_terraform.md
index 8b5d96355b..3f5fdd257c 100644
--- a/website/docs/references/cli-reference/gitops_logs_terraform.md
+++ b/website/docs/references/cli-reference/gitops_logs_terraform.md
@@ -38,4 +38,4 @@ gitops logs terraform --namespace flux-system my-resource
* [gitops logs](gitops_logs.md) - Get logs for a resource
-###### Auto generated by spf13/cobra on 19-Jul-2023
+###### Auto generated by spf13/cobra on 2-Aug-2023
diff --git a/website/docs/references/cli-reference/gitops_remove.md b/website/docs/references/cli-reference/gitops_remove.md
index a5d6844b95..a089b09e10 100644
--- a/website/docs/references/cli-reference/gitops_remove.md
+++ b/website/docs/references/cli-reference/gitops_remove.md
@@ -24,4 +24,4 @@ Remove various components of Weave GitOps
* [gitops](gitops.md) - Weave GitOps
* [gitops remove run](gitops_remove_run.md) - Remove GitOps Run sessions
-###### Auto generated by spf13/cobra on 19-Jul-2023
+###### Auto generated by spf13/cobra on 2-Aug-2023
diff --git a/website/docs/references/cli-reference/gitops_replan.md b/website/docs/references/cli-reference/gitops_replan.md
index c3760d9e74..901323cfc5 100644
--- a/website/docs/references/cli-reference/gitops_replan.md
+++ b/website/docs/references/cli-reference/gitops_replan.md
@@ -33,4 +33,4 @@ gitops replan terraform --namespace flux-system my-resource
* [gitops](gitops.md) - Weave GitOps
* [gitops replan terraform](gitops_replan_terraform.md) - Trigger replan for a Terraform object
-###### Auto generated by spf13/cobra on 19-Jul-2023
+###### Auto generated by spf13/cobra on 2-Aug-2023
diff --git a/website/docs/references/cli-reference/gitops_replan_terraform.md b/website/docs/references/cli-reference/gitops_replan_terraform.md
index 5a6fe1a22c..5046b76c76 100644
--- a/website/docs/references/cli-reference/gitops_replan_terraform.md
+++ b/website/docs/references/cli-reference/gitops_replan_terraform.md
@@ -38,4 +38,4 @@ gitops replan terraform --namespace flux-system my-resource
* [gitops replan](gitops_replan.md) - Replan a resource
-###### Auto generated by spf13/cobra on 19-Jul-2023
+###### Auto generated by spf13/cobra on 2-Aug-2023
diff --git a/website/docs/references/cli-reference/gitops_resume.md b/website/docs/references/cli-reference/gitops_resume.md
index 173392e2e4..8f0f7745e7 100644
--- a/website/docs/references/cli-reference/gitops_resume.md
+++ b/website/docs/references/cli-reference/gitops_resume.md
@@ -33,4 +33,4 @@ gitops resume terraform --namespace flux-system my-resource
* [gitops](gitops.md) - Weave GitOps
* [gitops resume terraform](gitops_resume_terraform.md) - Resume a Terraform object
-###### Auto generated by spf13/cobra on 19-Jul-2023
+###### Auto generated by spf13/cobra on 2-Aug-2023
diff --git a/website/docs/references/cli-reference/gitops_resume_terraform.md b/website/docs/references/cli-reference/gitops_resume_terraform.md
index 8767ad7d38..9c73159e58 100644
--- a/website/docs/references/cli-reference/gitops_resume_terraform.md
+++ b/website/docs/references/cli-reference/gitops_resume_terraform.md
@@ -38,4 +38,4 @@ gitops resume terraform --namespace flux-system my-resource
* [gitops resume](gitops_resume.md) - Resume a resource
-###### Auto generated by spf13/cobra on 19-Jul-2023
+###### Auto generated by spf13/cobra on 2-Aug-2023
diff --git a/website/docs/references/cli-reference/gitops_run.md b/website/docs/references/cli-reference/gitops_run.md
index 7888a1a18c..f7b032e0e8 100644
--- a/website/docs/references/cli-reference/gitops_run.md
+++ b/website/docs/references/cli-reference/gitops_run.md
@@ -54,13 +54,13 @@ gitops beta run ./charts/podinfo --timeout 3m --port-forward namespace=flux-syst
--dashboard-port string GitOps Dashboard port (default "9001")
--decryption-key-file string Path to an age key file used for decrypting Secrets using SOPS.
--disable-compression If true, opt-out of response compression for all requests to the server
- --flux-version string The version of Flux to install. (default "0.37.0")
+ --flux-version string The version of Flux to install. (default "2.0.1")
-h, --help help for run
--no-bootstrap Disable bootstrapping at shutdown.
--no-session Disable session management. If not specified, the session will be enabled by default.
--port-forward string Forward the port from a cluster's resource to your local machine i.e. 'port=8080:8080,resource=svc/app'.
--root-dir string Specify the root directory to watch for changes. If not specified, the root of Git repository will be used.
- --session-name string Specify the name of the session. If not specified, the name of the current branch and the last commit id will be used. (default "run-main-adda33ef-dirty")
+ --session-name string Specify the name of the session. If not specified, the name of the current branch and the last commit id will be used. (default "run-main-3dd7cb6e-dirty")
--session-namespace string Specify the namespace of the session. (default "default")
--skip-dashboard-install Skip installation of the Dashboard. This also disables the prompt asking whether the Dashboard should be installed.
--skip-resource-cleanup Skip resource cleanup. If not specified, the GitOps Run resources will be deleted by default.
diff --git a/website/docs/references/cli-reference/gitops_set.md b/website/docs/references/cli-reference/gitops_set.md
index 5dc3aff778..c85fbf6893 100644
--- a/website/docs/references/cli-reference/gitops_set.md
+++ b/website/docs/references/cli-reference/gitops_set.md
@@ -32,4 +32,4 @@ gitops set config analytics true
* [gitops](gitops.md) - Weave GitOps
* [gitops set config](gitops_set_config.md) - Set the CLI configuration for Weave GitOps
-###### Auto generated by spf13/cobra on 19-Jul-2023
+###### Auto generated by spf13/cobra on 2-Aug-2023
diff --git a/website/docs/references/cli-reference/gitops_suspend.md b/website/docs/references/cli-reference/gitops_suspend.md
index f86f7d3b45..702c994988 100644
--- a/website/docs/references/cli-reference/gitops_suspend.md
+++ b/website/docs/references/cli-reference/gitops_suspend.md
@@ -33,4 +33,4 @@ gitops resume terraform --namespace flux-system my-resource
* [gitops](gitops.md) - Weave GitOps
* [gitops suspend terraform](gitops_suspend_terraform.md) - Suspend a Terraform object
-###### Auto generated by spf13/cobra on 19-Jul-2023
+###### Auto generated by spf13/cobra on 2-Aug-2023
diff --git a/website/docs/references/cli-reference/gitops_suspend_terraform.md b/website/docs/references/cli-reference/gitops_suspend_terraform.md
index 7be610f60a..ea62f790e1 100644
--- a/website/docs/references/cli-reference/gitops_suspend_terraform.md
+++ b/website/docs/references/cli-reference/gitops_suspend_terraform.md
@@ -38,4 +38,4 @@ gitops suspend terraform --namespace flux-system my-resource
* [gitops suspend](gitops_suspend.md) - Suspend a resource
-###### Auto generated by spf13/cobra on 19-Jul-2023
+###### Auto generated by spf13/cobra on 2-Aug-2023
diff --git a/website/docs/references/cli-reference/gitops_version.md b/website/docs/references/cli-reference/gitops_version.md
index 68a073fd21..3c76d9a0bb 100644
--- a/website/docs/references/cli-reference/gitops_version.md
+++ b/website/docs/references/cli-reference/gitops_version.md
@@ -27,4 +27,4 @@ gitops version [flags]
* [gitops](gitops.md) - Weave GitOps
-###### Auto generated by spf13/cobra on 19-Jul-2023
+###### Auto generated by spf13/cobra on 2-Aug-2023
diff --git a/website/docs/references/helm-reference.md b/website/docs/references/helm-reference.md
index 858613d8d1..1f156fae41 100644
--- a/website/docs/references/helm-reference.md
+++ b/website/docs/references/helm-reference.md
@@ -5,7 +5,7 @@ This is a reference of all the configurable values in Weave GitOps's
Helm chart. This is intended for customizing your installation after
you've gone through the [getting started](../intro-weave-gitops.mdx) guide.
-This reference was generated for the chart version 4.0.26 which installs weave gitops v0.28.0.
+This reference was generated for the chart version 4.0.27 which installs weave gitops v0.29.0.
## Values
@@ -27,7 +27,7 @@ This reference was generated for the chart version 4.0.26 which installs weave g
| fullnameOverride | string | `""` | |
| image.pullPolicy | string | `"IfNotPresent"` | |
| image.repository | string | `"ghcr.io/weaveworks/wego-app"` | |
-| image.tag | string | `"v0.28.0"` | |
+| image.tag | string | `"v0.29.0"` | |
| imagePullSecrets | list | `[]` | |
| ingress.annotations | object | `{}` | |
| ingress.className | string | `""` | |
diff --git a/website/versioned_docs/version-0.29.0/_components/CurlCodeBlock.jsx b/website/versioned_docs/version-0.29.0/_components/CurlCodeBlock.jsx
new file mode 100644
index 0000000000..b27993ae63
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/_components/CurlCodeBlock.jsx
@@ -0,0 +1,24 @@
+import React from "react";
+
+import CodeBlock from "@theme/CodeBlock";
+import BrowserOnly from "@docusaurus/BrowserOnly";
+
+export default function CurlCodeBlock({ localPath, hostedPath, content }) {
+ return (
+ <>
+
+ {() => (
+
+ curl -o {localPath} {window.location.protocol}
+ //{window.location.host}
+ {hostedPath}
+
+ )}
+
+
+
+ {content}
+
+ >
+ );
+}
diff --git a/website/versioned_docs/version-0.29.0/_components/TierLabel.jsx b/website/versioned_docs/version-0.29.0/_components/TierLabel.jsx
new file mode 100644
index 0000000000..1bb36bdbaf
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/_components/TierLabel.jsx
@@ -0,0 +1,20 @@
+import React from "react";
+import Link from "@docusaurus/Link";
+import useGlobalData from "@docusaurus/useGlobalData";
+
+const containerStyle = {
+ fontSize: 16,
+ marginLeft: 4,
+ fontVariant: "all-small-caps",
+};
+
+export default function TierLabel({ tiers }) {
+ return (
+
+ {tiers}
+
+ );
+}
diff --git a/website/versioned_docs/version-0.29.0/_components/_alpha_warning.mdx b/website/versioned_docs/version-0.29.0/_components/_alpha_warning.mdx
new file mode 100644
index 0000000000..48e5112fb7
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/_components/_alpha_warning.mdx
@@ -0,0 +1,9 @@
+
+:::caution
+
+**This feature is in alpha and certain aspects will change**
+
+We're very excited for people to use this feature.
+However, please note that changes in the API, behaviour and security will evolve.
+The feature is suitable to use in controlled testing environments.
+:::
\ No newline at end of file
diff --git a/website/versioned_docs/version-0.29.0/assets/dashboards/explorer.json b/website/versioned_docs/version-0.29.0/assets/dashboards/explorer.json
new file mode 100644
index 0000000000..9d27ee6930
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/assets/dashboards/explorer.json
@@ -0,0 +1,1200 @@
+{
+ "annotations": {
+ "list": [
+ {
+ "builtIn": 1,
+ "datasource": {
+ "type": "grafana",
+ "uid": "-- Grafana --"
+ },
+ "enable": true,
+ "hide": true,
+ "iconColor": "rgba(0, 211, 255, 1)",
+ "name": "Annotations & Alerts",
+ "target": {
+ "limit": 100,
+ "matchAny": false,
+ "tags": [],
+ "type": "dashboard"
+ },
+ "type": "dashboard"
+ }
+ ]
+ },
+ "description": "weave gitops explorer metrics",
+ "editable": true,
+ "fiscalYearStartMonth": 0,
+ "graphTooltip": 0,
+ "id": 3,
+ "links": [],
+ "liveNow": false,
+ "panels": [
+ {
+ "collapsed": false,
+ "gridPos": {
+ "h": 1,
+ "w": 24,
+ "x": 0,
+ "y": 0
+ },
+ "id": 16,
+ "panels": [],
+ "title": "SLOs",
+ "type": "row"
+ },
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "prometheus"
+ },
+ "fieldConfig": {
+ "defaults": {
+ "color": {
+ "mode": "thresholds"
+ },
+ "mappings": [],
+ "thresholds": {
+ "mode": "absolute",
+ "steps": [
+ {
+ "color": "red",
+ "value": null
+ },
+ {
+ "color": "green",
+ "value": 99
+ }
+ ]
+ }
+ },
+ "overrides": []
+ },
+ "gridPos": {
+ "h": 5,
+ "w": 24,
+ "x": 0,
+ "y": 1
+ },
+ "id": 17,
+ "options": {
+ "colorMode": "value",
+ "graphMode": "area",
+ "justifyMode": "auto",
+ "orientation": "auto",
+ "reduceOptions": {
+ "calcs": [
+ "lastNotNull"
+ ],
+ "fields": "",
+ "values": false
+ },
+ "textMode": "auto"
+ },
+ "pluginVersion": "10.0.2",
+ "targets": [
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "P1809F7CD0C75ACF3"
+ },
+ "editorMode": "code",
+ "expr": "sum(rate(http_request_duration_seconds_count{handler=\"/v1/query\", code=\"200\"}[30m])) * 100 / sum(rate(http_request_duration_seconds_count{handler=\"/v1/query\"}[30m]))",
+ "legendFormat": "total",
+ "range": true,
+ "refId": "A"
+ }
+ ],
+ "title": "Availability",
+ "type": "stat"
+ },
+ {
+ "collapsed": false,
+ "gridPos": {
+ "h": 1,
+ "w": 24,
+ "x": 0,
+ "y": 6
+ },
+ "id": 6,
+ "panels": [],
+ "title": "Query",
+ "type": "row"
+ },
+ {
+ "aliasColors": {},
+ "bars": false,
+ "dashLength": 10,
+ "dashes": false,
+ "datasource": {
+ "type": "prometheus",
+ "uid": "prometheus"
+ },
+ "fill": 1,
+ "fillGradient": 0,
+ "gridPos": {
+ "h": 5,
+ "w": 12,
+ "x": 0,
+ "y": 7
+ },
+ "hiddenSeries": false,
+ "id": 2,
+ "legend": {
+ "alignAsTable": true,
+ "avg": true,
+ "current": false,
+ "max": true,
+ "min": true,
+ "rightSide": false,
+ "show": true,
+ "total": false,
+ "values": true
+ },
+ "lines": true,
+ "linewidth": 1,
+ "nullPointMode": "null",
+ "options": {
+ "alertThreshold": true
+ },
+ "percentage": false,
+ "pluginVersion": "10.0.2",
+ "pointradius": 2,
+ "points": false,
+ "renderer": "flot",
+ "seriesOverrides": [],
+ "spaceLength": 10,
+ "stack": false,
+ "steppedLine": false,
+ "targets": [
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "P1809F7CD0C75ACF3"
+ },
+ "editorMode": "code",
+ "expr": "sum(rate(http_request_duration_seconds_count{handler=\"/v1/query\"}[2m]))",
+ "legendFormat": "total",
+ "range": true,
+ "refId": "A"
+ },
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "prometheus"
+ },
+ "editorMode": "code",
+ "expr": "sum(rate(http_request_duration_seconds_count{handler=\"/v1/query\",code!~\"2..\"}[2m]))",
+ "hide": false,
+ "legendFormat": "errors",
+ "range": true,
+ "refId": "B"
+ }
+ ],
+ "thresholds": [],
+ "timeRegions": [],
+ "title": "Query Requests Rate",
+ "tooltip": {
+ "shared": true,
+ "sort": 0,
+ "value_type": "individual"
+ },
+ "type": "graph",
+ "xaxis": {
+ "mode": "time",
+ "show": true,
+ "values": []
+ },
+ "yaxes": [
+ {
+ "$$hashKey": "object:1215",
+ "format": "short",
+ "logBase": 1,
+ "show": true
+ },
+ {
+ "$$hashKey": "object:1216",
+ "format": "short",
+ "logBase": 1
+ }
+ ],
+ "yaxis": {
+ "align": true
+ }
+ },
+ {
+ "aliasColors": {},
+ "bars": false,
+ "dashLength": 10,
+ "dashes": false,
+ "datasource": {
+ "type": "prometheus",
+ "uid": "prometheus"
+ },
+ "fill": 1,
+ "fillGradient": 0,
+ "gridPos": {
+ "h": 5,
+ "w": 12,
+ "x": 12,
+ "y": 7
+ },
+ "hiddenSeries": false,
+ "id": 1,
+ "legend": {
+ "alignAsTable": true,
+ "avg": true,
+ "current": false,
+ "max": true,
+ "min": true,
+ "rightSide": false,
+ "show": true,
+ "total": false,
+ "values": true
+ },
+ "lines": true,
+ "linewidth": 1,
+ "nullPointMode": "null",
+ "options": {
+ "alertThreshold": true
+ },
+ "percentage": false,
+ "pluginVersion": "10.0.2",
+ "pointradius": 2,
+ "points": false,
+ "renderer": "flot",
+ "seriesOverrides": [],
+ "spaceLength": 10,
+ "stack": false,
+ "steppedLine": false,
+ "targets": [
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "P1809F7CD0C75ACF3"
+ },
+ "editorMode": "code",
+ "expr": "sum(rate(http_request_duration_seconds_sum{code=\"200\",handler=\"/v1/query\",method=\"POST\"}[2m])) / sum(rate(http_request_duration_seconds_count{code=\"200\",handler=\"/v1/query\",method=\"POST\"}[2m]))",
+ "legendFormat": "200s",
+ "range": true,
+ "refId": "A"
+ }
+ ],
+ "thresholds": [],
+ "timeRegions": [],
+ "title": "Query Requests Duration",
+ "tooltip": {
+ "shared": true,
+ "sort": 0,
+ "value_type": "individual"
+ },
+ "type": "graph",
+ "xaxis": {
+ "mode": "time",
+ "show": true,
+ "values": []
+ },
+ "yaxes": [
+ {
+ "$$hashKey": "object:923",
+ "format": "s",
+ "label": "Latency",
+ "show": true
+ },
+ {
+ "$$hashKey": "object:924",
+ "format": "short"
+ }
+ ],
+ "yaxis": {
+ "align": true
+ }
+ },
+ {
+ "aliasColors": {},
+ "bars": false,
+ "dashLength": 10,
+ "dashes": false,
+ "datasource": {
+ "type": "prometheus",
+ "uid": "prometheus"
+ },
+ "fill": 1,
+ "fillGradient": 0,
+ "gridPos": {
+ "h": 5,
+ "w": 12,
+ "x": 0,
+ "y": 12
+ },
+ "hiddenSeries": false,
+ "id": 10,
+ "legend": {
+ "alignAsTable": true,
+ "avg": true,
+ "current": false,
+ "max": false,
+ "min": false,
+ "rightSide": true,
+ "show": true,
+ "total": false,
+ "values": true
+ },
+ "lines": true,
+ "linewidth": 1,
+ "nullPointMode": "null",
+ "options": {
+ "alertThreshold": true
+ },
+ "percentage": false,
+ "pluginVersion": "10.0.2",
+ "pointradius": 2,
+ "points": false,
+ "renderer": "flot",
+ "seriesOverrides": [],
+ "spaceLength": 10,
+ "stack": false,
+ "steppedLine": false,
+ "targets": [
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "P1809F7CD0C75ACF3"
+ },
+ "editorMode": "code",
+ "expr": "sum(rate(datastore_latency_seconds_count{action=~\"Get.*\"}[2m])) by (action)",
+ "legendFormat": "{{action}}",
+ "range": true,
+ "refId": "A"
+ }
+ ],
+ "thresholds": [],
+ "timeRegions": [],
+ "title": "Datastore Read Request Rate",
+ "tooltip": {
+ "shared": true,
+ "sort": 0,
+ "value_type": "individual"
+ },
+ "type": "graph",
+ "xaxis": {
+ "mode": "time",
+ "show": true,
+ "values": []
+ },
+ "yaxes": [
+ {
+ "format": "short"
+ },
+ {
+ "format": "short"
+ }
+ ],
+ "yaxis": {
+ "align": true
+ }
+ },
+ {
+ "aliasColors": {},
+ "bars": false,
+ "dashLength": 10,
+ "dashes": false,
+ "datasource": {
+ "type": "prometheus",
+ "uid": "prometheus"
+ },
+ "fill": 1,
+ "fillGradient": 0,
+ "gridPos": {
+ "h": 5,
+ "w": 12,
+ "x": 12,
+ "y": 12
+ },
+ "hiddenSeries": false,
+ "id": 11,
+ "legend": {
+ "alignAsTable": true,
+ "avg": true,
+ "current": false,
+ "max": true,
+ "min": true,
+ "show": true,
+ "total": false,
+ "values": true
+ },
+ "lines": true,
+ "linewidth": 1,
+ "nullPointMode": "null",
+ "options": {
+ "alertThreshold": true
+ },
+ "percentage": false,
+ "pluginVersion": "10.0.2",
+ "pointradius": 2,
+ "points": false,
+ "renderer": "flot",
+ "seriesOverrides": [],
+ "spaceLength": 10,
+ "stack": false,
+ "steppedLine": false,
+ "targets": [
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "P1809F7CD0C75ACF3"
+ },
+ "editorMode": "code",
+ "expr": "sum(rate(datastore_latency_seconds_sum{action=~\"Get.*\",status=\"success\"}[2m])) / sum(rate(datastore_latency_seconds_count{action=~\"Get.*\",status=\"success\"}[2m]))\n",
+ "legendFormat": "success",
+ "range": true,
+ "refId": "A"
+ }
+ ],
+ "thresholds": [],
+ "timeRegions": [],
+ "title": "Datastore Read Requests Duration",
+ "tooltip": {
+ "shared": true,
+ "sort": 0,
+ "value_type": "individual"
+ },
+ "type": "graph",
+ "xaxis": {
+ "mode": "time",
+ "show": true,
+ "values": []
+ },
+ "yaxes": [
+ {
+ "$$hashKey": "object:725",
+ "format": "s",
+ "label": "Latency",
+ "show": true
+ },
+ {
+ "$$hashKey": "object:726",
+ "format": "short"
+ }
+ ],
+ "yaxis": {
+ "align": true
+ }
+ },
+ {
+ "aliasColors": {},
+ "bars": false,
+ "dashLength": 10,
+ "dashes": false,
+ "datasource": {
+ "type": "prometheus",
+ "uid": "prometheus"
+ },
+ "fill": 1,
+ "fillGradient": 0,
+ "gridPos": {
+ "h": 5,
+ "w": 12,
+ "x": 0,
+ "y": 17
+ },
+ "hiddenSeries": false,
+ "id": 13,
+ "legend": {
+ "alignAsTable": true,
+ "avg": true,
+ "current": false,
+ "max": false,
+ "min": false,
+ "rightSide": true,
+ "show": true,
+ "total": false,
+ "values": true
+ },
+ "lines": true,
+ "linewidth": 1,
+ "nullPointMode": "null",
+ "options": {
+ "alertThreshold": true
+ },
+ "percentage": false,
+ "pluginVersion": "10.0.2",
+ "pointradius": 2,
+ "points": false,
+ "renderer": "flot",
+ "seriesOverrides": [],
+ "spaceLength": 10,
+ "stack": false,
+ "steppedLine": false,
+ "targets": [
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "P1809F7CD0C75ACF3"
+ },
+ "editorMode": "code",
+ "expr": "sum(irate(indexer_latency_seconds_count[2m])) by (action)",
+ "legendFormat": "{{action}}",
+ "range": true,
+ "refId": "A"
+ }
+ ],
+ "thresholds": [],
+ "timeRegions": [],
+ "title": "Indexer Read Request Rate",
+ "tooltip": {
+ "shared": true,
+ "sort": 0,
+ "value_type": "individual"
+ },
+ "type": "graph",
+ "xaxis": {
+ "mode": "time",
+ "show": true,
+ "values": []
+ },
+ "yaxes": [
+ {
+ "format": "short"
+ },
+ {
+ "format": "short"
+ }
+ ],
+ "yaxis": {
+ "align": true
+ }
+ },
+ {
+ "aliasColors": {},
+ "bars": false,
+ "dashLength": 10,
+ "dashes": false,
+ "datasource": {
+ "type": "prometheus",
+ "uid": "prometheus"
+ },
+ "fill": 1,
+ "fillGradient": 0,
+ "gridPos": {
+ "h": 5,
+ "w": 12,
+ "x": 12,
+ "y": 17
+ },
+ "hiddenSeries": false,
+ "id": 19,
+ "legend": {
+ "alignAsTable": true,
+ "avg": true,
+ "current": false,
+ "max": false,
+ "min": false,
+ "show": true,
+ "total": false,
+ "values": true
+ },
+ "lines": true,
+ "linewidth": 1,
+ "nullPointMode": "null",
+ "options": {
+ "alertThreshold": true
+ },
+ "percentage": false,
+ "pluginVersion": "10.0.2",
+ "pointradius": 2,
+ "points": false,
+ "renderer": "flot",
+ "seriesOverrides": [],
+ "spaceLength": 10,
+ "stack": false,
+ "steppedLine": false,
+ "targets": [
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "P1809F7CD0C75ACF3"
+ },
+ "editorMode": "code",
+ "expr": "sum(rate(indexer_latency_seconds_sum{status=\"success\"}[2m])) / sum(rate(indexer_latency_seconds_count{status=\"success\"}[2m]))\n",
+ "legendFormat": "success",
+ "range": true,
+ "refId": "A"
+ }
+ ],
+ "thresholds": [],
+ "timeRegions": [],
+ "title": "Indexer Read Requests Duration",
+ "tooltip": {
+ "shared": true,
+ "sort": 0,
+ "value_type": "individual"
+ },
+ "type": "graph",
+ "xaxis": {
+ "mode": "time",
+ "show": true,
+ "values": []
+ },
+ "yaxes": [
+ {
+ "$$hashKey": "object:725",
+ "format": "s",
+ "label": "Latency",
+ "show": true
+ },
+ {
+ "$$hashKey": "object:726",
+ "format": "short"
+ }
+ ],
+ "yaxis": {
+ "align": true
+ }
+ },
+ {
+ "collapsed": false,
+ "gridPos": {
+ "h": 1,
+ "w": 24,
+ "x": 0,
+ "y": 22
+ },
+ "id": 7,
+ "panels": [],
+ "title": "Collector",
+ "type": "row"
+ },
+ {
+ "aliasColors": {},
+ "bars": false,
+ "dashLength": 10,
+ "dashes": false,
+ "datasource": {
+ "type": "prometheus",
+ "uid": "prometheus"
+ },
+ "fill": 1,
+ "fillGradient": 0,
+ "gridPos": {
+ "h": 5,
+ "w": 12,
+ "x": 0,
+ "y": 23
+ },
+ "hiddenSeries": false,
+ "id": 20,
+ "legend": {
+ "alignAsTable": true,
+ "avg": false,
+ "current": true,
+ "max": false,
+ "min": false,
+ "rightSide": true,
+ "show": true,
+ "total": false,
+ "values": true
+ },
+ "lines": true,
+ "linewidth": 1,
+ "nullPointMode": "null",
+ "options": {
+ "alertThreshold": true
+ },
+ "percentage": false,
+ "pluginVersion": "10.0.2",
+ "pointradius": 2,
+ "points": false,
+ "renderer": "flot",
+ "seriesOverrides": [],
+ "spaceLength": 10,
+ "stack": false,
+ "steppedLine": false,
+ "targets": [
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "P1809F7CD0C75ACF3"
+ },
+ "editorMode": "code",
+ "expr": "collector_cluster_watcher{collector=\"objects\"}",
+ "legendFormat": "{{status}}",
+ "range": true,
+ "refId": "A"
+ }
+ ],
+ "thresholds": [],
+ "timeRegions": [],
+ "title": "Objects Cluster Watchers ",
+ "tooltip": {
+ "shared": true,
+ "sort": 0,
+ "value_type": "individual"
+ },
+ "type": "graph",
+ "xaxis": {
+ "mode": "time",
+ "show": true,
+ "values": []
+ },
+ "yaxes": [
+ {
+ "$$hashKey": "object:1215",
+ "format": "short",
+ "logBase": 1,
+ "show": true
+ },
+ {
+ "$$hashKey": "object:1216",
+ "format": "short",
+ "logBase": 1
+ }
+ ],
+ "yaxis": {
+ "align": true
+ }
+ },
+ {
+ "aliasColors": {},
+ "bars": false,
+ "dashLength": 10,
+ "dashes": false,
+ "datasource": {},
+ "fill": 1,
+ "fillGradient": 0,
+ "gridPos": {
+ "h": 5,
+ "w": 12,
+ "x": 12,
+ "y": 23
+ },
+ "hiddenSeries": false,
+ "id": 21,
+ "legend": {
+ "alignAsTable": true,
+ "avg": false,
+ "current": true,
+ "max": false,
+ "min": false,
+ "rightSide": true,
+ "show": true,
+ "total": false,
+ "values": true
+ },
+ "lines": true,
+ "linewidth": 1,
+ "nullPointMode": "null",
+ "options": {
+ "alertThreshold": true
+ },
+ "percentage": false,
+ "pluginVersion": "10.0.2",
+ "pointradius": 2,
+ "points": false,
+ "renderer": "flot",
+ "seriesOverrides": [],
+ "spaceLength": 10,
+ "stack": false,
+ "steppedLine": false,
+ "targets": [
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "P1809F7CD0C75ACF3"
+ },
+ "editorMode": "code",
+ "expr": "collector_cluster_watcher{collector=\"roles\"}",
+ "legendFormat": "{{status}}",
+ "range": true,
+ "refId": "A"
+ }
+ ],
+ "thresholds": [],
+ "timeRegions": [],
+ "title": "RBAC Cluster Watchers",
+ "tooltip": {
+ "shared": true,
+ "sort": 0,
+ "value_type": "individual"
+ },
+ "type": "graph",
+ "xaxis": {
+ "mode": "time",
+ "show": true,
+ "values": []
+ },
+ "yaxes": [
+ {
+ "$$hashKey": "object:1215",
+ "format": "short",
+ "logBase": 1,
+ "show": true
+ },
+ {
+ "$$hashKey": "object:1216",
+ "format": "short",
+ "logBase": 1
+ }
+ ],
+ "yaxis": {
+ "align": true
+ }
+ },
+ {
+ "aliasColors": {},
+ "bars": false,
+ "dashLength": 10,
+ "dashes": false,
+ "datasource": {
+ "type": "prometheus",
+ "uid": "prometheus"
+ },
+ "fill": 1,
+ "fillGradient": 0,
+ "gridPos": {
+ "h": 5,
+ "w": 12,
+ "x": 0,
+ "y": 28
+ },
+ "hiddenSeries": false,
+ "id": 12,
+ "legend": {
+ "avg": false,
+ "current": false,
+ "max": false,
+ "min": false,
+ "show": true,
+ "total": false,
+ "values": false
+ },
+ "lines": true,
+ "linewidth": 1,
+ "nullPointMode": "null",
+ "options": {
+ "alertThreshold": true
+ },
+ "percentage": false,
+ "pluginVersion": "10.0.2",
+ "pointradius": 2,
+ "points": false,
+ "renderer": "flot",
+ "seriesOverrides": [],
+ "spaceLength": 10,
+ "stack": false,
+ "steppedLine": false,
+ "targets": [
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "P1809F7CD0C75ACF3"
+ },
+ "editorMode": "code",
+ "expr": "sum(irate(datastore_latency_seconds_count{action=~\"Store.*\"}[2m])) by (action)",
+ "legendFormat": "{{action}}",
+ "range": true,
+ "refId": "A"
+ }
+ ],
+ "thresholds": [],
+ "timeRegions": [],
+ "title": "Datastore Write Request Rate",
+ "tooltip": {
+ "shared": true,
+ "sort": 0,
+ "value_type": "individual"
+ },
+ "type": "graph",
+ "xaxis": {
+ "mode": "time",
+ "show": true,
+ "values": []
+ },
+ "yaxes": [
+ {
+ "$$hashKey": "object:384",
+ "format": "short"
+ },
+ {
+ "$$hashKey": "object:385",
+ "format": "short"
+ }
+ ],
+ "yaxis": {
+ "align": true
+ }
+ },
+ {
+ "aliasColors": {},
+ "bars": false,
+ "dashLength": 10,
+ "dashes": false,
+ "datasource": {
+ "type": "prometheus",
+ "uid": "prometheus"
+ },
+ "fill": 1,
+ "fillGradient": 0,
+ "gridPos": {
+ "h": 5,
+ "w": 12,
+ "x": 12,
+ "y": 28
+ },
+ "hiddenSeries": false,
+ "id": 14,
+ "legend": {
+ "avg": false,
+ "current": false,
+ "max": false,
+ "min": false,
+ "show": true,
+ "total": false,
+ "values": false
+ },
+ "lines": true,
+ "linewidth": 1,
+ "nullPointMode": "null",
+ "options": {
+ "alertThreshold": true
+ },
+ "percentage": false,
+ "pluginVersion": "10.0.2",
+ "pointradius": 2,
+ "points": false,
+ "renderer": "flot",
+ "seriesOverrides": [],
+ "spaceLength": 10,
+ "stack": false,
+ "steppedLine": false,
+ "targets": [
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "P1809F7CD0C75ACF3"
+ },
+ "editorMode": "code",
+ "expr": "sum(rate(datastore_latency_seconds_sum{action=~\"Store.*\",status=\"success\"}[2m])) / sum(rate(datastore_latency_seconds_count{action=~\"Store.*\",status=\"success\"}[2m]))\n",
+ "legendFormat": "success",
+ "range": true,
+ "refId": "A"
+ }
+ ],
+ "thresholds": [],
+ "timeRegions": [],
+ "title": "Datastore Write Requests Duration",
+ "tooltip": {
+ "shared": true,
+ "sort": 0,
+ "value_type": "individual"
+ },
+ "type": "graph",
+ "xaxis": {
+ "mode": "time",
+ "show": true,
+ "values": []
+ },
+ "yaxes": [
+ {
+ "$$hashKey": "object:725",
+ "format": "s",
+ "label": "Latency",
+ "show": true
+ },
+ {
+ "$$hashKey": "object:726",
+ "format": "short"
+ }
+ ],
+ "yaxis": {
+ "align": true
+ }
+ },
+ {
+ "aliasColors": {},
+ "bars": false,
+ "dashLength": 10,
+ "dashes": false,
+ "datasource": {
+ "type": "prometheus",
+ "uid": "prometheus"
+ },
+ "fill": 1,
+ "fillGradient": 0,
+ "gridPos": {
+ "h": 5,
+ "w": 12,
+ "x": 0,
+ "y": 33
+ },
+ "hiddenSeries": false,
+ "id": 22,
+ "legend": {
+ "avg": false,
+ "current": false,
+ "max": false,
+ "min": false,
+ "show": true,
+ "total": false,
+ "values": false
+ },
+ "lines": true,
+ "linewidth": 1,
+ "nullPointMode": "null",
+ "options": {
+ "alertThreshold": true
+ },
+ "percentage": false,
+ "pluginVersion": "10.0.2",
+ "pointradius": 2,
+ "points": false,
+ "renderer": "flot",
+ "seriesOverrides": [],
+ "spaceLength": 10,
+ "stack": false,
+ "steppedLine": false,
+ "targets": [
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "P1809F7CD0C75ACF3"
+ },
+ "editorMode": "code",
+ "expr": "sum(irate(indexer_latency_seconds_count{action=~\"Add|Remove.*\"}[2m])) by (action)",
+ "legendFormat": "{{action}}",
+ "range": true,
+ "refId": "A"
+ }
+ ],
+ "thresholds": [],
+ "timeRegions": [],
+ "title": "Indexer Write Request Rate",
+ "tooltip": {
+ "shared": true,
+ "sort": 0,
+ "value_type": "individual"
+ },
+ "type": "graph",
+ "xaxis": {
+ "mode": "time",
+ "show": true,
+ "values": []
+ },
+ "yaxes": [
+ {
+ "$$hashKey": "object:384",
+ "format": "short"
+ },
+ {
+ "$$hashKey": "object:385",
+ "format": "short"
+ }
+ ],
+ "yaxis": {
+ "align": true
+ }
+ },
+ {
+ "aliasColors": {},
+ "bars": false,
+ "dashLength": 10,
+ "dashes": false,
+ "datasource": {
+ "type": "prometheus",
+ "uid": "prometheus"
+ },
+ "fill": 1,
+ "fillGradient": 0,
+ "gridPos": {
+ "h": 5,
+ "w": 12,
+ "x": 12,
+ "y": 33
+ },
+ "hiddenSeries": false,
+ "id": 23,
+ "legend": {
+ "avg": false,
+ "current": false,
+ "max": false,
+ "min": false,
+ "show": true,
+ "total": false,
+ "values": false
+ },
+ "lines": true,
+ "linewidth": 1,
+ "nullPointMode": "null",
+ "options": {
+ "alertThreshold": true
+ },
+ "percentage": false,
+ "pluginVersion": "10.0.2",
+ "pointradius": 2,
+ "points": false,
+ "renderer": "flot",
+ "seriesOverrides": [],
+ "spaceLength": 10,
+ "stack": false,
+ "steppedLine": false,
+ "targets": [
+ {
+ "datasource": {
+ "type": "prometheus",
+ "uid": "P1809F7CD0C75ACF3"
+ },
+ "editorMode": "code",
+ "expr": "sum(rate(indexer_latency_seconds_sum{action=~\"Add|Remove.*\",status=\"success\"}[2m])) / sum(rate(indexer_latency_seconds_count{action=~\"Add|Remove.*\",status=\"success\"}[2m]))\n",
+ "legendFormat": "success",
+ "range": true,
+ "refId": "A"
+ }
+ ],
+ "thresholds": [],
+ "timeRegions": [],
+ "title": "Indexer Write Requests Duration",
+ "tooltip": {
+ "shared": true,
+ "sort": 0,
+ "value_type": "individual"
+ },
+ "type": "graph",
+ "xaxis": {
+ "mode": "time",
+ "show": true,
+ "values": []
+ },
+ "yaxes": [
+ {
+ "$$hashKey": "object:725",
+ "format": "s",
+ "label": "Latency",
+ "show": true
+ },
+ {
+ "$$hashKey": "object:726",
+ "format": "short"
+ }
+ ],
+ "yaxis": {
+ "align": true
+ }
+ }
+ ],
+ "refresh": "5s",
+ "schemaVersion": 38,
+ "style": "dark",
+ "tags": [],
+ "templating": {
+ "list": []
+ },
+ "time": {
+ "from": "now-15m",
+ "to": "now"
+ },
+ "timepicker": {},
+ "timezone": "",
+ "title": "Explorer",
+ "uid": "Lp7_c9UVk",
+ "version": 2,
+ "weekStart": ""
+}
diff --git a/website/versioned_docs/version-0.29.0/assets/example-enterprise-helm.yaml b/website/versioned_docs/version-0.29.0/assets/example-enterprise-helm.yaml
new file mode 100644
index 0000000000..c5107f22e4
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/assets/example-enterprise-helm.yaml
@@ -0,0 +1,48 @@
+apiVersion: source.toolkit.fluxcd.io/v1beta2
+kind: HelmRepository
+metadata:
+ name: weave-gitops-enterprise-charts
+ namespace: flux-system
+spec:
+ interval: 60m
+ secretRef:
+ name: weave-gitops-enterprise-credentials
+ url: https://charts.dev.wkp.weave.works/releases/charts-v3
+---
+apiVersion: helm.toolkit.fluxcd.io/v2beta1
+kind: HelmRelease
+metadata:
+ name: weave-gitops-enterprise
+ namespace: flux-system
+spec:
+ chart:
+ spec:
+ interval: 65m
+ chart: mccp
+ sourceRef:
+ kind: HelmRepository
+ name: weave-gitops-enterprise-charts
+ namespace: flux-system
+ version: 0.x.x
+ install:
+ crds: CreateReplace
+ upgrade:
+ crds: CreateReplace
+ interval: 50m
+ values:
+ # -- Configure TLS settings if needed
+ # tls:
+ # -- Can be disabled if TLS is handled by a user-provided ingress controller
+ # enabled: true
+ # -- optionally specify a TLS secret
+ # secretName: null
+ config:
+ capi:
+ repositoryURL: https://github.com/$GITHUB_USER/fleet-infra
+ # -- Can be changed depending on your git repo structure
+ # repositoryPath: ./clusters/management/clusters
+ # repositoryClustersPath: ./cluster
+ git:
+ type: github
+ # -- Change if using on-prem github/gitlab
+ # hostname: https://github.com
diff --git a/website/versioned_docs/version-0.29.0/assets/templates/.keep b/website/versioned_docs/version-0.29.0/assets/templates/.keep
new file mode 100644
index 0000000000..dc92bc0885
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/assets/templates/.keep
@@ -0,0 +1 @@
+"# keep"
\ No newline at end of file
diff --git a/website/versioned_docs/version-0.29.0/assets/templates/capd-template.yaml b/website/versioned_docs/version-0.29.0/assets/templates/capd-template.yaml
new file mode 100644
index 0000000000..96e687afbe
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/assets/templates/capd-template.yaml
@@ -0,0 +1,162 @@
+apiVersion: templates.weave.works/v1alpha2
+kind: GitOpsTemplate
+metadata:
+ name: cluster-template-development
+ namespace: default
+ annotations:
+ templates.weave.works/add-common-bases: "true"
+ templates.weave.works/inject-prune-annotation: "true"
+ labels:
+ weave.works/template-type: cluster
+spec:
+ description: A simple CAPD template
+ params:
+ - name: CLUSTER_NAME
+ required: true
+ description: This is used for the cluster naming.
+ - name: NAMESPACE
+ description: Namespace to create the cluster in
+ - name: KUBERNETES_VERSION
+ description: Kubernetes version to use for the cluster
+ options: ["1.19.11", "1.21.1", "1.22.0", "1.23.3"]
+ - name: CONTROL_PLANE_MACHINE_COUNT
+ description: Number of control planes
+ options: ["1", "2", "3"]
+ - name: WORKER_MACHINE_COUNT
+ description: Number of worker machines
+ resourcetemplates:
+ - content:
+ - apiVersion: gitops.weave.works/v1alpha1
+ kind: GitopsCluster
+ metadata:
+ name: "${CLUSTER_NAME}"
+ namespace: "${NAMESPACE}"
+ labels:
+ weave.works/capi: bootstrap
+ spec:
+ capiClusterRef:
+ name: "${CLUSTER_NAME}"
+ - apiVersion: cluster.x-k8s.io/v1beta1
+ kind: Cluster
+ metadata:
+ name: "${CLUSTER_NAME}"
+ namespace: "${NAMESPACE}"
+ labels:
+ cni: calico
+ spec:
+ clusterNetwork:
+ pods:
+ cidrBlocks:
+ - 192.168.0.0/16
+ serviceDomain: cluster.local
+ services:
+ cidrBlocks:
+ - 10.128.0.0/12
+ controlPlaneRef:
+ apiVersion: controlplane.cluster.x-k8s.io/v1beta1
+ kind: KubeadmControlPlane
+ name: "${CLUSTER_NAME}-control-plane"
+ namespace: "${NAMESPACE}"
+ infrastructureRef:
+ apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
+ kind: DockerCluster
+ name: "${CLUSTER_NAME}"
+ namespace: "${NAMESPACE}"
+ - apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
+ kind: DockerCluster
+ metadata:
+ name: "${CLUSTER_NAME}"
+ namespace: "${NAMESPACE}"
+ - apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
+ kind: DockerMachineTemplate
+ metadata:
+ name: "${CLUSTER_NAME}-control-plane"
+ namespace: "${NAMESPACE}"
+ spec:
+ template:
+ spec:
+ extraMounts:
+ - containerPath: /var/run/docker.sock
+ hostPath: /var/run/docker.sock
+ - apiVersion: controlplane.cluster.x-k8s.io/v1beta1
+ kind: KubeadmControlPlane
+ metadata:
+ name: "${CLUSTER_NAME}-control-plane"
+ namespace: "${NAMESPACE}"
+ spec:
+ kubeadmConfigSpec:
+ clusterConfiguration:
+ apiServer:
+ certSANs:
+ - localhost
+ - 127.0.0.1
+ - 0.0.0.0
+ controllerManager:
+ extraArgs:
+ enable-hostpath-provisioner: "true"
+ initConfiguration:
+ nodeRegistration:
+ criSocket: /var/run/containerd/containerd.sock
+ kubeletExtraArgs:
+ cgroup-driver: cgroupfs
+ eviction-hard: nodefs.available<0%,nodefs.inodesFree<0%,imagefs.available<0%
+ joinConfiguration:
+ nodeRegistration:
+ criSocket: /var/run/containerd/containerd.sock
+ kubeletExtraArgs:
+ cgroup-driver: cgroupfs
+ eviction-hard: nodefs.available<0%,nodefs.inodesFree<0%,imagefs.available<0%
+ machineTemplate:
+ infrastructureRef:
+ apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
+ kind: DockerMachineTemplate
+ name: "${CLUSTER_NAME}-control-plane"
+ namespace: "${NAMESPACE}"
+ replicas: "${CONTROL_PLANE_MACHINE_COUNT}"
+ version: "${KUBERNETES_VERSION}"
+ - apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
+ kind: DockerMachineTemplate
+ metadata:
+ name: "${CLUSTER_NAME}-md-0"
+ namespace: "${NAMESPACE}"
+ spec:
+ template:
+ spec: {}
+ - apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
+ kind: KubeadmConfigTemplate
+ metadata:
+ name: "${CLUSTER_NAME}-md-0"
+ namespace: "${NAMESPACE}"
+ spec:
+ template:
+ spec:
+ joinConfiguration:
+ nodeRegistration:
+ kubeletExtraArgs:
+ cgroup-driver: cgroupfs
+ eviction-hard: nodefs.available<0%,nodefs.inodesFree<0%,imagefs.available<0%
+ - apiVersion: cluster.x-k8s.io/v1beta1
+ kind: MachineDeployment
+ metadata:
+ name: "${CLUSTER_NAME}-md-0"
+ namespace: "${NAMESPACE}"
+ spec:
+ clusterName: "${CLUSTER_NAME}"
+ replicas: "${WORKER_MACHINE_COUNT}"
+ selector:
+ matchLabels: null
+ template:
+ spec:
+ bootstrap:
+ configRef:
+ apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
+ kind: KubeadmConfigTemplate
+ name: "${CLUSTER_NAME}-md-0"
+ namespace: "${NAMESPACE}"
+ clusterName: "${CLUSTER_NAME}"
+ infrastructureRef:
+ apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
+ kind: DockerMachineTemplate
+ name: "${CLUSTER_NAME}-md-0"
+ namespace: "${NAMESPACE}"
+ version: "${KUBERNETES_VERSION}"
diff --git a/website/versioned_docs/version-0.29.0/cluster-management/advanced-cluster-management-topics/howto-inject-credentials-into-template.mdx b/website/versioned_docs/version-0.29.0/cluster-management/advanced-cluster-management-topics/howto-inject-credentials-into-template.mdx
new file mode 100644
index 0000000000..5d0b9916fa
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/cluster-management/advanced-cluster-management-topics/howto-inject-credentials-into-template.mdx
@@ -0,0 +1,83 @@
+---
+title: How to Inject Credentials Into Your Template
+hide_title: true
+---
+
+import TierLabel from "@site/docs/_components/TierLabel";
+
+# How to Inject Credentials Into Your Template
+
+Weave GitOps _templates_ describe the properties of your cluster—how many nodes, what version of Kubernetes, etc. The _identity_ refers to which account will be used to create the cluster. When you render a template, you may want to set the credentials to be used for this cluster—for example, if the cost is allocated to a specific team.
+
+The rendered resource can be automatically configured with the selected credentials.
+
+Credentials are injected into the following resources:
+* AWSCluster, AWSManagedControlPlane
+* AzureCluster, AzureManagedCluster
+* VSphereCluster
+
+If no credentials are selected, no changes will be applied, and the credentials used by your CAPI controller will be used as the default.
+
+In our cluster we have the template:
+
+```yaml
+apiVersion: templates.weave.works/v1alpha2
+kind: GitOpsTemplate
+metadata:
+ name: capa-cluster-template
+spec:
+ resourcetemplates:
+ - contents:
+ - apiVersion: infrastructure.cluster.x-k8s.io/v1alpha4
+ kind: AWSCluster
+ metadata:
+ name: "${CLUSTER_NAME}"
+ spec:
+ region: "${AWS_REGION}"
+```
+
+and the identity
+
+```yaml
+apiVersion: infrastructure.cluster.x-k8s.io/v1alpha3
+kind: AWSClusterStaticIdentity
+metadata:
+ name: "test-account"
+spec:
+ secretRef:
+ name: test-account-creds
+ namespace: capa-system
+ allowedNamespaces:
+ selector:
+ matchLabels:
+ cluster.x-k8s.io/ns: "testlabel"
+```
+
+We can select Weave GitOps to use the `test-account` when creating the cluster by using the _Infrastructure provider credentials_ dropdown on the _Create new cluster with template_ page:
+
+![Identity Selection](./../img/identity-selection.png)
+
+The resulting definition will have the identity injected into the appropriate place in the template, for this example:
+
+```yaml
+apiVersion: infrastructure.cluster.x-k8s.io/v1alpha4
+kind: AWSCluster
+metadata:
+ name: example-cluster
+spec:
+ region: eu-north-1
+ identityRef:
+ kind: AWSClusterStaticIdentity
+ name: test-account
+```
+
+### `identityRef`s
+
+The supported providers implement multi-tenancy by setting an `identityRef` on the the provider cluster object, e.g. `AWSCluster`, `AzureCluster` or `VSphereCluster`.
+
+Weave GitOps will search _all namespaces_ in the cluster for potential identities that can be used to create a cluster. The following identity `kind`s are currently supported and their corresponding Cluster kinds:
+
+- `AWSClusterStaticIdentity`: `AWSCluster`
+- `AWSClusterRoleIdentity`: `AWSCluster`
+- `AzureClusterIdentity`: `AzureCluster`
+- `VSphereClusterIdentity`: `VSphereCluster`
diff --git a/website/versioned_docs/version-0.29.0/cluster-management/assets/bootstrap/capi-gitops-cluster-bootstrap-config.yaml b/website/versioned_docs/version-0.29.0/cluster-management/assets/bootstrap/capi-gitops-cluster-bootstrap-config.yaml
new file mode 100644
index 0000000000..360caaefb4
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/cluster-management/assets/bootstrap/capi-gitops-cluster-bootstrap-config.yaml
@@ -0,0 +1,37 @@
+apiVersion: capi.weave.works/v1alpha1
+kind: ClusterBootstrapConfig
+metadata:
+ name: capi-gitops
+ namespace: default
+spec:
+ clusterSelector:
+ matchLabels:
+ weave.works/capi: bootstrap
+ jobTemplate:
+ generateName: "run-gitops-{{ .ObjectMeta.Name }}"
+ spec:
+ containers:
+ - image: ghcr.io/fluxcd/flux-cli:v0.41.0
+ name: flux-bootstrap
+ resources: {}
+ volumeMounts:
+ - name: kubeconfig
+ mountPath: "/etc/gitops"
+ readOnly: true
+ args:
+ [
+ "bootstrap",
+ "github",
+ "--kubeconfig=/etc/gitops/value",
+ "--owner=$GITHUB_USER",
+ "--repository=fleet-infra",
+ "--path=./clusters/{{ .ObjectMeta.Namespace }}/{{ .ObjectMeta.Name }}",
+ ]
+ envFrom:
+ - secretRef:
+ name: my-pat
+ restartPolicy: Never
+ volumes:
+ - name: kubeconfig
+ secret:
+ secretName: "{{ .ObjectMeta.Name }}-kubeconfig"
diff --git a/website/versioned_docs/version-0.29.0/cluster-management/assets/profiles/profile-repo.yaml b/website/versioned_docs/version-0.29.0/cluster-management/assets/profiles/profile-repo.yaml
new file mode 100644
index 0000000000..9e427fdb87
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/cluster-management/assets/profiles/profile-repo.yaml
@@ -0,0 +1,9 @@
+apiVersion: source.toolkit.fluxcd.io/v1beta2
+kind: HelmRepository
+metadata:
+ name: weaveworks-charts
+ namespace: flux-system
+spec:
+ interval: 1m
+ url: https://weaveworks.github.io/weave-gitops-profile-examples/
+status: {}
diff --git a/website/versioned_docs/version-0.29.0/cluster-management/assets/rbac/wego-admin.yaml b/website/versioned_docs/version-0.29.0/cluster-management/assets/rbac/wego-admin.yaml
new file mode 100644
index 0000000000..54fdc43f79
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/cluster-management/assets/rbac/wego-admin.yaml
@@ -0,0 +1,40 @@
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+ name: wego-admin-cluster-role-binding
+subjects:
+ - kind: User
+ name: wego-admin
+ apiGroup: rbac.authorization.k8s.io
+roleRef:
+ kind: ClusterRole
+ name: wego-admin-cluster-role
+ apiGroup: rbac.authorization.k8s.io
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+ name: wego-admin-cluster-role
+rules:
+ - apiGroups: [""]
+ resources: ["secrets", "pods"]
+ verbs: ["get", "list"]
+ - apiGroups: ["apps"]
+ resources: ["deployments", "replicasets"]
+ verbs: ["get", "list"]
+ - apiGroups: ["kustomize.toolkit.fluxcd.io"]
+ resources: ["kustomizations"]
+ verbs: ["get", "list", "patch"]
+ - apiGroups: ["helm.toolkit.fluxcd.io"]
+ resources: ["helmreleases"]
+ verbs: ["get", "list", "patch"]
+ - apiGroups: ["source.toolkit.fluxcd.io"]
+ resources: [ "buckets", "helmcharts", "gitrepositories", "helmrepositories", "ocirepositories" ]
+ verbs: ["get", "list", "patch"]
+ - apiGroups: [""]
+ resources: ["events"]
+ verbs: ["get", "watch", "list"]
+ - apiGroups: ["pac.weave.works"]
+ resources: ["policies"]
+ verbs: ["get", "list"]
diff --git a/website/versioned_docs/version-0.29.0/cluster-management/assets/templates/capa-template.yaml b/website/versioned_docs/version-0.29.0/cluster-management/assets/templates/capa-template.yaml
new file mode 100644
index 0000000000..e727e654e5
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/cluster-management/assets/templates/capa-template.yaml
@@ -0,0 +1,92 @@
+apiVersion: templates.weave.works/v1alpha2
+kind: GitOpsTemplate
+metadata:
+ name: aws-eks-dev
+ namespace: default
+ annotations:
+ templates.weave.works/inject-prune-annotation: "true"
+ templates.weave.works/add-common-bases: "true"
+ labels:
+ weave.works/template-type: cluster
+spec:
+ description: AWS EKS Development Cluster
+ params:
+ - name: CLUSTER_NAME
+ description: The name for this cluster.
+ - name: AWS_REGION
+ description: AWS Region to create cluster
+ options: ["us-east-1", "eu-central-1", "eu-west-2", "us-west-2"]
+ - name: KUBERNETES_VERSION
+ description: EKS Kubernetes version to use
+ options: ["v1.19.8", "v1.20.7", "v1.21.2"]
+ - name: WORKER_MACHINE_COUNT
+ description: Number of worker nodes to create.
+ resourcetemplates:
+ - contents:
+ - apiVersion: gitops.weave.works/v1alpha1
+ kind: GitopsCluster
+ metadata:
+ name: "${CLUSTER_NAME}"
+ namespace: default
+ labels:
+ weave.works/capi: bootstrap
+ spec:
+ capiClusterRef:
+ name: "${CLUSTER_NAME}"
+
+ - apiVersion: cluster.x-k8s.io/v1beta1
+ kind: Cluster
+ metadata:
+ name: ${CLUSTER_NAME}
+ namespace: default
+ labels:
+ weave.works/capi: bootstrap
+ spec:
+ clusterNetwork:
+ pods:
+ cidrBlocks:
+ - 192.168.0.0/16
+ controlPlaneRef:
+ apiVersion: controlplane.cluster.x-k8s.io/v1beta1
+ kind: AWSManagedControlPlane
+ name: ${CLUSTER_NAME}-control-plane
+ infrastructureRef:
+ apiVersion: controlplane.cluster.x-k8s.io/v1beta1
+ kind: AWSManagedControlPlane
+ name: ${CLUSTER_NAME}-control-plane
+
+ - apiVersion: controlplane.cluster.x-k8s.io/v1beta1
+ kind: AWSManagedControlPlane
+ metadata:
+ name: ${CLUSTER_NAME}-control-plane
+ namespace: default
+ spec:
+ region: ${AWS_REGION}
+ sshKeyName: default
+ version: ${KUBERNETES_VERSION}
+ eksClusterName: ${CLUSTER_NAME}
+
+ - apiVersion: cluster.x-k8s.io/v1beta1
+ kind: MachinePool
+ metadata:
+ name: ${CLUSTER_NAME}-pool-0
+ namespace: default
+ spec:
+ clusterName: ${CLUSTER_NAME}
+ replicas: ${WORKER_MACHINE_COUNT}
+ template:
+ spec:
+ bootstrap:
+ dataSecretName: ""
+ clusterName: ${CLUSTER_NAME}
+ infrastructureRef:
+ apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
+ kind: AWSManagedMachinePool
+ name: ${CLUSTER_NAME}-pool-0
+
+ - apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
+ kind: AWSManagedMachinePool
+ metadata:
+ name: ${CLUSTER_NAME}-pool-0
+ namespace: default
+ spec: {}
diff --git a/website/versioned_docs/version-0.29.0/cluster-management/cluster-management-intro.mdx b/website/versioned_docs/version-0.29.0/cluster-management/cluster-management-intro.mdx
new file mode 100644
index 0000000000..9a3b60ac14
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/cluster-management/cluster-management-intro.mdx
@@ -0,0 +1,50 @@
+---
+title: Cluster Management - Introduction
+hide_title: true
+---
+
+import TierLabel from "@site/docs/_components/TierLabel";
+
+# Cluster Management Introduction
+
+In line with the mantra “cattle, not pets,” Weave GitOps Enterprise (WGE) simplifies managing cluster lifecycle at scale—even massive scale. Through pull requests, which make every action recorded and auditable, WGE makes it possible for teams to create, update, and delete clusters across entire fleets. Breaking things is harder, and recovery is easier. WGE further simplifies the cluster lifecycle management process by providing both a user interface (UI) and a command line interface (CLI) to interact with and manage clusters on-prem, across clouds, and in hybrid environments. You can even use our UI to delete clusters—all it takes is the press of a button that spins up a pull request.
+
+WGE fully supports a range of options, including:
+- [Crossplane integration](https://www.weave.works/blog/gitops-goes-beyond-kubernetes-with-weave-gitops-upbound-s-universal-crossplane)
+- Terraform integration, with a [Terraform Controller](https://docs.gitops.weave.works/docs/terraform/overview/) that follows the patterns established by Flux
+- Cluster API
+
+## Helm Charts and Kustomizations Made Easy with Our UI
+
+The Weave GitOps Enterprise UI enables you to install software packages to your bootstrapped cluster via the Applications view of our user interface, using a [Helm chart](https://www.weave.works/blog/helm-charts-in-kubernetes) (via a HelmRelease) or [Kustomization](https://fluxcd.io/flux/components/kustomize/kustomization/). First, find the "Add an Application" button:
+
+![Profiles Selection](./img/add-application-btn.png)
+
+A form will appear, asking you to select the target cluster where you want to add your Application.
+
+![Profiles Selection](./img/add-application-form.png)
+
+Select the source type of either your Git repository or your Helm repository from the selected cluster:
+
+![Profiles Selection](./img/add-application-select-source.png)
+
+If you select Git repository as the source type, you will be able to add the Application from Kustomization:
+
+![Profiles Selection](./img/add-application-kustomization.png)
+
+If you select Helm repository as the source type, you will be able to add Application from HelmRelease.
+
+And if you choose the profiles Helm chart repository URL, you can select a profile from our [Profiles](profiles.mdx) list.
+
+![Profiles Selection](./img/add-application-helm-release.png)
+
+Finally, you can create a pull request to your target cluster and see it on your GitOps repository.
+
+## Follow Our User Guide
+
+Our user guide pages provides two pathways to deployment:
+
+- One path that shows you how to manage clusters [without adding Cluster API](managing-clusters-without-capi.mdx). Join a cluster by hooking WGE to it, then install an application on that cluster.
+- An **optional** path that shows you how to create, provision, and delete your first API cluster with [EKS/CAPA](../cluster-management/deploying-capa-eks.mdx).
+
+Just click the option you want to get started with, and let's go.
diff --git a/website/versioned_docs/version-0.29.0/cluster-management/cluster-management-troubleshooting.mdx b/website/versioned_docs/version-0.29.0/cluster-management/cluster-management-troubleshooting.mdx
new file mode 100644
index 0000000000..eaf4601a70
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/cluster-management/cluster-management-troubleshooting.mdx
@@ -0,0 +1,69 @@
+---
+title: Cluster Management Troubleshooting
+---
+
+import TierLabel from "../_components/TierLabel";
+
+# Cluster Management Troubleshooting
+
+We'll use this page to help you move past common troublesome situations.
+
+## Git Repositories and Resources
+
+To authenticate using Git during the pull request creation, you will need to select the Git repository where you'll create the pull request.
+
+Depending on the action performed on the resource (creation/deletion/editing), the default Git repository selected in the UI is determined in the following order:
+
+1. the repository used to initially create the resource found in the `templates.weave.works/create-request` annotation (in the case of editing or deleting of resources)
+ ```yaml
+ metadata:
+ annotations:
+ templates.weave.works/create-request: "{...\"parameter_values\":{...\"url\":\"https://github.com/weave-example-org/weave-demo\"}"
+ ```
+
+2. the first repository found with a `weave.works/repo-role: default` annotation
+ ```yaml
+ metadata:
+ annotations:
+ weave.works/repo-role: default
+ ```
+
+3. the flux-system repository
+ ```yaml
+ metadata:
+ name: flux-system
+ namespace: flux-system
+ ```
+
+4. the first repository in the list of Git repositories that the user has access to.
+
+In the case of deletion and editing, if the resource repository is found amongst the Git repositories that the user has access to, it will be preselected and the selection will be disabled. If it is not found, you can choose a new repository.
+
+In the case of tenants, we recommend adding the `weave.works/repo-role: default` to an appropriate Git repository.
+
+### Overriding the Calculated Git Repository HTTPS URL
+
+The system will try and automatically calculate the correct HTTPS API endpoint to create a pull request against. For example, if the Git repository URL is `ssh://git@github.com/org/repo.git`, the system will try and convert it to `https://github.com/org/repo.git`.
+
+However, it is not always possible to accurately derive this URL. An override can be specified to set the correct URL instead. For example, the SSH URL may be `ssh://git@interal-ssh-server:2222/org/repo.git` and the correct HTTPS URL may be `https://gitlab.example.com/org/repo.git`.
+
+In this case, we set the override via the `weave.works/repo-https-url` annotation on the `GitRepository` object:
+
+```yaml
+apiVersion: source.toolkit.fluxcd.io/v1beta1
+kind: GitRepository
+metadata:
+ name: repo
+ namespace: flux-system
+ annotations:
+ // highlight-start
+ weave.works/repo-https-url: https://gitlab.example.com/org/repo.git
+ // highlight-end
+spec:
+ interval: 1m
+ url: ssh://git@interal-ssh-server:2222/org/repo.git
+```
+
+The pull request will then be created against the correct HTTPS API.
+
+The above also applies to application creation.
diff --git a/website/versioned_docs/version-0.29.0/cluster-management/deploying-capa-eks.mdx b/website/versioned_docs/version-0.29.0/cluster-management/deploying-capa-eks.mdx
new file mode 100644
index 0000000000..83015e1a25
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/cluster-management/deploying-capa-eks.mdx
@@ -0,0 +1,198 @@
+---
+title: Deploying CAPA with EKS
+hide_title: true
+---
+
+import Tabs from "@theme/Tabs";
+import TabItem from "@theme/TabItem";
+
+import TierLabel from "@site/docs/_components/TierLabel";
+import CodeBlock from "@theme/CodeBlock";
+import BrowserOnly from "@docusaurus/BrowserOnly";
+
+
+ {frontMatter.title}
+
+
+Weave GitOps Enterprise can leverage [Cluster API](https://cluster-api.sigs.k8s.io/introduction.html) providers to enable leaf cluster creation. Cluster API provides declarative APIs, controllers, and tooling to manage the lifecycle of Kubernetes clusters across a large number of [infrastructure providers](https://cluster-api.sigs.k8s.io/reference/providers.html#infrastructure). Cluster API custom resource definitions (CRDs) are platform-independent as each provider implementation handles the creation of virtual machines, VPCs, networks, and other required infrastructure parts—enabling consistent and repeatable cluster deployments.
+
+As an AWS advanced technology partner, Weaveworks has been working tirelessly to ensure that deploying EKS **anywhere** is smooth and removes the barriers to application modernization.
+
+## Prerequisites
+
+You'll need to install the following software before continuing with these instructions:
+
+- `github cli` >= 2.3.0 [(source)](https://cli.github.com/)
+- `kubectl` [(source)](https://kubernetes.io/docs/tasks/tools/#kubectl)
+- `eksctl` [(source)](https://github.com/weaveworks/eksctl/releases)
+- the AWS Command Line Interface/`aws cli` [(source)](https://aws.amazon.com/cli/)
+- `clusterctl` >= v1.1.3 [(source)](https://github.com/kubernetes-sigs/cluster-api/releases); follow [these steps](https://cluster-api-aws.sigs.k8s.io/getting-started.html#install-clusterctl) to initialise the cluster and enable feature gates
+- `clusterawsadm` >= v1.1.0, following [Cluster API's instructions](https://github.com/kubernetes-sigs/cluster-api-provider-aws/releases)
+- Make sure you have a management cluster. If you followed the Weave GitOps Enterprise [installation guide](../enterprise/getting-started/install-enterprise.mdx), you'll have done this already.
+- Configure your `AWS_ACCESS_KEY_ID`and `AWS_SECRET_ACCESS_KEY` with either `aws configure` or by exporting it in the current shell.
+- Set the `GITHUB_TOKEN` as an environment variable in the current shell. It should have permissions to create Pull Requests against the cluster config repo.
+
+## Multitenancy
+
+Some Cluster API providers allow you to choose the account or identity that the new cluster will be created with. This is often referred to as _Multi-tenancy_ in the CAPI world. Weave GitOps currently supports:
+
+- [**AWS** multi-tenancy](https://cluster-api-aws.sigs.k8s.io/topics/multitenancy.html)
+- [**Azure** multi-tenancy](https://capz.sigs.k8s.io/topics/multitenancy.html)
+- [**vSphere** multi-tenancy](https://github.com/kubernetes-sigs/cluster-api-provider-vsphere/blob/master/docs/identity_management.md)
+
+## 1. Add Common RBAC to Your Repository
+
+When a cluster is provisioned, by default it will reconcile all the manifests in `./clusters//` and `./clusters/bases`.
+
+To display Applications and Sources in the UI we need to give the logged in user permissions to inspect the new cluster.
+
+Adding common RBAC rules to `./clusters/bases/rbac` is an easy way to configure this!
+
+import WegoAdmin from "!!raw-loader!./assets/rbac/wego-admin.yaml";
+
+
+ {() => (
+
+ curl -o clusters/bases/rbac/wego-admin.yaml {window.location.protocol}//
+ {window.location.host}
+ {require("./assets/rbac/wego-admin.yaml").default}
+
+ )}
+
+
+Expand to see full template yaml
+
+
+ {WegoAdmin}
+
+
+
+
+## 2. Build a Kubernetes Platform with Built-in Components Preconfigured for Your Organization
+
+To do this, go to Weaveworks' [Profiles Catalog](https://github.com/weaveworks/profiles-catalog).
+
+See [CAPI Templates](gitops-templates/intro.mdx) page for more details on this topic. Once we load a template we can use it in the UI to create clusters!
+
+import CapaTemplate from "!!raw-loader!./assets/templates/capa-template.yaml";
+
+Download the template below to your config repository path, then commit and push to your Git origin.
+
+
+ {() => (
+
+ curl -o clusters/management/capi/templates/capa-template.yaml{" "}
+ {window.location.protocol}//{window.location.host}
+ {require("./assets/templates/capa-template.yaml").default}
+
+ )}
+
+
+
+ {CapaTemplate}
+
+
+## 3. Add a Cluster Bootstrap Config
+
+This step ensures that Flux gets installed into your cluster. Create a cluster bootstrap config as follows:
+
+```bash
+ kubectl create secret generic my-pat --from-literal GITHUB_TOKEN=$GITHUB_TOKEN
+```
+
+import CapiGitopsCDC from "!!raw-loader!./assets/bootstrap/capi-gitops-cluster-bootstrap-config.yaml";
+
+Download the config with:
+
+
+ {() => (
+
+ curl -o
+ clusters/management/capi/bootstrap/capi-gitops-cluster-bootstrap-config.yaml{" "}
+ {window.location.protocol}
+ //{window.location.host}
+ {
+ require("./assets/bootstrap/capi-gitops-cluster-bootstrap-config.yaml")
+ .default
+ }
+
+ )}
+
+
+Then update the `GITOPS_REPO` variable to point to your cluster
+
+Expand to see full yaml
+
+
+ {CapiGitopsCDC}
+
+
+
+
+## 4. Delete a Cluster with the Weave GitOps Enterprise UI
+
+Here are the steps:
+- Select the clusters you want to delete
+- Press the `Create a PR to delete clusters` button
+- Either update the deletion PR values or leave the default values, depending on your situation
+- Press the `Remove clusters` button
+- Merge the PR for clusters deletion
+
+Note that you can't apply an _empty_ repository to a cluster. If you have Cluster API clusters and other manifests committed to this repository, and then _delete all of them_ so there are zero manifests left, then the apply will fail and the resources will not be removed from the cluster.
+A workaround is to add a dummy _ConfigMap_ back to the Git repository after deleting everything else so that there is at least one manifest to apply.
+
+## 5. Disable CAPI Support
+
+If you do not need CAPI-based cluster management support, you can disable CAPI
+via the Helm Chart values.
+
+Update your Weave GitOps Enterprise `HelmRelease` object with the
+`global.capiEnabled` value set to `false`:
+
+```yaml {33-35} title='clusters/management/weave-gitops-enterprise.yaml'
+---
+apiVersion: source.toolkit.fluxcd.io/v1beta2
+kind: HelmRepository
+metadata:
+ name: weave-gitops-enterprise-charts
+ namespace: flux-system
+spec:
+ interval: 60m
+ secretRef:
+ name: weave-gitops-enterprise-credentials
+ url: https://charts.dev.wkp.weave.works/releases/charts-v3
+---
+apiVersion: helm.toolkit.fluxcd.io/v2beta1
+kind: HelmRelease
+metadata:
+ name: weave-gitops-enterprise
+ namespace: flux-system
+spec:
+ chart:
+ spec:
+ interval: 65m
+ chart: mccp
+ sourceRef:
+ kind: HelmRepository
+ name: weave-gitops-enterprise-charts
+ namespace: flux-system
+ version: 0.12.0
+ install:
+ crds: CreateReplace
+ upgrade:
+ crds: CreateReplace
+ interval: 50m
+ values:
+ global:
+ capiEnabled: false
+```
+And that's it!
diff --git a/website/versioned_docs/version-0.29.0/cluster-management/img/add-application-btn.png b/website/versioned_docs/version-0.29.0/cluster-management/img/add-application-btn.png
new file mode 100644
index 0000000000..e4efad3c97
Binary files /dev/null and b/website/versioned_docs/version-0.29.0/cluster-management/img/add-application-btn.png differ
diff --git a/website/versioned_docs/version-0.29.0/cluster-management/img/add-application-form.png b/website/versioned_docs/version-0.29.0/cluster-management/img/add-application-form.png
new file mode 100644
index 0000000000..35abd63d05
Binary files /dev/null and b/website/versioned_docs/version-0.29.0/cluster-management/img/add-application-form.png differ
diff --git a/website/versioned_docs/version-0.29.0/cluster-management/img/add-application-helm-release.png b/website/versioned_docs/version-0.29.0/cluster-management/img/add-application-helm-release.png
new file mode 100644
index 0000000000..3405d63876
Binary files /dev/null and b/website/versioned_docs/version-0.29.0/cluster-management/img/add-application-helm-release.png differ
diff --git a/website/versioned_docs/version-0.29.0/cluster-management/img/add-application-kustomization.png b/website/versioned_docs/version-0.29.0/cluster-management/img/add-application-kustomization.png
new file mode 100644
index 0000000000..fdd1fab580
Binary files /dev/null and b/website/versioned_docs/version-0.29.0/cluster-management/img/add-application-kustomization.png differ
diff --git a/website/versioned_docs/version-0.29.0/cluster-management/img/add-application-select-source.png b/website/versioned_docs/version-0.29.0/cluster-management/img/add-application-select-source.png
new file mode 100644
index 0000000000..ce3998e4bc
Binary files /dev/null and b/website/versioned_docs/version-0.29.0/cluster-management/img/add-application-select-source.png differ
diff --git a/website/versioned_docs/version-0.29.0/cluster-management/img/disconnect-cluster.png b/website/versioned_docs/version-0.29.0/cluster-management/img/disconnect-cluster.png
new file mode 100644
index 0000000000..5a08b5afbc
Binary files /dev/null and b/website/versioned_docs/version-0.29.0/cluster-management/img/disconnect-cluster.png differ
diff --git a/website/versioned_docs/version-0.29.0/cluster-management/img/identity-selection.png b/website/versioned_docs/version-0.29.0/cluster-management/img/identity-selection.png
new file mode 100644
index 0000000000..c1ca94f155
Binary files /dev/null and b/website/versioned_docs/version-0.29.0/cluster-management/img/identity-selection.png differ
diff --git a/website/versioned_docs/version-0.29.0/cluster-management/img/profile-selection.png b/website/versioned_docs/version-0.29.0/cluster-management/img/profile-selection.png
new file mode 100644
index 0000000000..4f0243b070
Binary files /dev/null and b/website/versioned_docs/version-0.29.0/cluster-management/img/profile-selection.png differ
diff --git a/website/versioned_docs/version-0.29.0/cluster-management/managing-clusters-without-capi.mdx b/website/versioned_docs/version-0.29.0/cluster-management/managing-clusters-without-capi.mdx
new file mode 100644
index 0000000000..2b872fbf46
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/cluster-management/managing-clusters-without-capi.mdx
@@ -0,0 +1,348 @@
+---
+title: Managing Clusters Without Cluster API
+hide_title: true
+---
+
+import Tabs from "@theme/Tabs";
+import TabItem from "@theme/TabItem";
+
+import TierLabel from "../_components/TierLabel";
+import CodeBlock from "@theme/CodeBlock";
+import BrowserOnly from "@docusaurus/BrowserOnly";
+
+# Managing Clusters Without Cluster API
+
+You do **not** need Cluster API to add your Kubernetes cluster to Weave Gitops Enterprise. The only thing you need is a secret containing a valid `kubeconfig`.
+
+import TOCInline from "@theme/TOCInline";
+;
+
+
+
+
+## Adding kubeconfig to Your Management Cluster
+
+If you already have a `kubeconfig` stored in a secret in your management cluster, continue with the "Create a `GitopsCluster`" step below.
+
+If you have a kubeconfig, but it is not yet stored in your management cluster, load it into the cluster using this command:
+
+```
+kubectl create secret generic demo-01-kubeconfig \
+--from-file=value=./demo-01-kubeconfig
+```
+
+
+
+
+Here's how to create a kubeconfig secret.
+
+1. Create a new service account on the remote cluster:
+
+ ```yaml
+ apiVersion: v1
+ kind: ServiceAccount
+ metadata:
+ name: demo-01
+ namespace: default
+ ```
+
+2. Add RBAC permissions for the service account:
+
+ Expand to see role manifests
+
+ ```yaml
+ ---
+ apiVersion: rbac.authorization.k8s.io/v1
+ kind: ClusterRoleBinding
+ metadata:
+ name: impersonate-user-groups
+ subjects:
+ - kind: ServiceAccount
+ name: demo-01
+ namespace: default
+ roleRef:
+ kind: ClusterRole
+ name: user-groups-impersonator
+ apiGroup: rbac.authorization.k8s.io
+ ---
+ apiVersion: rbac.authorization.k8s.io/v1
+ kind: ClusterRole
+ metadata:
+ name: user-groups-impersonator
+ rules:
+ - apiGroups: [""]
+ resources: ["users", "groups"]
+ verbs: ["impersonate"]
+ - apiGroups: [""]
+ resources: ["namespaces"]
+ verbs: ["get", "list"]
+ ```
+
+
+
+ This will allow WGE to introspect the cluster for available namespaces.
+
+ Once we know what namespaces are available we can test whether the logged in user can access them via impersonation.
+
+3. Retrieve the token from the service account. First, run this command to get the list of secrets of the service accounts:
+
+ ```bash
+ kubectl get secrets --field-selector type=kubernetes.io/service-account-token
+ NAME TYPE DATA AGE
+ default-token-lsjz4 kubernetes.io/service-account-token 3 13d
+ demo-01-token-gqz7p kubernetes.io/service-account-token 3 99m
+ ```
+
+ (`demo-01-token-gqz7p` is the secret that holds the token for `demo-01` service account.)
+
+ Then, run the following command to get the service account token:
+
+ ```bash
+ TOKEN=$(kubectl get secret demo-01-token-gqz7p -o jsonpath={.data.token} | base64 -d)
+ ```
+
+4. Create a kubeconfig secret. We'll use a helper script to generate the kubeconfig, and then save it into `static-kubeconfig.sh`:
+
+ Expand to see script
+
+ ```bash title="static-kubeconfig.sh"
+ #!/bin/bash
+
+ if [[ -z "$CLUSTER_NAME" ]]; then
+ echo "Ensure CLUSTER_NAME has been set"
+ exit 1
+ fi
+
+ if [[ -z "$CA_CERTIFICATE" ]]; then
+ echo "Ensure CA_CERTIFICATE has been set to the path of the CA certificate"
+ exit 1
+ fi
+
+ if [[ -z "$ENDPOINT" ]]; then
+ echo "Ensure ENDPOINT has been set"
+ exit 1
+ fi
+
+ if [[ -z "$TOKEN" ]]; then
+ echo "Ensure TOKEN has been set"
+ exit 1
+ fi
+
+ export CLUSTER_CA_CERTIFICATE=$(cat "$CA_CERTIFICATE" | base64)
+
+ envsubst <
+
+5. Obtain the cluster certificate (CA). How you do this depends on your cluster. If you're using GKE, for example, you can view the CA on the GCP Console: Cluster->Details->Endpoint->”Show cluster certificate”. You'll need to copy the contents of the certificate into the `ca.crt` file used below.
+
+ ```bash
+ CLUSTER_NAME=demo-01 \
+ CA_CERTIFICATE=ca.crt \
+ ENDPOINT= \
+ TOKEN= ./static-kubeconfig.sh > demo-01-kubeconfig
+ ```
+
+6. Update the following fields:
+
+ - CLUSTER_NAME: insert the name of your cluster—i.e., `demo-01`
+ - ENDPOINT: add the API server endpoint i.e. `34.218.72.31`
+ - CA_CERTIFICATE: include the path to the CA certificate file of the cluster
+ - TOKEN: add the token of the service account retrieved in the previous step
+
+7. Finally, create a secret for the generated kubeconfig:
+
+ ```bash
+ kubectl create secret generic demo-01-kubeconfig \
+ --from-file=value=./demo-01-kubeconfig
+ ```
+
+
+
+
+## Add a Cluster Bootstrap Config
+
+This step ensures that Flux gets installed into your cluster. Create a cluster bootstrap config as follows:
+
+```bash
+ kubectl create secret generic my-pat --from-literal GITHUB_TOKEN=$GITHUB_TOKEN
+```
+
+import CapiGitopsCDC from "!!raw-loader!./assets/bootstrap/capi-gitops-cluster-bootstrap-config.yaml";
+
+Download the config with:
+
+
+ {() => (
+
+ curl -o
+ clusters/management/capi/bootstrap/capi-gitops-cluster-bootstrap-config.yaml{" "}
+ {window.location.protocol}
+ //{window.location.host}
+ {
+ require("./assets/bootstrap/capi-gitops-cluster-bootstrap-config.yaml")
+ .default
+ }
+
+ )}
+
+
+Then update the `GITHUB_USER` variable to point to your repository
+
+Expand to see full yaml
+
+
+ {CapiGitopsCDC}
+
+
+
+
+## Connect a Cluster
+
+To connect your cluster, you need to add some common RBAC rules into the `clusters/bases` folder. When a cluster is provisioned, by default it will reconcile all the manifests in `./clusters//` and `./clusters/bases`.
+
+To display Applications and Sources in the UI we need to give the logged in user permissions to inspect the new cluster.
+
+Adding common RBAC rules to `./clusters/bases/rbac` is an easy way to configure this!
+
+import WegoAdmin from "!!raw-loader!./assets/rbac/wego-admin.yaml";
+
+
+ {() => (
+
+ curl -o clusters/bases/rbac/wego-admin.yaml {window.location.protocol}//
+ {window.location.host}
+ {require("./assets/rbac/wego-admin.yaml").default}
+
+ )}
+
+
+Expand to see full template yaml
+
+
+ {WegoAdmin}
+
+
+
+
+## Create a `GitopsCluster`
+
+When a `GitopsCluster` appears in the cluster, the Cluster Bootstrap Controller will install Flux on it and by default start reconciling the `./clusters/demo-01` path in your management cluster's Git repository:
+
+```yaml title="./clusters/management/clusters/demo-01.yaml"
+apiVersion: gitops.weave.works/v1alpha1
+kind: GitopsCluster
+metadata:
+ name: demo-01
+ namespace: default
+ # Signals that this cluster should be bootstrapped.
+ labels:
+ weave.works/capi: bootstrap
+spec:
+ secretRef:
+ name: demo-01-kubeconfig
+```
+
+To use the Weave GitOps Enterprise user interface (UI) to inspect the Applications and Sources running on the new cluster, you'll need permissions. We took care of this above when we stored your RBAC rules in `./clusters/bases`. In the following step, we'll create a kustomization to add these common resources onto our new cluster:
+
+```yaml title="./clusters/demo-01/clusters-bases-kustomization.yaml"
+apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
+kind: Kustomization
+metadata:
+ creationTimestamp: null
+ name: clusters-bases-kustomization
+ namespace: flux-system
+spec:
+ interval: 10m0s
+ path: clusters/bases
+ prune: true
+ sourceRef:
+ kind: GitRepository
+ name: flux-system
+```
+
+Save these two files in your Git repository, then commit and push.
+
+Once Flux has reconciled the cluster, you can inspect your Flux resources via the UI!
+
+## Debugging Tip: Checking that Your kubeconfig Secret Is in Your Cluster
+
+To test that your kubeconfig secret is correctly set up, apply the following manifest and check the logs after the job completes:
+
+Expand to see manifest
+
+```yaml
+---
+apiVersion: batch/v1
+kind: Job
+metadata:
+ name: kubectl
+spec:
+ ttlSecondsAfterFinished: 30
+ template:
+ spec:
+ containers:
+ - name: kubectl
+ image: bitnami/kubectl
+ args:
+ [
+ "get",
+ "pods",
+ "-n",
+ "kube-system",
+ "--kubeconfig",
+ "/etc/kubeconfig/value",
+ ]
+ volumeMounts:
+ - name: kubeconfig
+ mountPath: "/etc/kubeconfig"
+ readOnly: true
+ restartPolicy: Never
+ volumes:
+ - name: kubeconfig
+ secret:
+ secretName: demo-01-kubeconfig
+ optional: false
+```
+
+
+
+In the manifest above, `demo-01-kubeconfig` is the name of the secret that contains the kubeconfig for the remote cluster.
+
+---
+
+## Additional Resources
+
+Other documentation that you might find useful:
+
+- [Authentication strategies](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#authentication-strategies)
+ - [X509 client certificates](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#x509-client-certs): can be used across different namespaces
+ - [Service account tokens](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens): limited to a single namespace
+- [Kubernetes authentication 101 (CNCF blog post)](https://www.cncf.io/blog/2020/07/31/kubernetes-rbac-101-authentication/)
+- [Kubernetes authentication (Magalix blog post)](https://www.magalix.com/blog/kubernetes-authentication)
diff --git a/website/versioned_docs/version-0.29.0/cluster-management/profiles.mdx b/website/versioned_docs/version-0.29.0/cluster-management/profiles.mdx
new file mode 100644
index 0000000000..4355d8d5c0
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/cluster-management/profiles.mdx
@@ -0,0 +1,155 @@
+---
+title: Profiles
+hide_title: true
+---
+
+import TierLabel from "../_components/TierLabel";
+
+# Profiles
+
+:::note BEFORE YOU START
+The following instructions require you to make minor changes to the content of your own hosted Helm repository.
+:::
+
+To put it simply, Profiles are [Helm charts](https://helm.sh/docs/topics/charts/). To create a Profile, you need to add an [annotation](https://helm.sh/docs/topics/charts/#the-chartyaml-file) to a Helm chart.
+
+A very simple Helm chart marked up as a Profile looks like this:
+```yaml
+name: demo-profile
+version: 0.0.1
+annotations:
+ weave.works/profile: "A Demo Profile"
+```
+The chart can use either [subcharts](https://helm.sh/docs/chart_template_guide/subcharts_and_globals/) or [dependencies](https://helm.sh/docs/chart_best_practices/dependencies/#helm) to include other charts. These other charts do not need the annotation, and they will not show up as Profiles.
+
+## Mark a HelmRepository as Containing Profiles
+
+Alternatively, you can annotate a Flux `HelmRepository`
+```yaml
+apiVersion: source.toolkit.fluxcd.io/v1beta2
+kind: HelmRepository
+metadata:
+ name: podinfo
+ namespace: default
+ annotations:
+ weave.works/profiles: "true" # this identifies all charts as profiles
+spec:
+ interval: 5m0s
+ url: https://stefanprodan.github.io/podinfo
+```
+
+This will ensure that all charts in the `HelmRepository` are identified as Profiles.
+
+## Add Layers to Define Dependencies Between Your Profiles
+
+Profile layers are a mechanism for loosely defining dependencies between Profiles.
+
+To add a layer to a Profile chart:
+```yaml
+name: demo-profile
+version: 0.0.1
+annotations:
+ weave.works/profile: "A Demo Profile"
+ weave.works/layer: "demo"
+```
+
+When multiple Profiles are specified in an API call, with layers in the API request then the set of layers is sorted, reversed, and configured as dependencies using Flux's [dependsOn](https://fluxcd.io/docs/components/helm/helmreleases/#helmrelease-dependencies) mechanism.
+```
+┌─────────┐ ┌─────────┐ ┌─────────┐
+│ │ │ │ │ │
+│ layer-3 ├──────► layer-2 ├──────► layer-1 │
+│ │ │ │ │ │
+└─────────┘ └─────────┘ └─────────┘
+ dependsOn dependsOn
+```
+
+The scope of the `dependsOn` calculation is limited to the set of Profiles in the API call.
+
+If only one chart is being installed, obviously no `dependsOn` is configured.
+
+If several charts are installed in the same layer, then the preceeding layer charts will be configured to depend on _all_ the charts in the succeeding layer.
+```
+┌──────────┐ ┌─────────┐ ┌─────────┐
+│ │ │ │ │ │
+│ layer-3 ├─────► layer-2 ├──────► layer-1 │
+│ │ │ │ │ │
+└──────────┤ └─────────┘ └─▲───────┘
+ dependsOn │ dependsOn │
+ │ │
+ │ ┌─────────┐ │
+ │ │ │ │
+ └─────► layer-2 ├────────┘
+ │ │
+ └─────────┘
+ dependsOn
+```
+If a chart with no layer specified is installed with a chart that has a layer specified, the service will configure the `dependsOn` for the chart without a layer to depend on the chart with layer.
+
+## (Optional) Use a Helm Chart from a Remote Public/Private Repository
+
+You can add your Profiles to a remote repository that can be referenced using a HelmRepository resource. The repository can be either public or private. Using a private repo requires a few extra steps.
+
+In this example, a public repo and branch is referenced directly where the Helm releases are:
+```yaml title="HelmRepository.yaml"
+apiVersion: source.toolkit.fluxcd.io/v1beta1
+kind: HelmRepository
+metadata:
+ name: weaveworks-charts
+ namespace: flux-system
+spec:
+ interval: 1m
+ url: https://weaveworks.github.io/weave-gitops-profile-examples/
+```
+
+To use private repositories with restricted access, you can use a [secret synced](../secrets/bootstrapping-secrets.mdx) to the target leaf cluster. SecretSync references the secret as `spec.secretRef`. The labels of your target leaf cluster are added for the syncer to match clusters against those labels using `spec.clusterSelector.matchLabels`.
+```yaml title="SecretSync.yaml"
+apiVersion: capi.weave.works/v1alpha1
+kind: SecretSync
+metadata:
+ name: my-dev-secret-syncer
+ namespace: flux-system
+spec:
+ clusterSelector:
+ matchLabels:
+ weave.works/capi: bootstrap
+ secretRef:
+ name: weave-gitops-enterprise-credentials
+ targetNamespace: flux-system
+```
+
+Once the SecretSync and Secret are available, the secret can be directly referenced in the HelmRepository object:
+```yaml title="PrivateHelmRepository.yaml"
+apiVersion: source.toolkit.fluxcd.io/v1beta2
+kind: HelmRepository
+metadata:
+ name: weaveworks-charts
+ namespace: flux-system
+spec:
+ interval: 60m
+ secretRef:
+ name: weave-gitops-enterprise-credentials
+ url: https://charts.dev.wkp.weave.works/releases/charts-v3
+ ```
+**Note**: The `HelmRepoSecret`, `SecretSync`, and the `GitopsCluster` should all be in the same namespace.
+
+### Select the Profiles You Want Installed at Cluster Creation
+
+WGE inspects the namespace in the management cluster where it is deployed, and looks for a `HelmRepository` object named `weaveworks-charts`. This Kubernetes object should point to a Helm chart repository that includes the Profiles available for installation.
+
+When creating a cluster from the UI using a CAPI template, these Profiles are available for selection in the `Profiles` section of the template. For example:
+
+![Profiles Selection](./img/profile-selection.png)
+
+As shown above, some Profiles are optional, while others are required. This is determined when the template is authored and allows for operations teams to control which Helm packages should be installed on new clusters by default.
+
+To enable editing of the yaml values for required Profiles, add the `editable` flag in the annotation and describe the required Profile in the template. For example:
+
+```
+apiVersion: templates.weave.works/v1alpha2
+kind: GitOpsTemplate
+metadata:
+ name: connect-a-cluster-with-policies
+ namespace: default
+ annotations:
+ capi.weave.works/profile-0: '{"name": "weave-policy-agent", "editable": true, "version": "0.2.8", "values": "accountId: weaveworks\nclusterId: ${CLUSTER_NAME}" }'
+```
diff --git a/website/versioned_docs/version-0.29.0/configuration/emergency-user.mdx b/website/versioned_docs/version-0.29.0/configuration/emergency-user.mdx
new file mode 100644
index 0000000000..c5b1548aa2
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/configuration/emergency-user.mdx
@@ -0,0 +1,106 @@
+---
+title: Emergency Cluster User Account
+---
+
+:::danger Important
+This is an **insecure** method of securing your dashboard which we only recommend for local
+and development environments, or if you need to activate emergency access to a damaged cluster.
+
+Note also that this mechanism only exists for a single user: you will not be able to
+create multiple users. Weave GitOps does not provide its own authentication mechanism,
+for secure and fully-featured authentication we **strongly recommend** using an OIDC provider as described [here](../oidc-access).
+:::
+
+## Configuring the emergency user
+
+Before you login via the emergency user account, you need to generate a bcrypt hash for your chosen password and store it as a secret in Kubernetes.
+There are several different ways to generate a bcrypt hash, this guide uses `gitops get bcrypt-hash` from our CLI.
+
+Generate the password by running:
+
+```sh
+PASSWORD=""
+echo -n $PASSWORD | gitops get bcrypt-hash
+$2a$10$OS5NJmPNEb13UgTOSKnMxOWlmS7mlxX77hv4yAiISvZ71Dc7IuN3q
+```
+
+Now create a Kubernetes secret to store your chosen username and the password hash:
+
+```sh
+kubectl create secret generic cluster-user-auth \
+ --namespace flux-system \
+ --from-literal=username=admin \
+ --from-literal=password='$2a$10$OS5NJmPNEb13UTOSKngMxOWlmS7mlxX77hv4yAiISvZ71Dc7IuN3q'
+```
+
+You should now be able to login via the cluster user account using your chosen username and password.
+
+## Updating the emergency user
+
+To change either the username or the password, recreate the `cluster-user-auth`
+with the new details.
+
+Note that only one emergency user can be created this way. To add more users,
+enable an [OIDC provider](../oidc-access).
+
+## User permissions
+
+By default both a ClusterRole and Role are generated for the emergency user.
+Both have the same permissions with former being optional and the latter being
+bound to the `flux-system` namespace (where Flux stores its resources by default).
+The default set of rules are configured like this:
+
+```yaml
+rules:
+ # Flux Resources
+ - apiGroups: ["source.toolkit.fluxcd.io"]
+ resources: [ "buckets", "helmcharts", "gitrepositories", "helmrepositories", "ocirepositories" ]
+ verbs: [ "get", "list", "watch", "patch" ]
+
+ - apiGroups: ["kustomize.toolkit.fluxcd.io"]
+ resources: [ "kustomizations" ]
+ verbs: [ "get", "list", "watch", "patch" ]
+
+ - apiGroups: ["helm.toolkit.fluxcd.io"]
+ resources: [ "helmreleases" ]
+ verbs: [ "get", "list", "watch", "patch" ]
+
+ - apiGroups: [ "notification.toolkit.fluxcd.io" ]
+ resources: [ "providers", "alerts" ]
+ verbs: [ "get", "list", "watch", "patch" ]
+
+ - apiGroups: ["infra.contrib.fluxcd.io"]
+ resources: ["terraforms"]
+ verbs: [ "get", "list", "watch", "patch" ]
+
+ # Read access for all other Kubernetes objects
+ - apiGroups: ["*"]
+ resources: ["*"]
+ verbs: [ "get", "list", "watch" ]
+```
+
+These permissions give the emergency user Administrator level powers. **We do not
+advise leaving it active on production systems**.
+
+If required, the permissions can be expanded with the `rbac.additionalRules` field in the
+[Helm Chart](../references/helm-reference.md).
+Follow the instructions in the next section in order to configure RBAC correctly.
+
+:::tip
+To remove the emergency user as a login method, set the following values in the
+[Helm Chart](../references/helm-reference.md):
+
+```yaml
+#
+adminUser:
+ create: false
+#
+additionalArgs:
+- --auth-methods=oidc
+#
+```
+
+If you are disabling an already existing emergency user, you will need to
+manually delete the Kubernetes Secret and any User Roles which were created on
+the cluster.
+:::
diff --git a/website/versioned_docs/version-0.29.0/configuration/oidc-access.mdx b/website/versioned_docs/version-0.29.0/configuration/oidc-access.mdx
new file mode 100644
index 0000000000..c877770616
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/configuration/oidc-access.mdx
@@ -0,0 +1,108 @@
+---
+title: OIDC Provider
+---
+
+# Login via an OIDC provider
+
+You may decide to give your engineering teams access to the dashboard, in order to view and manage their workloads. In this case, you will want to secure access to the dashboard and restrict who can interact with it. Weave GitOps integrates with your OIDC provider and uses standard Kubernetes RBAC to give you fine-grained control of the permissions for the dashboard users.
+
+## Background
+
+OIDC extends the OAuth2 authorization protocol by including an additional field (ID Token) that contains information (claims) about a user's identity. After a user successfully authenticates with the OIDC provider, this information is used by Weave GitOps to impersonate the user in any calls to the Kubernetes API. This allows cluster administrators to use RBAC rules to control access to the cluster and also the dashboard.
+
+## Configuration
+
+In order to login via your OIDC provider, you need to create a Kubernetes secret to store the OIDC configuration. This configuration consists of the following parameters:
+
+| Parameter | Description | Default |
+| ------------------| -------------------------------------------------------------------------------------------------------------------------------- | --------- |
+| `issuerURL` | The URL of the issuer, typically the discovery URL without a path | |
+| `clientID` | The client ID that has been setup for Weave GitOps in the issuer | |
+| `clientSecret` | The client secret that has been setup for Weave GitOps in the issuer | |
+| `redirectURL` | The redirect URL that has been setup for Weave GitOps in the issuer, typically the dashboard URL followed by `/oauth2/callback ` | |
+| `tokenDuration` | The time duration that the ID Token will remain valid, after successful authentication | "1h0m0s" |
+
+Ensure that your OIDC provider has been setup with a client ID/secret and the redirect URL of the dashboard.
+
+Create a secret named `oidc-auth` in the `flux-system` namespace with these parameters set:
+
+```sh
+kubectl create secret generic oidc-auth \
+ --namespace flux-system \
+ --from-literal=issuerURL= \
+ --from-literal=clientID= \
+ --from-literal=clientSecret= \
+ --from-literal=redirectURL= \
+ --from-literal=tokenDuration=
+```
+
+Once the HTTP server starts, unauthenticated users will have to click 'Login With OIDC Provider' to log in or use the cluster account (if configured). Upon successful authentication, the users' identity will be impersonated in any calls made to the Kubernetes API, as part of any action they take in the dashboard. By default the Helm chart will configure RBAC correctly but it is recommended to read the [service account](service-account-permissions.mdx) and [user](user-permissions.mdx) permissions pages to understand which actions are needed for Weave GitOps to function correctly.
+
+## Customizing
+
+For some OIDC configurations, you may need to customise the requested [scopes](https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims) or [claims](https://openid.net/specs/openid-connect-core-1_0.html#Claims).
+
+### Scopes
+
+By default, the following scopes are requested "openid","offline_access","email","groups".
+
+The "openid" scope is **mandatory** for OpenID auth, and the "email", and "groups" scopes are commonly used as unique identifiers in organisations.
+
+We use "offline_access" to allow us to refresh OIDC tokens to keep login sessions alive for as long as a refresh token is valid.
+
+You can however change the defaults.
+```sh
+kubectl create secret generic oidc-auth \
+ --namespace flux-system \
+ --from-literal=issuerURL= \
+ --from-literal=clientID= \
+ --from-literal=clientSecret= \
+ --from-literal=redirectURL= \
+ --from-literal=tokenDuration= \
+ --from-literal=customScopes=custom,scopes
+```
+The format for the `customScopes` key is a comma-separated list of scopes to request, in this case, "custom" and "scopes" would be requested, in addition to "openid".
+
+### Claims
+
+By default, the following claims are parsed from the OpenID [ID Token](https://openid.net/specs/openid-connect-core-1_0.html#CodeIDToken) "email" and "groups", these are presented as the `user` and `groups` when we communicate with your Kubernetes API server.
+
+This is equivalent to [configuring](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#configuring-the-api-server) your `kube-apiserver` with `--oidc-username-claim=email --oidc-groups-claim=groups`.
+
+Again, you can configure these from the `oidc-auth` `Secret`.
+
+```sh
+kubectl create secret generic oidc-auth \
+ --namespace flux-system \
+ --from-literal=issuerURL= \
+ --from-literal=clientID= \
+ --from-literal=clientSecret= \
+ --from-literal=redirectURL= \
+ --from-literal=tokenDuration= \
+ --from-literal=claimUsername=sub \
+ --from-literal=claimGroups=groups
+```
+There are two separate configuration keys, you can override them separately, these should match your `kube-apiserver` configuration.
+
+### Login UI
+
+The label of the OIDC button on the login screen is configurable via a feature flag environment variable.
+This can give your users a more familiar experience when logging in.
+
+Adjust the configuration in the helm `values.yaml` file or the `spec.values` section of the Weave Gitops `HelmRelease` resource:
+
+#### Weave Gitops
+
+```yaml
+envVars:
+ - name: WEAVE_GITOPS_FEATURE_OIDC_BUTTON_LABEL
+ value: "Login with ACME"
+```
+
+#### Weave Gitops Enterprise
+
+```yaml
+extraEnvVars:
+ - name: WEAVE_GITOPS_FEATURE_OIDC_BUTTON_LABEL
+ value: "Login with ACME"
+```
\ No newline at end of file
diff --git a/website/versioned_docs/version-0.29.0/configuration/recommended-rbac-configuration.mdx b/website/versioned_docs/version-0.29.0/configuration/recommended-rbac-configuration.mdx
new file mode 100644
index 0000000000..03721cfdf3
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/configuration/recommended-rbac-configuration.mdx
@@ -0,0 +1,178 @@
+---
+title: Recommended RBAC Configuration
+---
+
+This page summarises the contents of the [securing access to the dashboard](securing-access-to-the-dashboard.mdx),
+[service account permissions](service-account-permissions.mdx) and [user permissions](user-permissions.mdx). They should be
+read in addition to this page in order to understand the suggestions made here and
+their ramifications.
+
+This page is purposefully vague as the intention is to give a broad idea of how
+such a system could be implemented, not the specifics as that will be dependent
+on your specific circumstances and goals.
+
+## Summary
+
+The general recommendation is to use OIDC and a small number of groups that
+Weave GitOps can impersonate.
+
+OIDC is the recommended method for managing authentication as it decouples the
+need to manage user lists from the application, allowing it to be managed via
+a central system designed for that purpose (i.e. the OIDC provider). OIDC also
+enables the creation of groups (either via your provider's own systems or by
+using a connector like [Dex](../guides/setting-up-dex.md)).
+
+Configuring Weave GitOps to impersonate kubernetes groups rather than
+users has the following benefits:
+* A user's permissions for impersonation by Weave GitOps can be separate from
+ any other permissions that they may or may not have within the cluster.
+* Users do not have to be individually managed within the cluster and can have
+ their permissions managed together.
+
+## Example set up
+
+Assume that your company has the following people in OIDC
+* Aisha, a cluster admin, who should have full admin access to Weave GitOps
+* Brian, lead of team-A, who should have admin permissions to their team's
+ namespace in Weave GitOps and readonly otherwise
+* June and Jo, developers in team-A who should have read-only access to Weave GitOps
+
+You could then create 3 groups:
+
+* `wego-admin`
+ - Bound to the `ClusterRole`, created by Helm, `wego-admin-cluster-role`
+ - Aisha is the only member
+* `wego-team-a-admin`
+ - Bound to a `Role`, using the same permissions as `wego-admin-role`, created
+ in Team's namespace
+ - Brian and Aisha are members
+* `wego-readonly`
+ - Bound to a `ClusterRole` that matches `wego-admin-cluster-role` but with
+ no `patch` permissions.
+ - Aisha, Brian, June & Jo are all members
+
+The Weave GitOps service account can then be configured with:
+```yaml
+rbac:
+ impersonationResourceNames: ["wego-admin", "wego-team-a-admin", "wego-readonly"]
+ impersonationResources: ["groups"]
+```
+so that only these three groups can be `impersonated` by the service account.
+
+:::caution Using OIDC for cluster and Weave GitOps Authentication
+If the same OIDC provider is used to authenticate a user with the cluster
+itself (e.g. for use with `kubectl`) and to Weave GitOps then, depending
+on OIDC configuration, they may end up with the super-set of their permissions
+from Weave GitOps and any other permissions granted to them.
+
+This can lead to un-intended consequences (e.g. viewing `secrets`). To avoid
+this OIDC providers will often let you configure which groups are returned
+to which clients: the Weave GitOps groups should not be returned to the
+cluster client (and vice versa).
+:::
+
+### Code
+
+The yaml to configure these permissions would look roughly like:
+
+Expand to see example RBAC
+
+```yaml
+# Admin cluster role
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+ name: wego-admin-cluster-role
+rules:
+ - apiGroups: [""]
+ resources: ["secrets", "pods" ]
+ verbs: [ "get", "list" ]
+ - apiGroups: ["apps"]
+ resources: [ "deployments", "replicasets"]
+ verbs: [ "get", "list" ]
+ - apiGroups: ["kustomize.toolkit.fluxcd.io"]
+ resources: [ "kustomizations" ]
+ verbs: [ "get", "list", "patch" ]
+ - apiGroups: ["helm.toolkit.fluxcd.io"]
+ resources: [ "helmreleases" ]
+ verbs: [ "get", "list", "patch" ]
+ - apiGroups: ["source.toolkit.fluxcd.io"]
+ resources: [ "buckets", "helmcharts", "gitrepositories", "helmrepositories", "ocirepositories" ]
+ verbs: [ "get", "list", "patch" ]
+ - apiGroups: [""]
+ resources: ["events"]
+ verbs: ["get", "watch", "list"]
+---
+# Read only cluster role
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+ name: wego-readonly-role
+rules:
+ # All the 'patch' permissions have been removed
+ - apiGroups: [""]
+ resources: ["secrets", "pods" ]
+ verbs: [ "get", "list" ]
+ - apiGroups: ["apps"]
+ resources: [ "deployments", "replicasets"]
+ verbs: [ "get", "list" ]
+ - apiGroups: ["kustomize.toolkit.fluxcd.io"]
+ resources: [ "kustomizations" ]
+ verbs: [ "get", "list" ]
+ - apiGroups: ["helm.toolkit.fluxcd.io"]
+ resources: [ "helmreleases" ]
+ verbs: [ "get", "list" ]
+ - apiGroups: ["source.toolkit.fluxcd.io"]
+ resources: [ "buckets", "helmcharts", "gitrepositories", "helmrepositories", "ocirepositories" ]
+ verbs: [ "get", "list" ]
+ - apiGroups: [""]
+ resources: ["events"]
+ verbs: ["get", "watch", "list"]
+---
+# Bind the cluster admin role to the wego-admin group
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+ name: wego-cluster-admin
+subjects:
+- kind: Group
+ name: wego-admin # only Aisha is a member
+ apiGroup: rbac.authorization.k8s.io
+roleRef:
+ kind: ClusterRole
+ name: wego-admin-cluster-role
+ apiGroup: rbac.authorization.k8s.io
+---
+# Bind the admin role in the team-a namespace for the wego-team-a-admin group
+apiVersion: rbac.authorization.k8s.io/v1
+kind: RoleBinding
+metadata:
+ name: wego-team-a-admin-role
+ namespace: team-a
+subjects:
+- kind: Group
+ name: wego-team-a-admin # Aisha & Brian are members
+ apiGroup: rbac.authorization.k8s.io
+roleRef:
+ # Use the cluster role to set rules, just bind them in the team-a namespace
+ kind: ClusterRole
+ name: wego-admin-role
+ apiGroup: rbac.authorization.k8s.io
+---
+# Bind the readonly role to the readonly group
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+ name: wego-readonly-role
+subjects:
+- kind: Group
+ name: wego-readonly # Everyone is a member
+ apiGroup: rbac.authorization.k8s.io
+roleRef:
+ kind: ClusterRole
+ name: wego-readonly-role
+ apiGroup: rbac.authorization.k8s.io
+---
+```
+
+
diff --git a/website/versioned_docs/version-0.29.0/configuration/securing-access-to-the-dashboard.mdx b/website/versioned_docs/version-0.29.0/configuration/securing-access-to-the-dashboard.mdx
new file mode 100644
index 0000000000..b0f40ae381
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/configuration/securing-access-to-the-dashboard.mdx
@@ -0,0 +1,15 @@
+---
+title: Securing access to the dashboard
+---
+
+## Dashboard Login
+
+There are 2 supported methods for logging in to the dashboard:
+- [Login via an OIDC provider](../oidc-access)
+- [Login via a cluster user account](../emergency-user) (not recommended)
+
+The recommended method is to integrate with an OIDC provider,
+as this will let you control permissions for existing users and groups that have
+already been configured to use OIDC. However, it is also possible to use the Emergency Cluster
+User Account to login, if an OIDC provider is not available to use.
+Both methods work with standard Kubernetes RBAC.
diff --git a/website/versioned_docs/version-0.29.0/configuration/service-account-permissions.mdx b/website/versioned_docs/version-0.29.0/configuration/service-account-permissions.mdx
new file mode 100644
index 0000000000..ef81eb1253
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/configuration/service-account-permissions.mdx
@@ -0,0 +1,124 @@
+---
+title: Dashboard Runtime Permissions
+---
+
+# GitOps Dashboard Service Account Permissions
+
+:::danger Important
+This doc covers the service account [permissions](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
+for the **Weave Gitops application** itself (ie. the permissions the Dashboard needs to work).
+For the service account for the **cluster user** role (ie. for the user accessing the
+GitOps Dashboard), see the page [here](user-permissions.mdx).
+:::
+
+The default permissions of the service account are defined in the [helm chart](https://github.com/weaveworks/weave-gitops/tree/main/charts/gitops-server/templates/role.yaml) which
+will generate a cluster role with the following permissions:
+
+```yaml
+rules:
+# Used to query the cluster
+- apiGroups: [""]
+ resources: ["users", "groups"] # set by rbac.impersonationResources
+ verbs: [ "impersonate" ]
+ # resourceNames: [] # set by rbac.impersonationResourceNames
+# Used to get OIDC/static user credentials for login
+- apiGroups: [""]
+ resources: [ "secrets" ]
+ verbs: [ "get", "list" ]
+ resourceNames: # set by rbac.viewSecretsResourceNames
+ - "cluster-user-auth"
+ - "oidc-auth"
+# The service account needs to read namespaces to know where it can query
+- apiGroups: [ "" ]
+ resources: [ "namespaces" ]
+ verbs: [ "get", "list" ]
+```
+
+These allow the pod to do three things:
+* [Impersonate](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) the user and operate in the cluster as them
+* Read the available namespaces (this is required to understand the users' permissions)
+* Read the `cluster-user-auth` and `oidc-auth` secrets, which are the default secrets
+ to store the emergency cluster user account and OIDC configuration (see
+ [securing access to the dashboard](securing-access-to-the-dashboard.mdx))
+
+## The Helm values
+
+| Value | Description | Default |
+|-----------------------------------|---------------------------------------------------------------------|--------------------------------------|
+| `rbac.impersonationResources` | Which resource types the service account can impersonate | `["users", "groups"]` |
+| `rbac.impersonationResourceNames` | Specific users, groups or services account that can be impersonated | `[]` |
+| `rbac.viewSecretsResourceNames` | Specific secrets that can be read | `["cluster-user-auth", "oidc-auth"]` |
+
+
+## Impersonation
+
+The primary way Weave GitOps queries the Kube API is via `impersonation`, the
+application (not the cluster) authenticates the user (either via the [emergency
+cluster user](../emergency-user) credentials or OIDC) then makes calls to the Kube API on the user's
+behalf. This is equivalent to making a kubectl call like:
+
+```bash
+$ kubectl get deployments --as aisha@example.com
+```
+
+Assuming the user `aisha@example.com` has been granted permissions to get
+deployments within the cluster then this will return them. The same occurs
+within the application. This makes the proper configuration of the application's
+permissions very important as, without proper restrictions it can impersonate
+very powerful `users` or `groups`. For example, the `system:masters` is group
+is generally bound to the `cluster-admin` role which can do anything.
+
+For more details of the permissions needed by the user or group see the
+[user permissions](user-permissions.mdx) guide.
+
+### Configuring impersonation
+
+It is highly recommended that you limit which users and groups that the
+application can impersonate by setting `rbac.impersonationResourceNames` in
+the Helm chart's `values`. e.g.:
+
+```yaml
+rbac:
+ impersonationResources: ["groups"]
+ impersonationResourceNames:
+ - admin
+ - dev-team
+ - qa-team
+```
+In this example the application can only impersonate the groups admin, dev-team
+and qa-team (this also, implicitly disables the [emergency cluster user](../emergency-user)).
+
+Unfortunately not all OIDC providers support groups so you may need to
+manually enumerate users, for example:
+```yaml
+rbac:
+ impersonationResources: ["users"]
+ impersonationResourceNames:
+ - aisha@example.com
+ - bill@example.com
+ - wego-admin # enable the emergency cluster user
+```
+
+A better, albeit more involved, solution is to set up an OIDC connector like
+[Dex](../guides/setting-up-dex.md) and use that to manage groups for you.
+
+## Get namespaces
+
+The application itself uses get namespace permissions to pre-cache the list of
+available namespaces. As the user accesses resources their permissions within
+various namespaces is also cached to speed up future operations.
+
+## Reading the `cluster-user-auth` and `oidc-auth secrets`
+
+The `cluster-user-auth` and `oidc-auth` secrets provide information for authenticating
+to the application. The former holds the username and bcrypt-hashed password
+for the [emergency user](../emergency-user) and the latter holds OIDC configuration.
+
+The application needs to be able to access these secrets in order to
+authenticate users.
+
+### Configuring secrets
+
+The `rbac.viewSecretsResourceNames` value allows the operator to change which secrets the
+application can read. This is mostly so that, if the emergency user is not
+configured, that secret can be removed, or if the secret _is_ in use but renamed.
diff --git a/website/versioned_docs/version-0.29.0/configuration/tls.md b/website/versioned_docs/version-0.29.0/configuration/tls.md
new file mode 100644
index 0000000000..b9932d6ff6
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/configuration/tls.md
@@ -0,0 +1,49 @@
+---
+title: TLS and Certificates
+---
+
+## TLS configuration
+
+By default the dashboard will listen on 0.0.0.0:9001 with TLS disabled and
+without exposing any external connection.
+
+Exposing services without TLS if not recommended. Without a certificate, a user
+can't be sure they are using the right service, and the traffic will be easily
+monitored, or even tampered with. All communication between the user and an endpoint
+with TLS will be encrypted.
+
+To expose an external connection, you must first configure TLS. TLS termination
+can be provided via an ingress controller or directly by the dashboard. In
+either case, the Helm Release must be updated. To have the dashboard itself
+handle TLS, you must create a `tls` secret containing the cert and key:
+
+```cli
+kubectl create secret tls my-tls-secret \
+ --cert=path/to/cert/file \
+ --key=path/to/key/file
+```
+
+and reference it from the helm release:
+
+```yaml
+ values:
+ serverTLS:
+ enabled: true
+ secretName: "my-tls-secret"
+```
+
+If you prefer to delegate TLS handling to the ingress controller instead, your
+helm release should look like:
+
+```yaml
+ values:
+ ingress:
+ enabled: true
+ ... other parameters specific to the ingress type ...
+```
+
+## cert-manager
+
+Install [cert-manager](../guides/cert-manager.md) and request a `Certificate` in
+the `flux-system` namespace. Provide the name of secret associated with the
+certificate to the weave-gitops-enterprise HelmRelease as described above.
diff --git a/website/versioned_docs/version-0.29.0/configuration/user-permissions.mdx b/website/versioned_docs/version-0.29.0/configuration/user-permissions.mdx
new file mode 100644
index 0000000000..2ec436f633
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/configuration/user-permissions.mdx
@@ -0,0 +1,244 @@
+---
+title: User Permissions
+---
+import TierLabel from "../_components/TierLabel";
+
+This is an explanation of the [kubernetes permissions](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
+needed by users/groups of the Weave GitOps application. As covered in
+[service account permissions](service-account-permissions.mdx)
+the primary way that the application interacts with the Kube API is via [impersonation](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation).
+This means that the permissions granted to the users and groups that Weave GitOps
+can impersonate determine the scope of actions that it can take within your cluster.
+
+At a minimum, a User should be bound to Role in the `flux-system` namespace (where
+flux stores its resources by default) with the following permissions:
+
+```yaml
+rules:
+ # Flux Resources
+ - apiGroups: ["source.toolkit.fluxcd.io"]
+ resources: [ "buckets", "helmcharts", "gitrepositories", "helmrepositories", "ocirepositories" ]
+ verbs: [ "get", "list", "watch", "patch" ]
+
+ - apiGroups: ["kustomize.toolkit.fluxcd.io"]
+ resources: [ "kustomizations" ]
+ verbs: [ "get", "list", "watch", "patch" ]
+
+ - apiGroups: ["helm.toolkit.fluxcd.io"]
+ resources: [ "helmreleases" ]
+ verbs: [ "get", "list", "watch", "patch" ]
+
+ - apiGroups: [ "notification.toolkit.fluxcd.io" ]
+ resources: [ "providers", "alerts" ]
+ verbs: [ "get", "list", "watch", "patch" ]
+
+ - apiGroups: ["infra.contrib.fluxcd.io"]
+ resources: ["terraforms"]
+ verbs: [ "get", "list", "watch", "patch" ]
+
+ # Read access for all other Kubernetes objects
+ - apiGroups: ["*"]
+ resources: ["*"]
+ verbs: [ "get", "list", "watch" ]
+```
+
+For a wider scope the User can be bound to a ClusterRole with the same set.
+
+### Flux Resources
+
+The resources that Flux works with directly, including the one from TF-controller.
+
+| Api Group | Resources | Permissions |
+| ------------------------------ | ----------------------------------------------------------------------- | ---------------- |
+| kustomize.toolkit.fluxcd.io | kustomizations | get, list, patch |
+| helm.toolkit.fluxcd.io | helmreleases | get, list, patch |
+| source.toolkit.fluxcd.io | buckets, helmcharts, gitrepositories, helmrepositories, ocirepositories | get, list, patch |
+| notification.toolkit.fluxcd.io | providers, alerts | get, list |
+| infra.contrib.fluxcd.io | terraforms | get, list, patch |
+
+In order for Weave GitOps to be able to accurately display the state of Flux it
+needs to be able to query the [CRDs](https://fluxcd.io/docs/components/) that Flux uses. This is done using the
+`get` and `list` permissions
+
+The `patch` permissions are used for 2 features: to suspend and resume
+reconciliation of a resource by modifying the 'spec' of a resource,
+and to force reconciliation of a resource by modifying the annotations
+of the resource. These features work the same way `flux suspend`,
+`flux resume` and `flux reconcile` does on the CLI.
+
+### Resources managed via Flux
+
+| Api Group | Resources | Permissions |
+|---------------------------|--------------------------------------------------------------------------------|------------------|
+| "" | configmaps, secrets, pods, services, persistentvolumes, persistentvolumeclaims | get, list, watch |
+| apps | deployments, replicasets, statefulsets | get, list, watch |
+| batch | jobs, cronjobs | get, list, watch |
+| autoscaling | horizontalpodautoscalers | get, list, watch |
+| rbac.authorization.k8s.io | roles, clusterroles, rolebindings, clusterrolebindings | get, list, watch |
+| networking.k8s.io | ingresses | get, list, watch |
+
+Weave GitOps reads basic resources so that it can monitor the effect that Flux has
+on what's running.
+
+Reading `secrets` enables Weave GitOps to monitor the state of Helm releases
+as that's where it stores the [state by default](https://helm.sh/docs/faq/changes_since_helm2/#secrets-as-the-default-storage-driver).
+For clarity this these are the Helm release objects _not_ the Flux HelmRelease
+resource (which are dealt with by the earlier section).
+
+### Feedback from Flux
+
+The primary method by which Flux communicates the status of itself is by events,
+these will show when reconciliations start and stop, whether they're successful
+and information as to why they're not.
+
+## Weave GitOps Enterprise
+
+Weave GitOps Enterprise extends Weave GitOps OSS by adding more roles. These roles may need to be extended further in order to support certain use cases. Some of the most common use cases are described below.
+
+### Progressive delivery with Flagger
+
+Weave GitOps Enterprise integrates with Flagger in order to provide a view on progressive delivery deployments. This includes the ability to view all the resources that Flagger manages during its operation. The default ClusterRole `gitops-canaries-reader` includes the minimum permissions necessary for a user to be able to view canary object details, metric template object details and canary related events.
+
+When Flagger is configured to integrate with a service mesh such as Linkerd or Istio for the rollout, then this ClusterRole needs to be extended so that it can read the additional service mesh resources being generated by Flagger. Note that currently, in order to display service mesh or ingress related resources, we require `spec.provider` to be set in each canary resource.
+
+The following table provides a list of all the custom resources that Flagger generates grouped by provider:
+
+| Provider | API Group | Resource |
+| --- | --- | --- |
+| AppMesh | appmesh.k8s.aws | virtualnode |
+| | appmesh.k8s.aws | virtualrouter |
+| | appmesh.k8s.aws | virtualservice |
+| Linkerd | split.smi-spec.io | trafficsplit |
+| Istio | networking.istio.io | destinationrule |
+| | networking.istio.io | virtualservice |
+| Contour | projectcontour.io | httpproxy |
+| Gloo | gateway.solo.io | routetable |
+| | gloo.solo.io | upstream |
+| Nginx | networking.k8s.io | ingress |
+| Skipper | networking.k8s.io | ingress |
+| Traefik | traefik.containo.us | traefikservice |
+| Open Service Mesh | split.smi-spec.io | trafficsplit |
+| Kuma | kuma.io | trafficroute |
+| GatewayAPI | gateway.networking.k8s.io | httproute |
+
+For example, the following manifest shows how `gitops-canaries-reader` has been extended to allow the user for viewing TrafficSplit resources when Linkerd is used:
+
+Expand to see example canary reader RBAC
+
+```yaml title="gitops-canaries-reader.yaml"
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+ name: gitops-canaries-reader
+rules:
+- apiGroups:
+ - flagger.app
+ resources:
+ - canaries
+ - metrictemplates
+ verbs:
+ - get
+ - list
+- apiGroups:
+ - ""
+ resources:
+ - events
+ verbs:
+ - get
+ - watch
+ - list
+# Additional permissions for Linkerd resources are added below
+- apiGroups:
+ - split.smi-spec.io
+ resources:
+ - trafficsplits
+ verbs:
+ - get
+ - list
+```
+
+
+
+#### Setting up remote cluster permissions
+
+In order to view canaries in a remote cluster from the management cluster, you need to consider the following:
+- The service account used to access the remote cluster needs to be able to list namespaces and custom resource definitions in the given cluster. It additionally needs to be able to impersonate users and groups.
+- The user or group that logs in to the management cluster, needs appropriate permissions to certain resources of the remote cluster.
+
+For example, applying the following manifest on remote clusters, ensures that the `wego-admin` user will be able to view canary information from within the Weave GitOps Enterprise UI on the management cluster:
+
+Expand to see example of remote cluster canary reader
+
+```yaml title="remote-cluster-service-user-rbac.yaml"
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+ name: user-groups-impersonator
+rules:
+ - apiGroups: [""]
+ resources: ["users", "groups"]
+ verbs: ["impersonate"]
+ - apiGroups: [""]
+ resources: ["namespaces"]
+ verbs: ["get", "list"]
+ - apiGroups: ["apiextensions.k8s.io"]
+ resources: ["customresourcedefinitions"]
+ verbs: ["get", "list"]
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+ name: impersonate-user-groups
+subjects:
+ - kind: ServiceAccount
+ name: remote-cluster-01 # Service account created in remote cluster
+ namespace: default
+roleRef:
+ kind: ClusterRole
+ name: user-groups-impersonator
+ apiGroup: rbac.authorization.k8s.io
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+ name: canary-reader
+rules:
+ - apiGroups: [""]
+ resources: [ "events", "services" ]
+ verbs: [ "get", "list", "watch" ]
+ - apiGroups: [ "apps" ]
+ resources: [ "*" ]
+ verbs: [ "get", "list" ]
+ - apiGroups: [ "autoscaling" ]
+ resources: [ "*" ]
+ verbs: [ "get", "list" ]
+ - apiGroups: [ "flagger.app" ]
+ resources: [ "canaries", "metrictemplates"]
+ verbs: [ "get", "list", "watch" ]
+ - apiGroups: [ "helm.toolkit.fluxcd.io" ]
+ resources: [ "helmreleases" ]
+ verbs: [ "get", "list" ]
+ - apiGroups: [ "kustomize.toolkit.fluxcd.io" ]
+ resources: [ "kustomizations" ]
+ verbs: [ "get", "list" ]
+ - apiGroups: [ "source.toolkit.fluxcd.io" ]
+ resources: [ "buckets", "helmcharts", "gitrepositories", "helmrepositories", "ocirepositories" ]
+ verbs: [ "get", "list" ]
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+ name: read-canaries
+subjects:
+- kind: User
+ name: wego-admin # User logged in management cluster, impersonated via service account
+ apiGroup: rbac.authorization.k8s.io
+roleRef:
+ kind: ClusterRole
+ name: canary-reader
+ apiGroup: rbac.authorization.k8s.io
+```
+
+
+
+You may need to add more users/groups to the `read-canaries` ClusterRoleBinding to ensure additional users can view canary information from within the Weave GitOps Enterprise UI.
diff --git a/website/versioned_docs/version-0.29.0/enterprise/getting-started/install-enterprise-airgap.mdx b/website/versioned_docs/version-0.29.0/enterprise/getting-started/install-enterprise-airgap.mdx
new file mode 100644
index 0000000000..2fc25470cf
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/enterprise/getting-started/install-enterprise-airgap.mdx
@@ -0,0 +1,576 @@
+---
+title: Install Enterprise in Air-gapped Environments
+hide_title: true
+toc_max_heading_level: 4
+---
+
+import TierLabel from "../../_components/TierLabel";
+
+# Install Enterprise in Air-gapped Environments
+
+From [wikipedia](https://en.wikipedia.org/wiki/Air_gap_(networking))
+
+>An air gap, air wall, air gapping or disconnected network is a network security measure employed on one or more computers
+to ensure that a secure computer network is physically isolated from unsecured networks, such as the public Internet or an unsecured local area network...
+
+This document guides on how to install Weave Gitops Enterprise in a restricted environment.
+
+# Before You Start
+
+There are multiple restrictions that could happen within an air-gapped environment. This guide assumes that you have egress network
+restrictions. In order to install Weave Gitops Enterprise (WGE), the required artifacts are required to be loaded
+from a private registry. This guide helps you with the task to identity the Helm charts
+and container images required to install WGE and to load them into your private registry.
+
+It also assumes that you could prepare the installation from a proxy host. A proxy host is defined here
+as a computer that is able to access to both the public and private network. It could take different shapes,
+for example, it could be a bastion host, a corp laptop, etc.
+
+Access to both public and private network is required during the airgap installation but not simultaneously.
+It is expected to have an online stage to gather the artifacts first, and an offline stage later,
+to load the artifacts in the private network.
+
+Finally, we aim to provide an end to end example to use it as a guidance more than a recipe. Feel free to adapt the details
+that do not fit within your context.
+
+# Install
+
+There are different variations of the following stages and conditions. We consider that installing
+WGE in an air-gapped environment could follow the following stages.
+
+1. Setup a WGE install environment.
+2. Collect artifacts and publish to a private registry.
+3. Install Weave Gitops Enterprise in the air-gapped environment.
+
+## Setup a WGE install environment
+
+The main goal of this stage is to recreate a local Weave Gitops Enterprise within your context, to collect
+the container images and Helm charts, that will be required in your private registry for the offline installation.
+
+A three-step setup is followed.
+
+1. Setup a proxy host
+2. Setup a private registry
+3. Install Weave Gitops Enterprise
+
+### Setup a proxy host
+
+There are many possible configurations for this host. This guide will assume that the host has installed the following:
+
+- [docker](https://www.docker.com/) as container runtime.
+- [kubectl and kind](https://kubernetes.io/docs/tasks/tools)
+- [helm](https://helm.sh/docs/intro/install/)
+- [skopeo](https://github.com/containers/skopeo) to manage container images
+- [flux](https://fluxcd.io/flux/cmd/) to boostrap Flux in the environment.
+- [clusterctl](https://cluster-api.sigs.k8s.io/user/quick-start.html#install-clusterctl) to replicate the cluster management
+capabilities.
+
+#### Create a Kind Cluster
+
+Create a kind cluster with registry following [this guide](https://kind.sigs.k8s.io/docs/user/local-registry/)
+
+#### Install Flux
+
+You could just use `flux install` to install Flux into your kind cluster
+
+#### Set up a Helm repo
+
+We are going to install [ChartMuseum](https://chartmuseum.com/) via Flux.
+
+Remember to also install helm plugin
+[cm-push](https://github.com/chartmuseum/helm-push).
+
+Expand to see installation yaml
+
+```yaml
+---
+apiVersion: source.toolkit.fluxcd.io/v1beta2
+kind: HelmRepository
+metadata:
+ name: chartmuseum
+ namespace: flux-system
+spec:
+ interval: 10m
+ url: https://chartmuseum.github.io/charts
+---
+apiVersion: helm.toolkit.fluxcd.io/v2beta1
+kind: HelmRelease
+metadata:
+ name: chartmuseum
+ namespace: flux-system
+spec:
+ chart:
+ spec:
+ chart: chartmuseum
+ sourceRef:
+ kind: HelmRepository
+ name: chartmuseum
+ namespace: flux-system
+ interval: 10m0s
+ timeout: 10m0s
+ releaseName: helm-repo
+ install:
+ crds: CreateReplace
+ remediation:
+ retries: 3
+ values:
+ env:
+ open:
+ DISABLE_API: "false"
+ AUTH_ANONYMOUS_GET: "true"
+```
+
+
+
+Set up access from your host.
+
+```bash
+#expose kubernetes svc
+kubectl -n flux-system port-forward svc/helm-repo-chartmuseum 8080:8080 &
+
+#add hostname
+sudo -- sh -c "echo 127.0.0.1 helm-repo-chartmuseum >> /etc/hosts"
+
+```
+Test that you could reach it.
+```bash
+#add repo to helm
+helm repo add private http://helm-repo-chartmuseum:8080
+
+#test that works
+helm repo update private
+```
+
+At this stage you have already a private registry for container images and helm charts.
+
+### Install Weave Gitops Enterprise
+
+This step is to gather the artifacts and images in your local environment to push to the private registry.
+
+#### Cluster API
+
+This would vary depending on the provider, given that we target a offline environment, most likely we are in
+a private cloud environment, so we will be using [liquidmetal](https://weaveworks-liquidmetal.github.io/site/docs/tutorial-basics/capi/).
+
+Export these environment variables to configure your CAPI experience. Adjust them to your context.
+
+```shell
+export CAPI_BASE_PATH=/tmp/capi
+export CERT_MANAGER_VERSION=v1.9.1
+export CAPI_VERSION=v1.3.0
+export CAPMVM_VERSION=v0.7.0
+export EXP_CLUSTER_RESOURCE_SET=true
+export CONTROL_PLANE_MACHINE_COUNT=1
+export WORKER_MACHINE_COUNT=1
+export CONTROL_PLANE_VIP="192.168.100.9"
+export HOST_ENDPOINT="192.168.1.130:9090"
+```
+
+Execute the following script to generate `clusterctl` config file.
+
+```shell
+cat << EOF > clusterctl.yaml
+cert-manager:
+ url: "$CAPI_BASE_PATH/cert-manager/$CERT_MANAGER_VERSION/cert-manager.yaml"
+
+providers:
+ - name: "microvm"
+ url: "$CAPI_BASE_PATH/infrastructure-microvm/$CAPMVM_VERSION/infrastructure-components.yaml"
+ type: "InfrastructureProvider"
+ - name: "cluster-api"
+ url: "$CAPI_BASE_PATH/cluster-api/$CAPI_VERSION/core-components.yaml"
+ type: "CoreProvider"
+ - name: "kubeadm"
+ url: "$CAPI_BASE_PATH/bootstrap-kubeadm/$CAPI_VERSION/bootstrap-components.yaml"
+ type: "BootstrapProvider"
+ - name: "kubeadm"
+ url: "$CAPI_BASE_PATH/control-plane-kubeadm/$CAPI_VERSION/control-plane-components.yaml"
+ type: "ControlPlaneProvider"
+EOF
+```
+Execute `make` using the following makefile to intialise CAPI in your cluster:
+
+Expand to see Makefile contents
+
+```makefile
+.PHONY := capi
+
+capi: capi-init capi-cluster
+
+capi-init: cert-manager cluster-api bootstrap-kubeadm control-plane-kubeadm microvm clusterctl-init
+
+cert-manager:
+ mkdir -p $(CAPI_BASE_PATH)/cert-manager/$(CERT_MANAGER_VERSION)
+ curl -L https://github.com/cert-manager/cert-manager/releases/download/$(CERT_MANAGER_VERSION)/cert-manager.yaml --output $(CAPI_BASE_PATH)/cert-manager/$(CERT_MANAGER_VERSION)/cert-manager.yaml
+
+cluster-api:
+ mkdir -p $(CAPI_BASE_PATH)/cluster-api/$(CAPI_VERSION)
+ curl -L https://github.com/kubernetes-sigs/cluster-api/releases/download/$(CAPI_VERSION)/core-components.yaml --output $(CAPI_BASE_PATH)/cluster-api/$(CAPI_VERSION)/core-components.yaml
+ curl -L https://github.com/kubernetes-sigs/cluster-api/releases/download/$(CAPI_VERSION)/metadata.yaml --output $(CAPI_BASE_PATH)/cluster-api/$(CAPI_VERSION)/metadata.yaml
+
+bootstrap-kubeadm:
+ mkdir -p $(CAPI_BASE_PATH)/bootstrap-kubeadm/$(CAPI_VERSION)
+ curl -L https://github.com/kubernetes-sigs/cluster-api/releases/download/$(CAPI_VERSION)/bootstrap-components.yaml --output $(CAPI_BASE_PATH)/bootstrap-kubeadm/$(CAPI_VERSION)/bootstrap-components.yaml
+ curl -L https://github.com/kubernetes-sigs/cluster-api/releases/download/$(CAPI_VERSION)/metadata.yaml --output $(CAPI_BASE_PATH)/bootstrap-kubeadm/$(CAPI_VERSION)/metadata.yaml
+
+control-plane-kubeadm:
+ mkdir -p $(CAPI_BASE_PATH)/control-plane-kubeadm/$(CAPI_VERSION)
+ curl -L https://github.com/kubernetes-sigs/cluster-api/releases/download/$(CAPI_VERSION)/control-plane-components.yaml --output $(CAPI_BASE_PATH)/control-plane-kubeadm/$(CAPI_VERSION)/control-plane-components.yaml
+ curl -L https://github.com/kubernetes-sigs/cluster-api/releases/download/$(CAPI_VERSION)/metadata.yaml --output $(CAPI_BASE_PATH)/control-plane-kubeadm/$(CAPI_VERSION)/metadata.yaml
+
+microvm:
+ mkdir -p $(CAPI_BASE_PATH)/infrastructure-microvm/$(CAPMVM_VERSION)
+ curl -L https://github.com/weaveworks-liquidmetal/cluster-api-provider-microvm/releases/download/$(CAPMVM_VERSION)/infrastructure-components.yaml --output $(CAPI_BASE_PATH)/infrastructure-microvm/$(CAPMVM_VERSION)/infrastructure-components.yaml
+ curl -L https://github.com/weaveworks-liquidmetal/cluster-api-provider-microvm/releases/download/$(CAPMVM_VERSION)/cluster-template-cilium.yaml --output $(CAPI_BASE_PATH)/infrastructure-microvm/$(CAPMVM_VERSION)/cluster-template-cilium.yaml
+ curl -L https://github.com/weaveworks-liquidmetal/cluster-api-provider-microvm/releases/download/$(CAPMVM_VERSION)/metadata.yaml --output $(CAPI_BASE_PATH)/infrastructure-microvm/$(CAPMVM_VERSION)/metadata.yaml
+
+clusterctl-init:
+ clusterctl init --wait-providers -v 4 --config clusterctl.yaml --infrastructure microvm
+
+capi-cluster:
+ clusterctl generate cluster --config clusterctl.yaml -i microvm:$(CAPMVM_VERSION) -f cilium lm-demo | kubectl apply -f -
+```
+
+
+
+#### Deploying the Terraform Controller
+
+Apply the following example manifest to deploy the Terraform Controller:
+
+Expand to see file contents
+
+```yaml
+apiVersion: source.toolkit.fluxcd.io/v1beta2
+kind: HelmRepository
+metadata:
+ name: tf-controller
+ namespace: flux-system
+spec:
+ interval: 10m
+ url: https://weaveworks.github.io/tf-controller/
+---
+apiVersion: helm.toolkit.fluxcd.io/v2beta1
+kind: HelmRelease
+metadata:
+ name: tf-controller
+ namespace: flux-system
+spec:
+ chart:
+ spec:
+ chart: tf-controller
+ version: "0.9.2"
+ sourceRef:
+ kind: HelmRepository
+ name: tf-controller
+ namespace: flux-system
+ interval: 10m0s
+ install:
+ crds: CreateReplace
+ remediation:
+ retries: 3
+ upgrade:
+ crds: CreateReplace
+```
+
+
+
+#### Weave Gitops Enterprise
+
+Update the following manifest to your context.
+
+Expand to see file contents
+
+```yaml {4-7,19-20}
+---
+apiVersion: v1
+data:
+ deploy-key:
+ entitlement:
+ password:
+ username:
+kind: Secret
+metadata:
+ labels:
+ kustomize.toolkit.fluxcd.io/name: shared-secrets
+ kustomize.toolkit.fluxcd.io/namespace: flux-system
+ name: weave-gitops-enterprise-credentials
+ namespace: flux-system
+type: Opaque
+---
+apiVersion: v1
+data:
+ password:
+ username:
+kind: Secret
+metadata:
+ labels:
+ kustomize.toolkit.fluxcd.io/name: enterprise
+ kustomize.toolkit.fluxcd.io/namespace: flux-system
+ name: cluster-user-auth
+ namespace: flux-system
+type: Opaque
+---
+apiVersion: source.toolkit.fluxcd.io/v1beta2
+kind: HelmRepository
+metadata:
+ name: weave-gitops-enterprise-charts
+ namespace: flux-system
+spec:
+ interval: 10m
+ secretRef:
+ name: weave-gitops-enterprise-credentials
+ url: https://charts.dev.wkp.weave.works/releases/charts-v3
+---
+apiVersion: helm.toolkit.fluxcd.io/v2beta1
+kind: HelmRelease
+metadata:
+ name: weave-gitops-enterprise
+ namespace: flux-system
+spec:
+ chart:
+ spec:
+ chart: mccp
+ version: "0.10.2"
+ sourceRef:
+ kind: HelmRepository
+ name: weave-gitops-enterprise-charts
+ namespace: flux-system
+ interval: 10m0s
+ install:
+ crds: CreateReplace
+ remediation:
+ retries: 3
+ upgrade:
+ crds: CreateReplace
+ values:
+ global:
+ capiEnabled: true
+ enablePipelines: true
+ enableTerraformUI: true
+ clusterBootstrapController:
+ enabled: true
+ cluster-controller:
+ controllerManager:
+ kubeRbacProxy:
+ image:
+ repository: gcr.io/kubebuilder/kube-rbac-proxy
+ tag: v0.8.0
+ manager:
+ image:
+ repository: docker.io/weaveworks/cluster-controller
+ tag: v1.4.1
+ policy-agent:
+ enabled: true
+ image: weaveworks/policy-agent
+ pipeline-controller:
+ controller:
+ manager:
+ image:
+ repository: ghcr.io/weaveworks/pipeline-controller
+ images:
+ clustersService: docker.io/weaveworks/weave-gitops-enterprise-clusters-service:v0.10.2
+ uiServer: docker.io/weaveworks/weave-gitops-enterprise-ui-server:v0.10.2
+ clusterBootstrapController: weaveworks/cluster-bootstrap-controller:v0.4.0
+```
+
+
+
+At this stage you should have a local management cluster with Weave GitOps Enterprise installed.
+
+```bash
+➜ kubectl get pods -A
+NAMESPACE NAME READY STATUS RESTARTS AGE
+...
+flux-system weave-gitops-enterprise-cluster-controller-6f8c69dc8-tq994 2/2 Running 5 (12h ago) 13h
+flux-system weave-gitops-enterprise-mccp-cluster-bootstrap-controller-cxd9c 2/2 Running 0 13h
+flux-system weave-gitops-enterprise-mccp-cluster-service-8485f5f956-pdtxw 1/1 Running 0 12h
+flux-system weave-gitops-enterprise-pipeline-controller-85b76d95bd-2sw7v 1/1 Running 0 13h
+...
+```
+
+You can observe the installed Helm Charts with `kubectl`:
+
+```bash
+kubectl get helmcharts.source.toolkit.fluxcd.io
+NAME CHART VERSION SOURCE KIND SOURCE NAME AGE READY STATUS
+flux-system-cert-manager cert-manager 0.0.7 HelmRepository weaveworks-charts 13h True pulled 'cert-manager' chart with version '0.0.7'
+flux-system-tf-controller tf-controller 0.9.2 HelmRepository tf-controller 13h True pulled 'tf-controller' chart with version '0.9.2'
+flux-system-weave-gitops-enterprise mccp v0.10.2 HelmRepository weave-gitops-enterprise-charts 13h True pulled 'mccp' chart with version '0.10.2'
+```
+
+As well as the container images:
+
+```bash
+
+kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec['containers','initContainers'][*].image}" |tr -s '[[:space:]]' '\n' \
+| sort | uniq | grep -vE 'kindest|etcd|coredns'
+
+docker.io/prom/prometheus:v2.34.0
+docker.io/weaveworks/cluster-controller:v1.4.1
+docker.io/weaveworks/weave-gitops-enterprise-clusters-service:v0.10.2
+docker.io/weaveworks/weave-gitops-enterprise-ui-server:v0.10.2
+ghcr.io/fluxcd/flagger-loadtester:0.22.0
+ghcr.io/fluxcd/flagger:1.21.0
+ghcr.io/fluxcd/helm-controller:v0.23.1
+ghcr.io/fluxcd/kustomize-controller:v0.27.1
+ghcr.io/fluxcd/notification-controller:v0.25.2
+...
+```
+
+## Collect and Publish Artifacts
+
+This section guides you to push installed artifacts to your private registry.
+Here's a Makefile to help you with each stage:
+
+Expand to see Makefile contents
+
+```makefile {4-6}
+.PHONY := all
+
+#set these variable with your custom configuration
+PRIVATE_HELM_REPO_NAME=private
+REGISTRY=localhost:5001
+WGE_VERSION=0.10.2
+
+WGE=mccp-$(WGE_VERSION)
+WGE_CHART=$(WGE).tgz
+
+all: images charts
+
+charts: pull-charts push-charts
+
+images:
+ kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec['containers','initContainers'][*].image}" \
+ |tr -s '[[:space:]]' '\n' | sort | uniq | grep -vE 'kindest|kube-(.*)|etcd|coredns' | xargs -L 1 -I {} ./image-sync.sh {} $(REGISTRY)
+ kubectl get microvmmachinetemplates --all-namespaces -o jsonpath="{.items[*].spec.template.spec.kernel.image}"|tr -s '[[:space:]]' '\n' \
+ | sort | uniq | xargs -L 1 -I {} ./image-sync.sh {} $(REGISTRY)
+
+pull-charts:
+ curl -L https://s3.us-east-1.amazonaws.com/weaveworks-wkp/releases/charts-v3/$(WGE_CHART) --output $(WGE_CHART)
+
+push-charts:
+ helm cm-push -f $(WGE_CHART) $(PRIVATE_HELM_REPO_NAME)
+```
+
+
+
+The `image-sync.sh` referenced in the `images` target of the the above Makefile
+is similar to:
+
+```shell
+skopeo copy docker://$1 docker://$2/$1 --preserve-digests --multi-arch=all
+```
+
+>[Skopeo](https://github.com/containers/skopeo) allows you to configure a range a security features to meet your requirements.
+For example, configuring trust policies before pulling or signing containers before making them available in your private network.
+Feel free to adapt the previous script to meet your security needs.
+
+1. Configure the environment variables to your context.
+2. Execute `make` to automatically sync Helm charts and container images.
+
+```bash
+➜ resources git:(docs-airgap-install) ✗ make
+kubectl get microvmmachinetemplates --all-namespaces -o jsonpath="{.items[*].spec.template.spec.kernel.image}"|tr -s '[[:space:]]' '\n' \
+ | sort | uniq | xargs -L 1 -I {} ./image-pull-push.sh {} docker-registry:5000
+
+5.10.77: Pulling from weaveworks-liquidmetal/flintlock-kernel
+Digest: sha256:5ef5f3f5b42a75fdb69cdd8d65f5929430f086621e61f00694f53fe351b5d466
+Status: Image is up to date for ghcr.io/weaveworks-liquidmetal/flintlock-kernel:5.10.77
+ghcr.io/weaveworks-liquidmetal/flintlock-kernel:5.10.77
+...5.10.77: digest: sha256:5ef5f3f5b42a75fdb69cdd8d65f5929430f086621e61f00694f53fe351b5d466 size: 739
+```
+
+## Airgap Install
+
+### Weave Gitops Enterprise
+At this stage you have in your private registry both the Helm charts and container images required to install Weave GitOps
+Enterprise. Now you are ready to install WGE from your private registry.
+
+Follow the instructions to install WGE with the following considerations:
+
+1. Adjust Helm Releases `spec.chart.spec.sourceRef` to tell Flux to pull Helm charts from your Helm repo.
+2. Adjust Helm Releases `spec.values` to use the container images from your private registry.
+
+An example of how it would look for Weave GitOps Enterprise is shown below.
+
+Expand to view example WGE manifest
+
+```yaml title="weave-gitops-enterprise.yaml" {21-24,32}
+---
+apiVersion: source.toolkit.fluxcd.io/v1beta2
+kind: HelmRepository
+metadata:
+ name: weave-gitops-enterprise-charts
+ namespace: flux-system
+spec:
+ interval: 1m
+ url: http://helm-repo-chartmuseum:8080
+---
+apiVersion: helm.toolkit.fluxcd.io/v2beta1
+kind: HelmRelease
+metadata:
+ name: weave-gitops-enterprise
+ namespace: flux-system
+spec:
+ chart:
+ spec:
+ chart: mccp
+ version: "0.10.2"
+ sourceRef:
+ kind: HelmRepository
+ name: weave-gitops-enterprise-charts
+ namespace: flux-system
+ interval: 1m0s
+ install:
+ crds: CreateReplace
+ remediation:
+ retries: 3
+ upgrade:
+ crds: CreateReplace
+ values:
+ global:
+ capiEnabled: true
+ enablePipelines: true
+ enableTerraformUI: true
+ clusterBootstrapController:
+ enabled: true
+ #images changed
+ cluster-controller:
+ controllerManager:
+ kubeRbacProxy:
+ image:
+ repository: localhost:5001/gcr.io/kubebuilder/kube-rbac-proxy
+ tag: v0.8.0
+ manager:
+ image:
+ repository: localhost:5001/docker.io/weaveworks/cluster-controller
+ tag: v1.4.1
+ policy-agent:
+ enabled: true
+ image: localhost:5001/weaveworks/policy-agent
+ pipeline-controller:
+ controller:
+ manager:
+ image:
+ repository: localhost:5001/ghcr.io/weaveworks/pipeline-controller
+ images:
+ clustersService: localhost:5001/docker.io/weaveworks/weave-gitops-enterprise-clusters-service:v0.10.2
+ uiServer: localhost:5001/docker.io/weaveworks/weave-gitops-enterprise-ui-server:v0.10.2
+ clusterBootstrapController: localhost:5001/weaveworks/cluster-bootstrap-controller:v0.4.0
+```
+
+
+
+### Cluster API
+
+Indicate in the Cluster API configuration file `clusterctl.yaml` that you want to use images from the private repo
+by leveraging [image overrides](https://cluster-api.sigs.k8s.io/clusterctl/configuration.html#image-overrides).
+
+```yaml
+images:
+ all:
+ repository: localhost:5001/registry.k8s.io/cluster-api
+ infrastructure-microvm:
+ repository: localhost:5001/ghcr.io/weaveworks-liquidmetal
+```
+Then execute `make clusterctl-init` to init capi using your private registry.
diff --git a/website/versioned_docs/version-0.29.0/enterprise/getting-started/install-enterprise.mdx b/website/versioned_docs/version-0.29.0/enterprise/getting-started/install-enterprise.mdx
new file mode 100644
index 0000000000..da4c3a9223
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/enterprise/getting-started/install-enterprise.mdx
@@ -0,0 +1,394 @@
+---
+title: Install Weave GitOps Enterprise
+hide_title: true
+pagination_next: enterprise/getting-started/releases-enterprise
+---
+
+import Tabs from "@theme/Tabs";
+import TabItem from "@theme/TabItem";
+import TierLabel from "@site/docs/_components/TierLabel";
+import CurlCodeBlock from "../../_components/CurlCodeBlock";
+import oauthBitbucket from '/img/oauth-bitbucket.png';
+import oauthAzureDevOps from '/img/oauth-azure-devops.png';
+import oauthAzureDevOpsSuccess from '/img/oauth-azure-devops-success.png';
+
+# Install Weave GitOps Enterprise
+
+:::info
+To purchase an entitlement to Weave GitOps Enterprise, please contact [sales@weave.works](mailto:sales@weave.works).
+:::
+
+Follow the instructions on this page to:
+
+import TOCInline from "@theme/TOCInline";
+
+ {
+ const trimStart = toc.slice(toc.findIndex((node) => node.id == 'install-weave-gitops-enterprise')+1);
+ return trimStart.slice(0, trimStart.findIndex((node) => node.level == '4'));
+ })()} />
+
+:::tip
+There is no need to install the open source version of Weave GitOps before installing Weave GitOps Enterprise.
+:::
+
+## Example: Set up a Management Cluster with CAPA and EKS
+
+To get you started, we'll cover EKS as our management cluster with the CAPA provider. Please note again that Weave GitOps Enterprise supports [clusters without Cluster API](../../cluster-management/managing-clusters-without-capi.mdx), as well as any combination of management cluster and CAPI provider.
+
+### Prep Step: Create a Repository
+Create a new private GitHub repository and give it a name. We'll call our repo `fleet-infra`.
+
+Set up a Git client for your private repo. For GitHub, see their docs on [setting your username](https://docs.github.com/en/get-started/getting-started-with-git/setting-your-username-in-git#setting-your-git-username-for-every-repository-on-your-computer) and [setting your email address](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/setting-your-commit-email-address#setting-your-email-address-for-every-repository-on-your-computer).
+
+[Cluster API](https://cluster-api.sigs.k8s.io/introduction.html) provides declarative APIs, controllers, and tooling to manage the lifecycle of Kubernetes clusters, across a large number of [infrastructure providers](https://cluster-api.sigs.k8s.io/reference/providers.html#infrastructure).
+The CAPI custom resource definitions are platform-independent as each provider implementation handles the creation of virtual machines,
+VPCs, networks, and other required infrastructure parts, enabling consistent and repeatable cluster deployments.
+
+The following example and steps reflect Flux’s architecture and operations. Go [here](https://fluxcd.io/docs/cmd/) for more detailed documentation about Flux.
+
+### 1. CAPA Setup
+
+Cluster API requires kubectl access to an existing Kubernetes cluster. For this example, configure kubectl to use the management cluster:
+
+```bash
+export KUBECONFIG=/path/to/kubeconfig
+```
+
+After having configured kubectl, deploy the CAPA components by following the [steps provided by Cluster API documentation](https://cluster-api-aws.sigs.k8s.io/getting-started.html#install-clusterctl).
+
+### 2. Prepare IAM for Installation
+
+Cluster API needs special permissions in AWS. Use the `clusterawsadm` command below to roll out a CloudStack and install the permissions into your AWS account. Although the CloudStack is bound to a region, the resulting permissions are globally scoped. You can use any AWS Region that you have access to.
+
+The `clusterawsadm` command takes an AWSIAMConfiguration file. [Cluster API docs provide the command](https://cluster-api-aws.sigs.k8s.io/topics/using-clusterawsadm-to-fulfill-prerequisites.html#with-eks-support) for you; run this.
+
+Run the `clusterawsadm` command to create an IAM group:
+
+```bash
+clusterawsadm bootstrap iam create-cloudformation-stack --config eks-config.yaml --region $REGION
+```
+
+Create an IAM User, which will be used as a kind of service account, and assign the newly created group to this user. The group name will be something like: `cluster-api-provider-aws-s-AWSIAMGroupBootstrapper-XXXX`.
+
+Create a secret for the newly created IAM user.
+
+### 3. Create the Cluster
+
+In testing, we used the following values:
+`$INSTANCESIZE` : t3.large
+`$NUMOFNODES` : 2
+`$MINNODES` : 2
+`$MAXNODES` : 6
+
+```bash
+eksctl create cluster -n "$CLUSTERNAME" -r "$REGION" --nodegroup-name workers -t $INSTANCESIZE --nodes $NUMOFNODES --nodes-min $MINNODES --nodes-max $MAXNODES --ssh-access --alb-ingress-access
+```
+
+### 4. Add the Cluster to kubeconfig
+
+Once you've created your cluster, add it to your `kubeconfig`:
+
+```bash
+aws eks --region "$REGION" update-kubeconfig --name "$CLUSTERNAME"
+```
+
+### 5. Install Flux Onto Your Cluster with the `flux bootstrap` Command
+
+The `flux bootstrap` command enables you to deploy Flux on a cluster the GitOps way. Go [here](https://fluxcd.io/docs/cmd/) for more information about the `flux bootstrap` command.
+
+
+
+
+```bash
+flux bootstrap github \
+ --owner= \
+ --repository=fleet-infra \
+ --branch=main \
+ --path=./clusters/management \
+ --personal \
+ --components-extra image-reflector-controller,image-automation-controller
+```
+
+
+
+
+
+```bash
+flux bootstrap gitlab \
+ --owner= \
+ --repository=fleet-infra \
+ --branch=main \
+ --path=./clusters/management \
+ --personal \
+ --components-extra image-reflector-controller,image-automation-controller
+```
+
+
+
+
+Your private GitHub repo should have a clusters/management folder that includes the manifests Flux needs to operate, and that also generates a key value pair for Flux to access the repo.
+
+* **owner**: The username (or organization) of the Git repository
+* **repository**: Git repository name
+* **branch**: Git branch (default "main")
+* **path**: Path relative to the repository root; when specified, the cluster sync will be scoped to this path
+* **personal**: If set, the owner is assumed to be a repo user
+* **components-extra**: Additional controllers to install
+
+At this point your Flux management cluster should be running. Take a look at the repository you created earlier.
+
+### 6. Install CAPA
+
+You do not need to install a CAPI provider to provision Kubernetes clusters using Weave GitOps Enterprise—you can also provision with Terraform. But for this example with CAPA, you must.
+
+Download a specific version of clusterctl from the [releases page](https://github.com/kubernetes-sigs/cluster-api/releases). We've tested the example templates provided in this guide with `clusterctl` version `1.1.3`.
+
+Next, run this command:
+
+```bash
+export EXP_EKS=true
+export EXP_MACHINE_POOL=true
+export CAPA_EKS_IAM=true
+export EXP_CLUSTER_RESOURCE_SET=true
+
+clusterctl init --infrastructure aws
+```
+
+Please note that, while the next few steps apply to our example, they are also relevant whether you're using another CAPI provider or none at all.
+
+## Apply the Entitlements Secret
+
+Contact sales@weave.works for a valid entitlements secret. Then apply it to the cluster:
+
+```bash
+kubectl apply -f entitlements.yaml
+```
+
+## Configure Access for Writing to Git from the Weave GitOps Enterprise UI
+
+Here we provide guidance for GitHub, GitLab, BitBucket Server, and Azure DevOps.
+
+
+
+GitHub requires no additional configuration for OAuth git access
+
+
+
+Create a GitLab OAuth application that will request `api` permissions to create pull requests on your behalf.
+
+Follow the [GitLab docs](https://docs.gitlab.com/ee/integration/oauth_provider.html).
+
+The application should have at least these scopes:
+
+- `api`
+- `openid`
+- `email`
+- `profile`
+
+Add callback URLs to the application for each address the UI will be exposed on, e.g.:
+
+- `https://localhost:8000/oauth/gitlab` for port-forwarding and testing
+- `https://git.example.com/oauth/gitlab` for production use
+
+Save your application, taking note of the **Client ID** and **Client Secret**. Save
+them into the `git-provider-credentials` secret, along with:
+
+- `GIT_HOST_TYPES` to tell WGE that the host is gitlab
+- `GITLAB_HOSTNAME` where the OAuth app is hosted
+
+**Replace values** in this snippet and run:
+
+```bash
+kubectl create secret generic git-provider-credentials --namespace=flux-system \
+ --from-literal="GITLAB_CLIENT_ID=13457" \
+ --from-literal="GITLAB_CLIENT_SECRET=24680" \
+ --from-literal="GITLAB_HOSTNAME=git.example.com" \
+ --from-literal="GIT_HOST_TYPES=git.example.com=gitlab"
+```
+
+
+
+
+Create a new [incoming application link](https://confluence.atlassian.com/bitbucketserver/configure-an-incoming-link-1108483657.html) from
+the BitBucket administration dashboard. You will be asked to enter a unique name and the redirect URL for the external application. The redirect URL
+should be set to `/oauth/bitbucketserver`. You will also need to select permissions for the application. The minimum set of
+permissions needed for WGE to create pull requests on behalf of users is `Repositories - Write`. An example of configuring these settings is shown below.
+
+
+
+
+Save your application and take note of the **Client ID** and **Client Secret**. Save
+them into the `git-provider-credentials` secret, along with:
+
+- `GIT_HOST_TYPES` to tell WGE that the host is bitbucket-server
+- `BITBUCKET_SERVER_HOSTNAME` where the OAuth app is hosted
+
+**Replace values** in this snippet and run:
+
+```bash
+kubectl create secret generic git-provider-credentials --namespace=flux-system \
+ --from-literal="BITBUCKET_SERVER_CLIENT_ID=13457" \
+ --from-literal="BITBUCKET_SERVER_CLIENT_SECRET=24680" \
+ --from-literal="BITBUCKET_SERVER_HOSTNAME=git.example.com" \
+ --from-literal="GIT_HOST_TYPES=git.example.com=bitbucket-server"
+```
+
+If the secret is already present, use the following command to update it using your default editor:
+
+```bash
+kubectl edit secret generic git-provider-credentials --namespace=flux-system
+```
+
+:::info
+
+If BitBucket Server is running on the default port (7990), make sure you include the port number in the values of the secret. For example: `GIT_HOST_TYPES=git.example.com:7990=bitbucket-server`
+
+:::
+
+
+
+
+
+Navigate to [VisualStudio](https://app.vsaex.visualstudio.com/app/register) and register a new application, as explained in the [docs](https://learn.microsoft.com/en-us/azure/devops/integrate/get-started/authentication/oauth?view=azure-devops#1-register-your-app). Set the authorization callback URL and select which scopes to grant. Set the callback URL to `/oauth/azuredevops`.
+
+Select the `Code (read and write)` scope from the list. This is necessary so that WGE can create pull requests on behalf of users. An example of configuring these settings is shown below.
+
+
+
+After creating your application, you will be presented with the application settings. Take note of the `App ID` and `Client Secret` values—you will use them to configure WGE.
+
+
+
+In your cluster, create a secret named `git-provider-credentials` that contains the `App ID` and `Client Secret` values from the newly created application.
+
+**Replace values** in this snippet and run:
+
+```bash
+kubectl create secret generic git-provider-credentials --namespace=flux-system \
+ --from-literal="AZURE_DEVOPS_CLIENT_ID=" \
+ --from-literal="AZURE_DEVOPS_CLIENT_SECRET="
+```
+
+WGE is now configured to ask users for authorization the next time a pull request must be created as part of using a template. Note that each user can view and manage which applications they have authorized by navigating to https://app.vsaex.visualstudio.com/me.
+
+
+
+
+
+## Configure Helm Chart and Commit
+
+We deploy WGE via a Helm chart. We'll save and adapt the below template before committing it in Git to a Flux-reconciled path.
+
+Clone the newly created repo locally. We're gonna add some things!
+
+```bash
+git clone git@:/fleet-infra
+cd fleet-infra
+```
+
+Download the helm-release to `clusters/management/weave-gitops-enterprise.yaml`.
+
+import ExampleWGE from "../../assets/example-enterprise-helm.yaml";
+import ExampleWGEContent from "!!raw-loader!../../assets/example-enterprise-helm.yaml";
+
+Expand to see file contents
+
+
+
+
+
+Once you have copied the above file, open and adjust the following configuration
+options:
+
+#### `values.config.capi.repositoryURL`
+Ensure this has been set to your repository URL.
+
+#### `values.config.capi.repositoryPath`
+By default, WGE will create new clusters in the `clusters/management/clusters` path.
+You can configure it with `values.config.capi.repositoryPath`.
+You might what to change it to `clusters/my-cluster/cluster` if you configured Flux to reconcile `./clusters/my-cluster` instead.
+
+#### `values.config.capi.repositoryClustersPath`
+The other important path to configure is where you'll store applications and workloads run on the new cluster.
+By default this is `./clusters`. When a new cluster is specified, any selected profiles will be written to `./clusters/{.namespace}/{.clusterName}/profiles.yaml`.
+When the new cluster is bootstrapped, Flux will sync the `./clusters/{.namespace}/{.clusterName}` path.
+
+#### (Optional) Install policy agent
+
+[Policy agent](../../policy/intro.mdx) comes packaged with the WGE chart. To install it, set the following values:
+
+- `values.policy-agent.enabled`: set to true to install the agent with WGE
+- `values.policy-agent.config.accountId`: organization name, used as identifier
+- `values.policy-agent.config.clusterId`: unique identifier for the cluster
+
+Commit and push all the files
+
+```bash
+git add clusters/management/weave-gitops-enterprise.yaml
+git commit -m "Deploy Weave GitOps Enterprise"
+git push
+```
+
+Flux will reconcile the helm-release and WGE will be deployed into the cluster. You can check the `flux-system` namespace to verify all pods are running.
+
+## Configure Your Password
+
+To login to the WGE UI, generate a bcrypt hash for your chosen password and store it as a secret in the Kubernetes cluster. There are several different ways to generate a bcrypt hash. Here, we'll use `gitops get bcrypt-hash` from our CLI.
+
+```bash
+PASSWORD=""
+echo -n $PASSWORD | gitops get bcrypt-hash | kubectl create secret generic cluster-user-auth -n flux-system --from-literal=username=wego-admin --from-file=password=/dev/stdin
+```
+
+A validation to know it’s working:
+
+```bash
+kubectl get secret -n flux-system cluster-user-auth
+```
+
+## Install the Weave GitOps Enterprise CLI Tool
+
+To do this, you can use either brew or curl.
+
+
+
+
+```bash
+brew install weaveworks/tap/gitops-ee
+```
+
+
+
+
+
+```bash
+curl --silent --location "https://artifacts.wge.dev.weave.works/releases/bin/0.27.0/gitops-$(uname)-$(uname -m).tar.gz" | tar xz -C /tmp
+sudo mv /tmp/gitops /usr/local/bin
+gitops version
+```
+
+
+
+
+## Next Steps
+
+Here are a couple of options for you to take your next steps with WGE. Explore one option or all of them, in no particular order.
+
+- [Cluster Management](https://docs.gitops.weave.works/docs/next/cluster-management/intro/): We'll show you how to join WGE to a cluster and install an application on that cluster *without* using Cluster API. But if you prefer using Cluster API, our docs cover that too.
+- Install the [Terraform Controller](https://weaveworks.github.io/tf-controller/) to reconcile your Terraform resources in a GitOps way. With Flux and the TF Controller, WGE makes it easy to add Terraform templates to your clusters and continuously reconcile any changes made to the Terraform source manifest.
+- Install [Policy agent](../../policy/intro.mdx), which comes packaged with the WGE chart.
diff --git a/website/versioned_docs/version-0.29.0/enterprise/getting-started/intro-enterprise.mdx b/website/versioned_docs/version-0.29.0/enterprise/getting-started/intro-enterprise.mdx
new file mode 100644
index 0000000000..f4cb3e9b63
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/enterprise/getting-started/intro-enterprise.mdx
@@ -0,0 +1,68 @@
+---
+title: Introduction to Weave GitOps Enterprise
+hide_title: true
+---
+import TierLabel from "../../_components/TierLabel";
+import Link from "@docusaurus/Link";
+
+# Weave GitOps Enterprise
+
+:::tip Ready for more GitOps?
+To purchase an entitlement to Weave GitOps Enterprise, please contact [sales@weave.works](mailto:sales@weave.works).
+:::
+
+Weave GitOps Enterprise provides ops teams with an easy way to assess the
+health of multiple clusters in a single place. It shows cluster information such as
+Kubernetes version and number of nodes and provides details about the GitOps operations
+on those clusters, such as Git repositories and recent commits. Additionally, it
+aggregates Prometheus alerts to assist with troubleshooting.
+
+If you have already purchased your entitlement, head to the [installation page](./install-enterprise.mdx).
+
+## Feature Breakdown
+
+In addition to the features in the OSS edition, Weave GitOps Enterprise
+offers the following capabilities, taking your delivery from simple Continuous Delivery to Internal Developer Platform:
+
+### :boat: [Cluster Fleet Management](../../cluster-management/cluster-management-intro.mdx)
+Weave GitOps Enterprise (WGE) simplifies cluster lifecycle management at scale—even massive scale. Through pull requests, which make every action recorded and auditable, WGE makes it possible for teams to create, update, and delete clusters across entire fleets. WGE further simplifies the process by providing both a user interface (UI) and a command line interface (CLI) for teams to interact with and manage clusters on-prem, across clouds, and in hybrid environments. WGE works with [Terraform](https://www.weave.works/blog/extending-gitops-beyond-kubernetes-with-terraform), [Crossplane](https://www.weave.works/blog/gitops-goes-beyond-kubernetes-with-weave-gitops-upbound-s-universal-crossplane), and any Cluster API provider.
+
+![WGE dashboard with cluster view](/img/wge-dashboard-dark-mode.png)
+
+### :closed_lock_with_key: [Trusted Application Delivery](../../policy/intro.mdx)
+Add policy as code to GitOps pipelines and enforce security and compliance,
+application resilience and coding standards from source to production.
+Validate policy conformance at every step in the software delivery pipeline:
+commit, build, deploy and run time.
+
+### :truck: [Progressive Delivery](../../progressive-delivery/progressive-delivery-flagger-install.mdx)
+Deploy into production environments safely using canary, blue/green deployment, and A/B
+strategies. Simple, single-file configuration defines success rollback. Measure Service Level Objectives (SLOs)
+using observability metrics from Prometheus, Datadog, New Relic, and others.
+
+### :infinity: [CD Pipelines](../../pipelines/pipelines-intro.mdx)
+Rollout new software from development to production.
+Environment rollouts that work with your existing CI system.
+
+### :factory_worker: [Team Workspaces](../../workspaces/intro.mdx)
+Allow DevOps teams to work seamlessly together with multi-tenancy,
+total RBAC control, and policy enforcement, with integration to enterprise IAM.
+
+### :point_up_2: [Self-Service Templates and Profiles](../../gitops-templates/intro.mdx)
+Component profiles enable teams to deploy standard services quickly,
+consistently and reliably. Teams can curate the profiles that are available
+within their estate ensuring there is consistency everywhere. Using GitOps
+it's easy to guarantee the latest, secure versions of any component are
+deployed in all production systems.
+
+### :sparkling_heart: Health Status and Compliance Dashboards
+Gain a single view of the health and state of the cluster and its workloads.
+Monitor deployments and alert on policy violations across apps and clusters.
+
+### :compass: Kubernetes Anywhere
+Reduce complexity with GitOps and install across all major target environments
+including support for on-premise, edge, hybrid, and multi-cloud Kubernetes clusters.
+
+### :bell: [Critical 24/7 Support](/help-and-support/)
+Your business and workloads operate around the clock, and so do we.
+Whenever you have a problem, our experts are there to help. We’ve got your back!
diff --git a/website/versioned_docs/version-0.29.0/enterprise/getting-started/releases-enterprise.mdx b/website/versioned_docs/version-0.29.0/enterprise/getting-started/releases-enterprise.mdx
new file mode 100644
index 0000000000..b2fa71b83c
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/enterprise/getting-started/releases-enterprise.mdx
@@ -0,0 +1,720 @@
+---
+title: Enterprise Releases
+hide_title: true
+---
+import TierLabel from "../../_components/TierLabel";
+
+# Releases
+
+:::info
+This page details the changes for Weave GitOps Enterprise and its associated components. For Weave GitOps OSS - please see the release notes on [GitHub](https://github.com/weaveworks/weave-gitops/releases).
+:::
+
+## v0.28.0
+2023-07-20
+
+### Highlights
+
+- This release drops the requirement to install cert-manager
+- Extends external secrets creation form to allow selecting multiple properties or all properties
+
+#### UI
+
+- Better support for organising your clusters and templates in the UI via namespaces
+- Better support for Azure and Bitbucket Repositories in the UI, you can now click through to Open Pull Requests from these providers
+- Dark Mode support for Policy Config
+
+#### Explorer
+
+- Adds support for Kubernetes Events
+
+### Dependency versions
+
+- weave-gitops v0.28.0
+- cluster-controller v1.5.2
+- cluster-bootstrap-controller v0.6.0
+- templates-controller v0.3.0
+- (optional) pipeline-controller v0.21.0
+- (optional) policy-agent v2.5.0
+- (optional) gitopssets-controller v0.13.4
+
+## v0.27.0
+2023-07-07
+
+### Highlights
+
+#### Explorer
+
+- Retries to make sure we're showing you the freshest data
+- Exports more metrics to enhance observability
+
+#### GitOpsSets
+
+- Config generator enabled by default! Include values from ConfigMaps and Secrets in your GitOpsSets
+
+#### UI
+
+- Dark mode enhancements
+- Consistent form styling
+
+### Dependency versions
+
+- weave-gitops v0.26.0
+- cluster-controller v1.5.2
+- cluster-bootstrap-controller v0.6.0
+- templates-controller v0.2.0
+- (optional) pipeline-controller v0.21.0
+- (optional) policy-agent v2.5.0
+- (optional) gitopssets-controller v0.13.4
+
+## v0.26.0
+2023-06-22
+
+### Highlights
+
+- Dark Mode is now available in WGE.
+- Added Prometheus metrics for all API endpoints.
+
+### Dependency versions
+
+- weave-gitops v0.26.0
+- cluster-controller v1.5.2
+- cluster-bootstrap-controller v0.6.0
+- templates-controller v0.2.0
+- (optional) pipeline-controller v0.21.0
+- (optional) policy-agent v2.5.0
+- (optional) gitopssets-controller v0.13.2
+
+## v0.25.0
+2023-06-08
+
+_Bug fixes_
+
+### Dependency versions
+
+- weave-gitops v0.25.1-rc.1
+- cluster-controller v1.5.2
+- cluster-bootstrap-controller v0.6.0
+- templates-controller v0.2.0
+- (optional) pipeline-controller v0.21.0
+- (optional) policy-agent v2.4.0
+- (optional) gitopssets-controller v0.12.0
+
+## v0.24.0
+2023-05-25
+
+### Highlights
+
+#### GitOpsSets
+
+- GitOpsSets can now generate from [Flux Image Automation](https://fluxcd.io/flux/components/image/)'s `ImagePolicy`. This allows you to include the latest version of an image in your templates, for example to keep a `Deployment` up to date.
+- Cross namespace support lands, create resources in multiple namespaces, they'll also be cleaned up properly via finalizers.
+- The **Sync** button in the UI now works correctly
+
+#### Profiles and Charts
+
+- You can now filter out the versions that will be shown from a HelmRepository when installing a chart via annotations:
+ - `"weave.works/helm-version-filter": "> 0.0.0"` to filter out rc releases
+ - `"weave.works/helm-version-filter": "> 1.0.0"` to filter any pre 1.0 releases
+ - `"weave.works/helm-version-filter": "> 3.0.0-0"` to filter any pre 3.0 releases but include rc releases
+
+#### Explorer
+- You could now navigate by filters and enabled full-text search.
+
+### Breaking Changes
+
+(none)
+
+### Known issues
+
+#### Explorer
+
+- Full-text search with terms including special characters like dashes (-) returns more results than expected by exact match term. For example, searching by term "flux-system" is treated as two terms: "flux" & "system" so returns the results for the joint of them. A fix for this will be part of the following releases.
+
+### Dependency versions
+
+- weave-gitops v0.24.0
+- cluster-controller v1.5.2
+- cluster-bootstrap-controller v0.6.0
+- templates-controller v0.2.0
+- (optional) pipeline-controller v0.21.0
+- (optional) policy-agent v2.3.0
+- (optional) gitopssets-controller v0.12.0
+
+## v0.23.0
+2023-05-12
+
+### Highlights
+
+#### Application Details
+
+- Health status is now displayed for Kubernetes built-in resources.
+
+#### Explorer
+- You could [configure the service account](https://docs.gitops.weave.works/docs/explorer/configuration/#authentication-and-authorization-for-collecting) to use for collecting resources.
+
+#### Templates
+
+- You can now provide a _Markdown_ description of a template. This will be rendered at the top of the Template page allowing template authors to provide clear instructions to their users on how to best fill in the values and complete any other required tests and checks.
+- Raw templates are more flexible and allow you to render resources which don't have an explicit `metadata.name` field.
+
+#### Cluster details
+
+- The cluster details page now shows a Cluster's Connectivity status, along with more details for _both_ GitopsClusters and CAPIClusters, including:
+ - Conditions
+ - Labels
+ - Annotations
+
+#### Explorer
+
+- When enabled [useQueryServiceBackend](https://docs.gitops.weave.works/docs/explorer/configuration/#setup) navigation from Clusters UI to Applications UI is not possible as Explorer does not yet support filtering.
+
+### Dependency versions
+
+- weave-gitops v0.23.0
+- cluster-controller v1.4.1
+- cluster-bootstrap-controller v0.6.0
+- templates-controller v0.2.0
+- (optional) pipeline-controller v0.21.0
+- (optional) policy-agent v2.3.0
+- (optional) gitopssets-controller v0.11.0
+
+
+
+## v0.22.0
+2023-04-27
+
+
+### Highlights
+
+#### Explorer
+
+- Explorer supports now Flux sources.
+- Applications UI and Sources UI could be configured to use Explorer backend to improve UI experience.
+- Explorer collector uses impersonation. Ensure you [configure collector](../../explorer/configuration.mdx/#authentication-and-authorization-for-collecting) for your leaf clusters.
+
+#### GitopsSets
+
+- Now supports correctly templating numbers and object chunks
+
+#### Cluster Bootstrapping
+
+- Don't wait for ControlPlane readiness to sync secrets, this allows secrets to be sync'd related to CNI or other early stage processes
+
+### Upgrade Notes (from the previous release)
+
+- Explorer: you should configure [collector service account](https://docs.gitops.weave.works/docs/explorer/configuration/#authentication-and-authorization-for-collecting) in your leaf clusters.
+
+### Known issues
+
+- Clusters page horizontally scrolls too much and status becomes unreadable for some fields
+
+### Dependency versions
+
+- weave-gitops v0.22.0
+- cluster-controller v1.4.1
+- cluster-bootstrap-controller v0.6.0
+- templates-controller v0.2.0
+- (optional) pipeline-controller v0.20.0
+- (optional) policy-agent v2.3.0
+- (optional) gitopssets-controller v0.9.0
+
+## v0.21.2
+2023-04-13
+
+### Highlights
+
+- See your gitopssets on leaf clusters in the UI
+- Fixed bug where gitopssets would not update ConfigMaps
+- View Open Pull requests button in the UI now allows you to select any GitRepository
+
+### Dependency versions
+
+- weave-gitops v0.21.2
+- cluster-controller v1.4.1
+- cluster-bootstrap-controller v0.5.0
+- templates-controller v0.1.4
+- (optional) pipeline-controller v0.20.0
+- (optional) policy-agent v2.3.0
+- (optional) gitopssets-controller v0.8.0
+
+## v0.20.0
+2023-03-30
+
+### Dependency versions
+
+- weave-gitops v0.20.0
+- cluster-controller v1.4.1
+- cluster-bootstrap-controller v0.5.0
+- templates-controller v0.1.4
+- (optional) pipeline-controller v0.20.0
+- (optional) policy-agent v2.3.0
+- (optional) gitopssets-controller v0.7.0
+
+## v0.19.0
+2023-03-16
+
+### Highlights
+
+#### UI
+
+- Gitopsssets come to the UI!
+
+### Dependency versions
+
+- weave-gitops v0.19.0
+- cluster-controller v1.4.1
+- cluster-bootstrap-controller v0.3.0
+- templates-controller v0.1.4
+- (optional) pipeline-controller v0.20.0
+- (optional) policy-agent v2.3.0
+- (optional) gitopssets-controller v0.6.0
+
+## v0.18.0
+2023-03-02
+### Highlights
+
+#### UI
+
+- See the logged in user's OIDC groups in the UI via the new User Profile page
+- Image Automation pages now show cluster information
+- See details about the configured promotion strategy for a pipeline
+- Log filtering by source and level for GitOps Run
+- See all Policy Configs listed in the UI
+
+#### GitopsSets
+
+- New `cluster` generator allows you to interact with the Weave GitOps Cluster inventory. GitOps Clusters that are added and removed to the inventory are reflected by the generator. That can be used to target for example to manage applications across a fleet of clusters.
+- Enhanced `gitRepository` generator can now scan directories and paths with the new `directory` option, which enables you to create for example dynamically Flux Kustomizations , based on your repository.
+- New `apiClient` generator allows you to query and endpoint, and provide data for your template.
+- Reconciliation metrics are now reported to the `/metrics` endpoint ready to be collected
+
+
+### Dependency versions
+
+- weave-gitops v0.18.0
+- cluster-controller v1.4.1
+- cluster-bootstrap-controller v0.3.0
+- templates-controller v0.1.3
+- (optional) pipeline-controller v0.20.0
+- (optional) policy-agent v2.3.0
+- (optional) gitopssets-controller v0.5.0
+
+## v0.17.0
+2023-02-16
+### Highlights
+
+This release contains dependency upgrades and bug fixes. For a larger list of updates, check out the [Weave GitOps v0.17.0](https://github.com/weaveworks/weave-gitops/releases/tag/v0.17.0) release.
+
+## v0.16.0
+2023-02-02
+### Highlights
+
+#### Create External Secrets via WGE UI
+- It's becoming easier to create new a external secret CR through the UI instead of writing the whole CR yaml.
+- The creation form will help users choose which cluster to deploy the External Secret to and which secret store to sync the secrets from.
+- It's all done in the GitOps way.
+
+#### Plan Button in Terraform
+- Adding **Add Plan** button in the terraform plan page to enable users to re-plan changes made.
+
+### Dependency versions
+
+- weave-gitops v0.16.0
+- cluster-controller v1.4.1
+- cluster-bootstrap-controller v0.3.0
+- templates-controller v0.1.2
+- (optional) pipeline-controller v0.14.0
+- (optional) policy-agent v2.2.0
+- (optional) gitopssets-controller v0.2.0
+
+### Breaking changes
+
+No breaking changes
+
+## v0.15.1
+2023-01-19
+### Highlights
+
+#### Multi Repository support. Weave GitOps Enterprise adapts and scales to your repository structure
+- Weave GitOps Enterprise, is now supporting via the WGE GUI the selection of the Git Repository. Enabling to scale and match the desired Git Repository structure.
+
+#### GitOps Templates
+- Supporting path for Profiles, enabling to set the path for profiles in the template to configure where in the directory the HelmRelease gets created.
+- Enhanced Enterprise CLI support for GitOps Templates.
+#### GitOps Templates CLI enhancements
+- Support for profiles in templates via CLI
+- ```gitops create template``` supporting ```--config``` allows you to read command line flags from a config file and ```--output-dir``` allows you to write files out to a directory instead of just stdout
+#### GitOpsSets in preview
+- GitOpsSets enable Platform Operators to have a single definition for an application for multiple environments and a fleet of clusters. A single definition can be used to generate the environment and cluster-specific configuration.
+- GitOpsSets has been released as a feature in preview of WGE. The Preview phase helps us to actively collect feedback and use cases, iterating and improving the feature to reach a level of maturity before we call it stable. Please contact us via [email](mailto:david.stauffer@weave.works) or [slack](https://join.slack.com/t/weave-community/shared_invite/zt-1nrm7dc6b-QbCec62CJ7qj_OUOtuJbrw) if you want to get access to the preview.
+
+
+
+### Minor fixes
+#### OIDC
+- Allows customising the requested scopes via config.oidc.customScopes: "email,groups,something_else"
+- Token refreshing is now supported
+
+
+### Dependency versions
+
+- weave-gitops v0.15.0
+- cluster-controller v1.4.1
+- cluster-bootstrap-controller v0.3.0
+- (optional) pipeline-controller v0.9.0
+- (optional) policy-agent v2.2.0
+
+### Breaking changes
+
+No breaking changes
+
+## v0.14.1
+2023-01-05
+### Highlights
+
+#### Secrets management
+- We are introducing new functionality into Weave GitOps Enterprise to help observe and manage secrets through external secrets operator (ESO). The new secrets UI will enable customers using ESO to observe and manage external secrets, as well as help them troubleshoot issues during their secrets creation and sync operations. In this release, we are including the ability to list all ExternalSecrets custom resources across multi-cluster environments. Users also will have the ability to navigate to each ExternalSecret and know the details of the secret, its sync status, and the last time this secret has been updated, as well as the latest events associated with the secret.
+
+#### Pipelines
+- Retry promotion on failure. Now if a promotion fails there is an automatic retry functionalty, you can configure the threshold and delay via the CLI.
+- Promotion webhook rate limiting. We enable now the configuration of the rate limit for the promotion webhooks.
+
+### Minor fixes
+#### Workspaces
+** [UI] "Tenant" ** is renamed to "Workspace" on details page.
+
+** [UI] Use time.RFC3339 ** format for all timestamps of the workspaces tabs.
+
+#### Other
+** [UI] Error notification boundary ** does not allow user to navigate away from the page.
+
+** [Gitops run] GitOps Run ** doesn't ask to install dashboard twice
+
+### Dependency versions
+
+- weave-gitops v0.14.1
+- cluster-controller v1.4.1
+- cluster-bootstrap-controller v0.3.0
+- (optional) pipeline-controller v0.9.0
+- (optional) policy-agent v2.2.0
+
+### Breaking changes
+
+No breaking changes
+
+## v0.13.0
+2022-12-22
+### Highlights
+
+#### GitOps Templates Path feature
+- GitOps templates now provide the capability to write resources to multiple
+ paths in the Git repository. This feature allows complex scenarios, like for
+ example creating a self-service for an application that requires an RDS
+ database. We’ve provided
+ [documentation](../../gitops-templates/repo-rendered-paths.mdx) which has a example.
+
+```yaml
+spec:
+ resourcetemplates:
+ - path: ./clusters/${CLUSTER_NAME}/definition/cluster.yaml
+ content:
+ - apiVersion: cluster.x-k8s.io/v1alpha4
+ kind: Cluster
+ metadata:
+ name: ${CLUSTER_NAME}
+ ...
+ - apiVersion: infrastructure.cluster.x-k8s.io/v1alpha4
+ kind: AWSCluster
+ metadata:
+ name: ${CLUSTER_NAME}
+ ...
+ - path: ./clusters/${CLUSTER_NAME}/workloads/helmreleases.yaml
+ content:
+ - apiVersion: helm.toolkit.fluxcd.io/v2beta1
+ kind: HelmRelease
+ metadata:
+ name: ${CLUSTER_NAME}-nginx
+ ...
+ - apiVersion: helm.toolkit.fluxcd.io/v2beta1
+ kind: HelmRelease
+ metadata:
+ name: ${CLUSTER_NAME}-cert-manager
+ ...
+```
+
+#### Workspace UI
+- Weave GitOps now provides a GUI for Workspaces.
+
+#### Enhanced Terraform Table in UI
+- Weave GitOps now provides more details on the Terraform inventory GUI page. Adding the type and identifier fields to the inventory table, plus filtering and a 'no data' message.
+
+#### Keyboard shortcuts for "port forwards" on GitOps Run
+- Weave GitOps now building and printing a list of set up port forwards.
+- Weave GitOps now opening the selected port forward URL on key press. Listening for keypress is performed with the `github.com/mattn/go-tty` package (other options required pressing Enter after a keypress, this catches just a single numeric keypress) and opening URLs with the `github.com/pkg/browser` package.
+
+#### Minor fixes
+**[UI] Notifications** Fixed provider page showing a 404.
+
+### Dependency versions
+
+- weave-gitops v0.13.0
+- cluster-controller v1.4.1
+- cluster-bootstrap-controller v0.3.0
+- (optional) pipeline-controller v0.8.0
+- (optional) policy-agent v2.2.0
+
+### Breaking changes
+
+No breaking changes
+
+## v0.12.0
+2022-12-09
+
+### Highlights
+
+**We highly recommend users of v0.11.0 upgrade to this version as it includes fixes for a number of UI issues.**
+
+#### GitOps Templates
+
+- Support to specify Helm charts inside the CRD, instead of annotations. We’ve
+ provided [documentation](../../gitops-templates/profiles.mdx) which has a example.
+
+```yaml
+spec:
+ charts:
+ items:
+ - chart: cert-manager
+ version: v1.5.3
+ editable: false
+ required: true
+ values:
+ installCRDs: ${CERT_MANAGER_INSTALL_CRDS}
+ targetNamespace: cert-manager
+ layer: layer-1
+ template:
+ content:
+ metadata:
+ labels:
+ app.kubernetes.io/name: cert-manager
+ spec:
+ retries: ${CERT_MANAGER_RETRY_COUNT}
+```
+
+- Ability to edit all fields now, including name/namespace
+
+#### Authentication with OIDC support
+Supporting custom OIDC groups claims for azure/okta integration
+Support for OIDC custom username and group claims:
+
+```yaml
+config
+ oidc:
+ claimUsername: ""
+ claimGroups: ""
+```
+
+#### Policy commit-time agent
+- Support Azure DevOps and auto-remediation in commit-time enforcement.
+
+#### Admin User- simpler RBAC
+- Weave GitOps default admin user can now “read” all objects. Why is this important? As users are trying out Weave GitOps they will most likely try it out with some of their favorite Cloud Native tools such as Crossplane, Tekton, Istio, etc. This enables them to see all of those resources and explore the full power of Weave GitOps. We still do not recommend this user for “production-use” cases, and customers should always be pushed towards implementing OIDC with scoped roles.
+
+#### Pipelines - adding Pipelines through Templates
+- From the Pipelines view you can add new Pipelines in a way which leverages GitOpsTemplates, additionally - to help users configure these, we’ve provided [documentation](../../pipelines/pipeline-templates.mdx) which has some samples.
+
+#### Support for multiple Flux instances on a single cluster
+- Support for running multiple flux instances in different namespaces on a single cluster for resource isolation.
+
+#### Minor fixes
+
+**Terraform CRD Error**
+Users of the Terraform Controller will be pleased to know we’ve addressed the issue where an error would be displayed if it had not been installed on all connected clusters.
+
+**Management cluster renaming**
+If the name of the cluster where Weave GitOps Enterprise is installed, was changed from the default of management through the config.cluster.name parameter, certain workflows could fail such as fetching profiles, this has now been resolved.
+
+### Dependency versions
+weave-gitops v0.12.0
+cluster-controller v1.4.1
+cluster-bootstrap-controller v0.3.0
+(optional) pipeline-controller v0.0.11
+(optional) policy-agent 2.1.1
+
+### Known issues
+- [UI] Notifications provider page shows a 404.
+
+## v0.11.0
+2022-11-25
+
+### Highlights
+
+#### GitOpsTemplates
+- We are working towards unifying CAPI and GitOps Templates under a single umbrella. For those already using CAPITemplates, we will ensure a smooth transition is possible by making use of a conversion hooks. There are some breaking changes for GitOpsTemplates as part of this transitionary period, so be sure to check the guidance under [Breaking Changes](#breaking-changes).
+- We now retain the ordering of parameters in the template instead of sorting them alphabetically. Providing to the author control in what sequence the parameters are rendered in the form and thus present a more logically grouped set of parameters to the end consumer.
+- You can control what
+ [delimiters](../../gitops-templates/supported-langs.mdx#custom-delimiters) you
+ want to use in a template. This provides flexibility for if you want to use
+ the syntax for dynamic functions like the [helper functions](../../gitops-templates/supported-langs.mdx#supported-functions-1) we support.
+
+#### Pipelines
+- This [feature](pipelines/pipelines-intro.mdx) is now enabled by default when you install the Weave GitOps Enterprise Helm Chart. You can toggle this with the `enablePipelines` flag.
+- GitOpsTemplates are a highly flexible way to create new resources - including Pipelines. We now provide a shortcut on the Pipelines table view to navigate you to Templates with the `weave.works/template-type=pipeline` label.
+
+#### Telemetry
+This release incorporates anonymous aggregate user behavior analytics to help us continuously improve the product. As an Enterprise customer, this is enabled by default. You can learn more about this [here](/feedback-and-telemetry#anonymous-aggregate-user-behavior-analytics).
+
+### Dependency versions
+- weave-gitops v0.11.0
+- cluster-controller v1.4.1
+- cluster-bootstrap-controller v0.3.0
+- (optional) pipeline-controller v0.0.11
+- (optional) policy-agent 2.1.1
+
+### Breaking changes
+
+#### GitOpsTemplates and CAPITemplates
+We are making these changes to provide a unified and intuitive self-service experience within Weave GitOps Enterprise, removing misleading and potentially confusing terminology born from when only Clusters were backed by Templates.
+
+**New API Group for the GitOpsTemplate CRD**
+- old: `clustertemplates.weave.works`
+- new: `templates.weave.works`
+
+After upgrading Weave GitOps Enterprise which includes the updated CRD:
+1. Update all your GitOpsTemplates in Git changing all occurrences of `apiVersion: clustertemplates.weave.works/v1alpha1` to `apiVersion: templates.weave.works/v1alpha1`.
+2. Commit, push and reconcile. They should now be viewable in the Templates view again.
+3. Clean up the old CRD. As it stands:
+ - `kubectl get gitopstemplate -A` will be empty as it is pointing to the old `clustertemplates.weave.works` CRD.
+ - `kubectl get gitopstemplate.templates.weave.works -A` will work
+To fix the former of the commands, remove the old CRD (helm does not do this automatically for safety reasons):
+ - `kubectl delete crd gitopstemplates.clustertemplates.weave.works`
+ - You may have to wait up to 5 minutes for your local kubectl CRD cache to invalidate, then `kubectl get gitopstemplate -A` should be working as usual
+
+**Template Profiles / Applications / Credentials sections are hidden by default**
+
+For both `CAPITemplates` and `GitopsTemplates` the default visibility for all sections in a template has been set to `"false"`. To re-enable profiles or applications on a template you can tweak the annotations
+
+```yaml
+annotations:
+ templates.weave.works/profiles-enabled: "true" # enable profiles
+ templates.weave.works/kustomizations-enabled: "true" # enable applications
+ templates.weave.works/credentials-enabled: "true" # enable CAPI credentials
+```
+
+**The default values for a profile are not fetched and included in a pull-request**
+
+Prior to this release WGE would fetch the default values.yaml for every profile installed and include them in the `HelmReleases` in the Pull Request when rendering out the profiles of a template.
+
+This was an expensive operation and occasionally led to timeouts.
+
+The new behaviour is to omit the values and fall back to the defaults included in the helm-chart. This sacrifices some UX (being able to see all the defaults in the PR and tweak them) to improve performance. **There should not be any final behaviour changes to the installed charts**.
+
+You can still view and tweak the `values.yaml` when selecting profiles to include on the "Create resource (cluster)" page. If changes are made here the updated values.yaml will be included.
+
+## v0.10.2
+2022-11-15
+
+### Highlights
+- Retain template parameter ordering.
+- Allow configuration of the delimiters in templates.
+- Add create a pipeline button.
+- add missing support for policy version v2beta2 to tenancy cmd.
+
+### Dependency versions
+- weave-gitops v0.10.2
+- cluster-controller v1.4.1
+- cluster-bootstrap-controller v0.3.0
+- (optional) policy-agent 2.1.1
+
+## v0.10.1
+2022-11-10
+
+### Highlights
+
+- Create non-cluster resources / Add Edit option to resources with create-request annotation
+- bump pipeline-controller
+- Parse annotations from template
+- Add cost estimate message if available
+- Adds support for showing policy modes and policy configs in the UI
+
+- Show suspended status on pipelines detail
+- YAML view for Pipelines
+- Align and link logo
+
+- Actually remove the watcher from the helm-watcher-cache
+- UI 1817 disable create target name space if name space is flux system
+
+- Adding edit capi cluster resource acceptance test
+- Add preview acceptance test
+
+### Dependency versions
+
+- weave-gitops v0.10.1
+- cluster-controller v1.4.1
+- cluster-bootstrap-controller v0.3.0
+- (optional) policy-agent 2.0.0
+
+
+## v0.9.6
+2022-10-17
+
+### Highlights
+- When adding applications, you can now preview the changes(PR) before creating a pull request
+- You can now see included Cluster Profiles when previewing your Create Cluster PR
+- Notifications are now available in the Notifications Page
+- You can now automatically create namespace when adding applications
+
+### Dependency versions
+
+- weave-gitops v0.9.6
+- cluster-controller v1.3.2
+- cluster-bootstrap-controller v0.3.0
+- (optional) policy-agent 1.2.1
+
+## v0.9.5
+2022-09-22
+
+### Highlights
+- **Tenancy**
+ - `gitops create tenant` now supports `--prune` to remove old resources from the cluster if you're not using `--export` with gitops.
+ - `deploymentRBAC` section in `tenancy.yaml` allows you to specify the permissions given to the flux `Kustomizations` that will apply the resources from git to your tenants' namespaces in the cluster.
+ - Support for `OCIRepository` sources when restricting/allowing the sources that can be applied into tenants' namespaces.
+- **Templates**
+ - Templates now support helm functions for simple transformations of values: `{{ .params.CLUSTER_NAME | upper }}`
+ - Templates has moved to its own page in the UI, this is the first step in moving towards embracing them as a more generic feature, not just for cluster creation.
+ - If a version is not specified in a **template profile annotation** it can be selected by the user.
+ - A `namespace` can be specified in the **template profile annotation** that will be provided as the `HelmRelease`'s `targetNamespace` by default.
+- **Bootstrapping**
+ - A ClusterBootstrapConfig can now optionally be triggered when `phase="Provisioned"`, rather than `ControlPlaneReady=True` status.
+
+### Dependency versions
+
+- weave-gitops v0.9.5
+- cluster-controller v1.3.2
+- cluster-bootstrap-controller v0.3.0
+- (optional) policy-agent 1.1.0
+
+### Known issues
+
+- [UI] Notifications page shows a 404 instead of the notification-controller's configuration.
+
+### ⚠️ Breaking changes from v0.9.4
+
+If using the policy-agent included in the weave-gitops-enterprise helm chart, the configuration should now be placed under the `config` key.
+
+**old**
+```yaml
+policy-agent:
+ enabled: true
+ accountId: "my-account"
+ clusterId: "my-cluster"
+```
+
+**new**
+```yaml
+policy-agent:
+ enabled: true
+ config:
+ accountId: "my-account"
+ clusterId: "my-cluster"
+```
diff --git a/website/versioned_docs/version-0.29.0/explorer/configuration.mdx b/website/versioned_docs/version-0.29.0/explorer/configuration.mdx
new file mode 100644
index 0000000000..862982c81f
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/explorer/configuration.mdx
@@ -0,0 +1,197 @@
+---
+title: Configuration
+hide_title: true
+---
+
+import TierLabel from "./../_components/TierLabel";
+import AlphaWarning from "../_components/_alpha_warning.mdx";
+
+# Configuration
+
+
+
+This page helps you to understand the options available to configure Explorer
+
+## Prerequisites
+Before using Explorer, please ensure that:
+- You have Weave Gitops Enterprise [v0.23.0](../enterprise/getting-started/releases-enterprise.mdx)
+
+## Setup
+
+The following configuration options are available for you to setup Explorer.
+
+- `.spec.values.enableExplorer`: feature flag to control whether Explorer is enabled.
+- `.spec.values.useQueryServiceBackend`: feature flag to control whether you want to leverage Explorer backend capabilities for
+other UI experiences like [Applications](../open-source/getting-started/ui-OSS.mdx#the-applications-view) or [Sources](../open-source/getting-started/ui-OSS.mdx#the-sources-view)
+- `.spec.values.explorer.collector.serviceAccount`: ServiceAccount `name` and `namespace` that explorer collector will use to impersonate
+in leaf clusters. Make sure you read [authz for collector](#Authentication_and_Authorization_for_collecting) before setting it. Default
+values are `name: collector`, `namespace: flux-system`.
+
+You should specify them in your HelmRelease values:
+
+```yaml
+---
+apiVersion: helm.toolkit.fluxcd.io/v2beta1
+kind: HelmRelease
+metadata:
+ name: weave-gitops-enterprise
+ namespace: flux-system
+spec:
+ # ... other spec components
+ values:
+ enableExplorer: true # feature flag to enable explorer
+ useQueryServiceBackend: true # uses explorer query backend in collection UIs
+ explorer:
+ collector:
+ serviceAccount: # service account that collector will impersonate in leaf clusters
+ name: collector
+ namespace: flux-system
+```
+
+## Configuration
+
+### Clusters
+
+Explorer watches the [GitopsClusters](../cluster-management/managing-clusters-without-capi.mdx/#connect-a-cluster)
+that you have connected to Weave Gitops Enterprise, as well as your Management cluster.
+
+### Kinds
+
+Explorer watches for the following kind resources out of the box:
+
+[Flux GitOps Toolkit](https://fluxcd.io/flux/components/)
+
+- [HelmRelease](https://fluxcd.io/flux/components/helm/helmreleases/)
+- [Kustomizations](https://fluxcd.io/flux/components/kustomize/kustomization/)
+- [Sources](https://fluxcd.io/flux/components/source/)
+ - [GitRepostiories](https://fluxcd.io/flux/components/source/gitrepositories/)
+ - [OciRepositories](https://fluxcd.io/flux/components/source/ocirepositories/)
+ - [HelmRepositories](https://fluxcd.io/flux/components/source/helmrepositories/)
+ - [HelmCharts](https://fluxcd.io/flux/components/source/helmcharts/)
+ - [Buckets](https://fluxcd.io/flux/components/source/buckets/)
+
+## Data Layer
+
+Explorer take a simple approach to manage resource views. It leverages a Data Store for caching the views and query them.
+The storage lifecycle is bounded to Weave Gitops Enterprise app and does not provide persistence guarantees.
+Instead, it requests data as required to the leaf clusters. In its simplest form, the data store used is [SQLite](https://sqlite.org/index.html).
+
+## Authentication and Authorization
+
+There are two main paths to consider within Explorer in the context of authentication and authorization (authN/authZ):
+
+1. The read or querying path is exercised when a weave gitops user queries the data.
+2. The write or collecting path is exercised to gather the resources from the leaf clusters.
+
+We look into them separately.
+
+## Authentication and Authorization for querying
+
+Explorer leverages existing authentication and authorization built-in the [application](https://docs.gitops.weave.works/docs/configuration/securing-access-to-the-dashboard/).
+It identifies for a user logged in the application: its identity and the access permissions via Kuberentes RBAC.
+Query results are filtered honouring the access determined via RBAC.
+
+## Authentication and Authorization for collecting
+
+[GitopsClusters](../cluster-management/managing-clusters-without-capi.mdx/#connect-a-cluster)
+define the connection and security context that Explorer leverages to collect data from leaf clusters. Given that you have followed the indications
+in [setup RBAC](../configuration/service-account-permissions.mdx), the GitopsCluster service account is able to impersonate any user or group.
+
+:::tip
+
+Collector RBAC resources are part of your leaf clusters common RBAC configuration. It is commonly
+located in your `clusters/bases` folder, as described in [Getting started](./getting-started.mdx).
+
+:::
+
+
+To configure collection, you would need to extend this configuration with the following:
+
+1. Create a ServiceAccount for the one that you specified in your [setup](#setup) `.spec.values.explorer.collector.serviceAccount`.
+
+Expand to see an example
+
+```yaml
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+ name: collector # should match .spec.values.explorer.collector.serviceAccount.name
+ namespace: flux-system # should match .spec.values.explorer.collector.serviceAccount.namespace
+```
+
+
+
+
+2. Create a ClusterRole with the permissions to watch the supported resources.
+
+Expand to see an example
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+ name: collector # could be .spec.values.explorer.collector.serviceAccount.name
+rules:
+ - apiGroups: [ "rbac.authorization.k8s.io" ]
+ resources: [ "roles", "clusterroles", "rolebindings", "clusterrolebindings" ]
+ verbs: [ "list", "watch" ]
+ - apiGroups: [ "kustomize.toolkit.fluxcd.io" ]
+ resources: [ "kustomizations" ]
+ verbs: [ "list", "watch" ]
+ - apiGroups: [ "helm.toolkit.fluxcd.io" ]
+ resources: [ "helmreleases" ]
+ verbs: [ "list", "watch" ]
+ - apiGroups: [ "source.toolkit.fluxcd.io" ]
+ resources: [ "buckets", "helmcharts", "gitrepositories", "helmrepositories", "ocirepositories" ]
+ verbs: [ "list", "watch" ]
+```
+
+
+
+3. Create a ClusterRolebinding to assign previous ClusterRole to the created collector `ServiceAccount`.
+
+Expand to see an example
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+ name: collector # could be .spec.values.explorer.collector.serviceAccount.name
+subjects:
+ - kind: ServiceAccount
+ name: collector # should match .spec.values.explorer.collector.serviceAccount.name
+ namespace: flux-system # should match .spec.values.explorer.collector.serviceAccount.namespace
+roleRef:
+ kind: ClusterRole
+ name: collector # name of the cluster role created earlier
+ apiGroup: rbac.authorization.k8s.io
+```
+
+
+
+If you want the collector to watch a particular namespace use a RoleBinding instead.
+
+4. Extend impersonation rules to allow service account impersonation for ServiceAccount `collector`
+
+Expand to see an example
+
+```yaml
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+ name: clusters-service-impersonator-role
+rules:
+ - apiGroups: [""]
+ resources: ["users", "groups"]
+ verbs: ["impersonate"]
+ - apiGroups: [ "" ]
+ resources: [ "serviceaccounts" ]
+ verbs: [ "impersonate" ]
+ resourceNames:
+ - "collector" # should match .spec.values.explorer.collector.serviceAccount.name
+```
+
+
+## Next Steps
+- See [querying](./querying.mdx) to deep dive in how to query.
+- See [operations](./operations.mdx) for day troubleshooting and operations.
diff --git a/website/versioned_docs/version-0.29.0/explorer/getting-started.mdx b/website/versioned_docs/version-0.29.0/explorer/getting-started.mdx
new file mode 100644
index 0000000000..e4297bbb35
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/explorer/getting-started.mdx
@@ -0,0 +1,56 @@
+---
+title: Getting started
+hide_title: true
+---
+
+import TierLabel from "./../_components/TierLabel";
+import AlphaWarning from "../_components/_alpha_warning.mdx";
+
+# Getting started
+
+
+
+This guide shows you the basics steps to start using Explorer.
+
+## Pre-requisites
+
+Before using Explorer, please ensure that:
+
+- You have Weave Gitops Enterprise [v0.23.0 or later version](../enterprise/getting-started/releases-enterprise.mdx)
+- You have deployed an application.
+
+## Setup
+
+Explorer is enabled via configuration through the feature flag `enableExplorer` that you could
+configure in your Weave Gitops Enterprise HelmRelease values:
+
+
+```yaml
+---
+apiVersion: helm.toolkit.fluxcd.io/v2beta1
+kind: HelmRelease
+metadata:
+ name: weave-gitops-enterprise
+ namespace: flux-system
+spec:
+ # ... other spec components
+ values:
+ enableExplorer: true
+```
+
+For a complete overview on the configuration you could see [configuration](./configuration.mdx).
+
+## Explorer UI
+
+Login to Weave Gitops and Explorer will be shown in the navigation menu `Explorer`.
+
+Explorer UI looks as follows:
+
+![explorer](imgs/explorer-open-new.png)
+
+It has two main components:
+
+- A search dialog with filter to querying the platform resources
+- A table with the filtered resources.
+
+For a more detailed view on the UI you could see [querying](./querying.mdx).
diff --git a/website/versioned_docs/version-0.29.0/explorer/imgs/debug-access-rules.png b/website/versioned_docs/version-0.29.0/explorer/imgs/debug-access-rules.png
new file mode 100644
index 0000000000..729465398a
Binary files /dev/null and b/website/versioned_docs/version-0.29.0/explorer/imgs/debug-access-rules.png differ
diff --git a/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-filter-terms.png b/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-filter-terms.png
new file mode 100644
index 0000000000..5725d243a1
Binary files /dev/null and b/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-filter-terms.png differ
diff --git a/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-intro.png b/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-intro.png
new file mode 100644
index 0000000000..2a59886bfd
Binary files /dev/null and b/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-intro.png differ
diff --git a/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-match.png b/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-match.png
new file mode 100644
index 0000000000..05966c8d71
Binary files /dev/null and b/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-match.png differ
diff --git a/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-multi-terms.png b/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-multi-terms.png
new file mode 100644
index 0000000000..78c0c0c01c
Binary files /dev/null and b/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-multi-terms.png differ
diff --git a/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-open-new.png b/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-open-new.png
new file mode 100644
index 0000000000..9219a2b10d
Binary files /dev/null and b/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-open-new.png differ
diff --git a/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-query-and.png b/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-query-and.png
new file mode 100644
index 0000000000..484f85eae6
Binary files /dev/null and b/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-query-and.png differ
diff --git a/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-query-filter-cluster.png b/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-query-filter-cluster.png
new file mode 100644
index 0000000000..0b67b8f36b
Binary files /dev/null and b/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-query-filter-cluster.png differ
diff --git a/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-query-filter-kind.png b/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-query-filter-kind.png
new file mode 100644
index 0000000000..2e70a83d66
Binary files /dev/null and b/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-query-filter-kind.png differ
diff --git a/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-query-metrics.png b/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-query-metrics.png
new file mode 100644
index 0000000000..f426d20761
Binary files /dev/null and b/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-query-metrics.png differ
diff --git a/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-query-overview.png b/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-query-overview.png
new file mode 100644
index 0000000000..ed99a33135
Binary files /dev/null and b/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-query-overview.png differ
diff --git a/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-ui.png b/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-ui.png
new file mode 100644
index 0000000000..d2f1b32d0b
Binary files /dev/null and b/website/versioned_docs/version-0.29.0/explorer/imgs/explorer-ui.png differ
diff --git a/website/versioned_docs/version-0.29.0/explorer/imgs/getting-started-failed.png b/website/versioned_docs/version-0.29.0/explorer/imgs/getting-started-failed.png
new file mode 100644
index 0000000000..e106373bdc
Binary files /dev/null and b/website/versioned_docs/version-0.29.0/explorer/imgs/getting-started-failed.png differ
diff --git a/website/versioned_docs/version-0.29.0/explorer/imgs/getting-started-querying-app.png b/website/versioned_docs/version-0.29.0/explorer/imgs/getting-started-querying-app.png
new file mode 100644
index 0000000000..4e6e41efbf
Binary files /dev/null and b/website/versioned_docs/version-0.29.0/explorer/imgs/getting-started-querying-app.png differ
diff --git a/website/versioned_docs/version-0.29.0/explorer/intro.mdx b/website/versioned_docs/version-0.29.0/explorer/intro.mdx
new file mode 100644
index 0000000000..7b694d68cf
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/explorer/intro.mdx
@@ -0,0 +1,42 @@
+---
+title: Introduction
+hide_title: true
+---
+
+import TierLabel from "./../_components/TierLabel";
+import AlphaWarning from "../_components/_alpha_warning.mdx";
+
+# Explorer
+
+
+
+As platform engineer or as developer, your applications and platform services will likely span multiple kubernetes clusters
+or infrastructure components. In order to manage and operate them you require a platform capability that
+allows you to discover the resources from a single place.
+
+Explorer is that capability that allows any platform user to discover platform resources from a single place
+across all your kubernetes clusters.
+
+![explorer](imgs/explorer-ui.png)
+
+## FAQ
+
+### Which journeys would be able to use explorer for?
+
+Explorer is better suited for journeys matching the discovery of resources across the platform resources inventory.
+
+### Which journeys would be better using other weave gitops capabilities for?
+
+If you have a particular resources you want to manage, weave gitops offers single resource experience
+for almost every resource.
+
+### Which Kinds does explorer support?
+
+Explorer support all Flux Applications and Sources CRDs
+
+See [Supported Kinds](../configuration#kinds) for more details.
+
+## Next Steps
+
+Now that you know what Explorer is, follow [getting started](../getting-started) to quickly have a feeling
+of what Explorer can do for you.
\ No newline at end of file
diff --git a/website/versioned_docs/version-0.29.0/explorer/operations.mdx b/website/versioned_docs/version-0.29.0/explorer/operations.mdx
new file mode 100644
index 0000000000..be36c233ad
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/explorer/operations.mdx
@@ -0,0 +1,255 @@
+---
+title: Operations
+hide_title: true
+toc_max_heading_level: 5
+
+---
+
+import TierLabel from "./../_components/TierLabel";
+import AlphaWarning from "../_components/_alpha_warning.mdx";
+
+# Operations
+
+
+
+As platform engineer you could need to have a finer understanding on the underlying logic for Explorer. The following
+options are available to you to operate and troubleshoot it.
+
+## Debug Access Rules
+
+It is a debugging tool to make visible explorer authorization logic. You could find it as tab `Access Rules` alongside
+the `Query` tab.
+
+![access rules](imgs/debug-access-rules.png)
+
+You could discover by `Cluster` and `Subject` the `Kinds` it is allowed to read. These are the rules that
+will be the source of truth doing authorization when a user does a query.
+
+## Monitoring
+
+Explorer provides the following telemetry to use for operations.
+
+### Metrics
+
+Explorer exports [Prometheus](https://prometheus.io/) metrics. Configuration happens during releasing as shown below.
+
+```yaml
+---
+apiVersion: helm.toolkit.fluxcd.io/v2beta1
+kind: HelmRelease
+metadata:
+ name: weave-gitops-enterprise
+ namespace: flux-system
+spec:
+ values:
+ #### Metrics - Prometheus metrics configuration
+ metrics:
+ # Enables metrics generation and prometheus endpoint
+ enabled: true
+ service:
+ # -- Port to start the metrics exporter on
+ port: 8080
+ # -- Annotations to set on the service
+ annotations:
+ prometheus.io/scrape: "true"
+ prometheus.io/path: "/metrics"
+ prometheus.io/port: "{{ .Values.metrics.service.port }}"
+```
+
+#### Querying
+
+Explorer querying path is composed of three components exporting metrics:
+
+- API server
+- Datastore Reads
+- Indexer Reads
+
+##### API Server
+
+Based on [go-http-metrics](https://github.com/slok/go-http-metrics/blob/master/metrics/prometheus/prometheus.go), the following
+metrics are generated.
+
+**Request Duration:** histogram with the latency of the HTTP requests.
+
+```
+http_request_duration_seconds_bucket{handler="/v1/query",method="POST",le="0.05"} 0
+http_request_duration_seconds_sum{handler="/v1/query",method="POST"} 10.088081923
+http_request_duration_seconds_count{handler="/v1/query",method="POST"} 51
+```
+
+**Response Size:** histogram with the size of the HTTP responses in bytes
+
+```
+http_response_size_bytes_bucket{handler="/v1/query",method="POST",le="0.05"} 10
+http_response_size_bytes_sum{handler="/v1/query",method="POST"} 120
+http_response_size_bytes_count{handler="/v1/query",method="POST"} 10
+```
+
+**Requests In Flight:** gauge with the number of inflight requests being handled at the same time.
+
+```
+http_requests_inflight{handler="/v1/query"} 0
+```
+
+##### Datastore Reads
+
+**Request Latency:** histogram with the latency of the datastore read requests.
+
+- `action` is the datastore read operation that could be either `GetObjects`, `GetAccessRules`, `GetObjectByID`, `GetRoles` or `GetRoleBindings`.
+- `status` is the result of the operation. It could be either read operation that could be either `success` or `error`.
+
+```
+datastore_latency_seconds_bucket{action="GetObjectByID", le="+Inf", status="success"} 1175
+datastore_latency_seconds_bucket{action="GetObjectByID", le="0.01", status="success"} 1174
+```
+```
+datastore_latency_seconds_count{action="GetObjectByID", status="success"} 1175
+datastore_latency_seconds_count{action="GetRoleBindings", status="success"} 47
+datastore_latency_seconds_count{action="GetRoles", status="success"} 47
+```
+```
+datastore_latency_seconds_sum{action="GetObjectByID", status="success"} 0.6924557999999995
+datastore_latency_seconds_sum{action="GetRoleBindings", status="success"} 1.329158916
+datastore_latency_seconds_sum{action="GetRoles", status="success"} 3.942473879999999
+```
+
+**Requests In Flight:** gauge with the number of inflight requests being handled at the same time.
+
+- `action` is the datastore read operation that could be either `GetObjects`, `GetAccessRules`, `GetObjectByID`, `GetRoles` or `GetRoleBindings`
+
+```
+datastore_inflight_requests{action="GetObjectByID"} 0
+datastore_inflight_requests{action="GetRoleBindings"} 0
+datastore_inflight_requests{action="GetRoles"} 0
+```
+
+##### Indexer Reads
+
+**Request Latency:** histogram with the latency of the indexer read requests.
+
+- `action` is the index read operation that could be either `ListFacets` or `Search`
+- `status` is the result of the operation. It could be either read operation that could be either `success` or `error`
+
+```
+indexer_latency_seconds_bucket{action="ListFacets", le="+Inf", status="success"} 1
+indexer_latency_seconds_bucket{action="Search", le="+Inf", status="success"} 47
+```
+```
+indexer_latency_seconds_sum{action="ListFacets", status="success"} 0.008928666
+indexer_latency_seconds_sum{action="Search", status="success"} 0.06231312599999999
+```
+```
+indexer_latency_seconds_count{action="ListFacets", status="success"} 1
+indexer_latency_seconds_count{action="Search", status="success"} 47
+```
+
+**Requests In Flight:** gauge with the number of inflight requests being handled at the same time.
+
+- `action` is the index read operation that could be either `ListFacets` or `Search`
+
+```
+indexer_inflight_requests{action="ListFacets"} 0
+indexer_inflight_requests{action="Search"} 0
+```
+
+#### Collecting
+
+Explorer collecting path is composed of three components exporting metrics:
+
+- Cluster Watcher Manager
+- Datastore Writes
+- Indexer Writes
+
+The following metrics are available to monitor its health.
+
+##### Cluster Watcher
+
+The metric `collector_cluster_watcher` provides the number of the cluster watchers it the following `status`:
+- Starting: a cluster watcher is starting at the back of detecting that a new cluster has been registered.
+- Started: cluster watcher has been started and collecting events from the remote cluster. This is the stable state.
+- Stopping: a cluster has been deregistered so its cluster watcher is no longer required. In the process of stopping it.
+- Failed: a cluster watcher has failed during the creation or starting process and cannot collect events from the remote clusters. This is the unstable state.
+
+Where `collector` is the type of collector, it could be
+- rbac: for collecting RBAC resources (ie roles)
+- objects: for collecting non-rbac resources (ie kustomizations)
+
+```
+collector_cluster_watcher{collector="objects", status="started"} 1
+collector_cluster_watcher{collector="objects", status="starting"} 0
+collector_cluster_watcher{collector="rbac", status="started"} 1
+collector_cluster_watcher{collector="rbac", status="starting"} 0
+```
+
+A sum on `collector_cluster_watcher` gives the total number of cluster watchers that should be equal to the number of clusters
+
+##### Datastore Writes
+
+**Request Latency:** histogram with the latency of the datastore write requests.
+
+- `action` is the datastore write operation that could be either `StoreRoles`, `StoreRoleBindings`, `StoreObjects`, `DeleteObjects`,
+`DeleteAllObjects`, `DeleteRoles`, `DeleteAllRoles`, `DeleteRoleBindings`, `DeleteAllRoleBindings`
+- `status` is the result of the operation. It could be either read operation that could be either `success` or `error`
+
+```
+datastore_latency_seconds_bucket{action="StoreRoles", le="+Inf", status="success"} 1175
+datastore_latency_seconds_bucket{action="StoreRoles", le="0.01", status="success"} 1174
+```
+
+```
+datastore_latency_seconds_count{action="StoreRoles", status="success"} 1175
+datastore_latency_seconds_count{action="DeleteRoles", status="success"} 47
+datastore_latency_seconds_count{action="DeleteAllRoleBindings", status="success"} 47
+```
+
+```
+datastore_latency_seconds_sum{action="StoreRoles", status="success"} 0.6924557999999995
+datastore_latency_seconds_sum{action="DeleteRoles", status="success"} 1.329158916
+datastore_latency_seconds_sum{action="DeleteAllRoleBindings", status="success"} 3.942473879999999
+```
+
+**Requests In Flight:** gauge with the number of inflight write requests being handled at the same time.
+
+- `action` is the datastore write operation that could be either `StoreRoles`, `StoreRoleBindings`, `StoreObjects`, `DeleteObjects`,
+`DeleteAllObjects`, `DeleteRoles`, `DeleteAllRoles`, `DeleteRoleBindings`, `DeleteAllRoleBindings`
+
+```
+datastore_inflight_requests{action="StoreRoles"} 0
+datastore_inflight_requests{action="StoreRoleBindings"} 0
+datastore_inflight_requests{action="DeleteAllRoleBindings"} 0
+```
+
+##### Indexer Writes
+
+**Request Latency:** histogram with the latency of the indexer write requests.
+
+- `action` is the index write operation that could be either `Add`, `Remove` or `RemoveByQuery`
+- `status` is the result of the operation. It could be either `success` or `error`
+
+```
+indexer_latency_seconds_bucket{action="Add",status="success",le="+Inf"} 109
+indexer_latency_seconds_bucket{action="Remove",status="success",le="+Inf"} 3
+```
+```
+indexer_latency_seconds_sum{action="Add",status="success"} 8.393912168
+indexer_latency_seconds_sum{action="Remove",status="success"} 0.012298476
+```
+```
+indexer_latency_seconds_count{action="Add",status="success"} 109
+indexer_latency_seconds_count{action="Remove",status="success"} 3
+```
+
+**Requests In Flight:** gauge with the number of inflight requests being handled at the same time.
+
+- `action` is the index write operation that could be either `Add`, `Remove` or `RemoveByQuery`
+
+```
+indexer_inflight_requests{action="Add"} 0
+indexer_inflight_requests{action="Remove"} 0
+```
+
+### Dashboard
+
+You could leverage [this grafana dashboard](../assets/dashboards/explorer.json) in Grafana to monitor its [golden signals](https://sre.google/sre-book/monitoring-distributed-systems/#xref_monitoring_golden-signals)
+
+![explorer](imgs/explorer-query-metrics.png)
diff --git a/website/versioned_docs/version-0.29.0/explorer/querying.mdx b/website/versioned_docs/version-0.29.0/explorer/querying.mdx
new file mode 100644
index 0000000000..e7b8596420
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/explorer/querying.mdx
@@ -0,0 +1,81 @@
+---
+title: Querying
+hide_title: true
+---
+
+import TierLabel from "./../_components/TierLabel";
+import AlphaWarning from "../_components/_alpha_warning.mdx";
+
+# Querying
+
+
+
+Explorer recommended way to discover resources is via its search dialog. This guide provides the background to understand
+it and set how to use it.
+
+## Schema
+
+Every resource is normalised to the following common schema:
+
+| __Key__ | __Description__ |
+| ----------------- | -------------- |
+| Cluster | Name of cluster where the resource exists. As gitops cluster ``|
+| Namespace | Namespace name where the resource exists.|
+| Kind | Resource kubernetes type or [kind](https://kubernetes.io/docs/reference/using-api/api-concepts/#standard-api-terminology)|
+| Name | Resource name as specified in its manifest.|
+| Status | Resource health status. Indicates the status of its reconciliation.|
+| Message | Resource health status message. It extends status field with information about the status.|
+
+For a `podinfo` helm release from a cluster `default/progress-delivery-demo2-32` like this:
+
+```yaml
+apiVersion: helm.toolkit.fluxcd.io/v2beta1
+kind: HelmRelease
+metadata:
+ name: podinfo
+ namespace: flux-system
+spec:
+ chart:
+ spec:
+ chart: podinfo
+ interval: 1m
+ reconcileStrategy: ChartVersion
+ sourceRef:
+ kind: HelmRepository
+ name: podinfo
+ version: 6.0.0
+ interval: 1m
+status:
+ conditions:
+ - message: Release reconciliation succeeded
+ reason: ReconciliationSucceeded
+ status: "True"
+ type: Ready
+```
+
+The schema looks like
+
+| Cluster | Namespace | Kind | Name | Status | Message |
+|------------| ---------| ----------------|---------|----------|------------------------|
+|`default/progress-delivery-demo2-32` | `flux-system` | `HelmRelease` | `podinfo` | `Success` | `Release reconciliation succeeded` |
+
+You can open the query filter settings by clicking on the filter button:
+
+![explorer](imgs/explorer-open-new.png)
+
+## Filtering and Searching
+
+The `Search` field allows for free-form text entry to query objects across all fields. For example, if we enter the term "podinfo", we will get matches for not only object names, but also strings from the `Message` field:
+
+![explorer-match](imgs/explorer-match.png)
+
+To filter the results by cluster, kind, namespace, enable the checkbox filters:
+
+
+![explorer match with filters](imgs/explorer-filter-terms.png)
+
+Note that the free-form terms only apply to the filtered results from the kind filter. In this case, we only match the "podinfo" string on results that are `Kustomizations`.
+
+We can also "OR" filters together. Note that filters within a category are OR'd together, but terms are AND'd across categories. For example, selecting the `Kind=Kustomization` and `Kind=HelmRelease` filters will show both `Kustomizations` and `HelmReleases`:
+
+![explorer with multiple filters](imgs/explorer-multi-terms.png)
diff --git a/website/versioned_docs/version-0.29.0/gitops-run/get-started.mdx b/website/versioned_docs/version-0.29.0/gitops-run/get-started.mdx
new file mode 100644
index 0000000000..1099016688
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/gitops-run/get-started.mdx
@@ -0,0 +1,306 @@
+---
+title: Tutorial
+hide_title: true
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# Get Started with GitOps Run
+
+GitOps Run supports two different modes of operation - directly on a
+cluster or as sandboxed sessions. The sandboxed sessions are intended
+for shared environments where multiple users are running their own
+sessions, whereas the direct mode is intended for a local cluster.
+
+In this tutorial we are going to use 'direct mode' to run GitOps on a local
+cluster.
+
+
+## Prerequisites
+### Required
+- Install the GitOps CLI. See [the installation](../open-source/getting-started/install-OSS.mdx#install-the-gitops-cli).
+
+### Optional
+- This guide uses [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) for demonstrations, but it is not required to use GitOps Run
+- The [Flux CLI](https://fluxcd.io/flux/installation/) is the quickest way to generate resource definitions, but the files can also be created manually
+
+## Create a local Kubernetes cluster
+
+To get started with GitOps Run, you need a Kubernetes cluster. There
+are many tools to set up a local cluster for test and development
+purposes.
+
+:::note
+This tutorial assumes you have full control of your cluster - we
+recommend a local cluster, but you can also use a remote cluster where
+you have full `cluster-admin` privileges.
+:::
+
+
+
+
+Install [kind](https://kind.sigs.k8s.io/docs/user/quick-start/) and run
+
+```bash
+kind create cluster
+```
+
+
+
+Install [k3d](https://k3d.io/) and run
+
+```bash
+k3d cluster create mycluster
+```
+
+
+
+Install [minikube](https://minikube.sigs.k8s.io/docs/start/) and run
+
+```bash
+minikube start
+```
+
+
+
+Install [Docker Desktop](https://www.docker.com/products/docker-desktop/) and enable Kubernetes. Then run
+
+```
+kubectl config set-context docker-desktop
+```
+
+
+
+GitOps Run works on any Kubernetes platform, but to avoid accidents
+you have to explicitly white-list the context name.
+
+First, find the name of the context where you want to run `gitops beta run` - in this example, there's a cluster with the name "dev":
+
+```bash
+$ kubectl config get-contexts
+CURRENT NAME CLUSTER AUTHINFO NAMESPACE
+* dev dev dev
+```
+
+Then, for any `gitops beta run` command in this guide, you'll have to add the flag `--allow-k8s-context=dev`
+
+
+
+Before you continue, make sure `kubectl get nodes` returns a node which is `Ready`.
+
+## Create a GitOps repository
+
+You need to set up a Git repository to put your GitOps manifests
+in. Any Git repository will do, for example create a new
+[github](https://github.com/new) repository and clone that.
+
+You may alternatively fork an existing repository, as we have done for this guide. Head
+to [podinfo](https://github.com/stefanprodan/podinfo) and create a fork with the
+name `podinfo-gitops-run`.
+
+## Set up GitOps Run
+
+To start GitOps Run, clone your newly created repository or fork and change into
+it.
+
+We will run the command with `--no-session` as it's a single user
+cluster which we want to use in direct mode. The port-forward points
+at the `podinfo` pod we will create later on.
+
+```bash
+export GITHUB_USER=
+
+# you can ignore these two commands if you already created and cloned your repository
+git clone git@github.com:$GITHUB_USER/podinfo-gitops-run.git
+
+cd podinfo-gitops-run
+gitops beta run ./podinfo --no-session --port-forward namespace=dev,resource=svc/dev-podinfo,port=9898:9898
+```
+
+You will now be asked if you want to install Flux and the GitOps
+[dashboard](../intro-weave-gitops.mdx). Answer `yes` and **set a password**.
+
+:::tip
+If you do not set a password, you won't be able to login to the GitOps UI
+:scream:.
+:::
+
+Shortly after you should be able to [open the dashboard](http://localhost:9001).
+The username is `admin` and the password will be the one you set above.
+
+In your dashboard you will be able to see what is in your cluster, including
+the resources that GitOps Run is operating.
+
+## Start modifying your deploment
+
+In your local GitOps repo, you will see that GitOps Run has created a new
+directory called `podinfo`. Inside there is a single, mostly empty, `kustomization.yaml`.
+
+To create the automation for the `podinfo` app, we first have to add the resources to
+run it - we'll create a new `Namespace`, a `HelmRepository` that
+references the Helm repository where the manifests are stored, and a
+`HelmRelease` that references the chart and version. We can use the
+`flux` CLI to generate the resource definition, or we can just create
+the yaml files ourselves.
+
+
+
+
+```bash
+cat < ./podinfo/namespace.yaml
+---
+apiVersion: v1
+kind: Namespace
+metadata:
+ name: dev
+EOF
+flux create source helm podinfo --url=https://stefanprodan.github.io/podinfo --namespace=dev --export > ./podinfo/podinfo-source.yaml
+flux create helmrelease podinfo --source=HelmRepository/podinfo --chart=podinfo --export --namespace=dev --target-namespace=dev > ./podinfo/podinfo-helmrelease.yaml
+```
+
+You should see three files now exist in your `./podinfo` directory.
+
+
+
+
+Save the contents of the following files to the `./podinfo` directory.
+
+./podinfo/namespace.yaml
+
+```yaml
+---
+apiVersion: v1
+kind: Namespace
+metadata:
+ name: dev
+```
+
+
+
+./podinfo/podinfo-source.yaml
+
+```yaml
+---
+apiVersion: source.toolkit.fluxcd.io/v1beta2
+kind: HelmRepository
+metadata:
+ name: podinfo
+ namespace: dev
+spec:
+ interval: 1m0s
+ url: https://stefanprodan.github.io/podinfo
+```
+
+
+
+./podinfo/podinfo-helmrelease.yaml
+
+```yaml
+---
+apiVersion: helm.toolkit.fluxcd.io/v2beta1
+kind: HelmRelease
+metadata:
+ name: podinfo
+ namespace: dev
+spec:
+ chart:
+ spec:
+ chart: podinfo
+ reconcileStrategy: ChartVersion
+ sourceRef:
+ kind: HelmRepository
+ name: podinfo
+ interval: 1m0s
+ targetNamespace: dev
+```
+
+
+
+
+
+
+The only remaining step is to import these files in the auto-generated
+`kustomization.yaml`. Open it up, and you should see the following:
+
+```yaml title="./podinfo/kustomization.yaml"
+---
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+resources: [] # 👋 Start adding the resources you want to sync here
+```
+
+Change the last line so it instead looks like the following:
+
+```yaml title="./podinfo/kustomization.yaml"
+---
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+// highlight-start
+resources:
+ - namespace.yaml
+ - podinfo-source.yaml
+ - podinfo-helmrelease.yaml
+// highlight-end
+```
+
+GitOps Run should now automatically upload these manifests and install
+them. The dashboard should show you how the resources are being
+reconciled, and when they're Ready you will be able to see podinfo
+[here](http://localhost:9898).
+
+
+## Update your app
+
+Now that GitOps Run is continuously watching and reconciling your
+local files onto your cluster, we can start modifying the resources.
+
+We're going to be modifying the `podinfo` we set up in the previous
+step. Open the current [podinfo](http://localhost:9898) and pay
+attention to the background color.
+
+Now, open your HelmRelease file and add the values at the bottom, as
+indicated:
+
+```yaml title="./podinfo/podinfo-helmrelease.yaml"
+---
+apiVersion: helm.toolkit.fluxcd.io/v2beta1
+kind: HelmRelease
+metadata:
+ name: podinfo
+ namespace: dev
+spec:
+ chart:
+ spec:
+ chart: podinfo
+ reconcileStrategy: ChartVersion
+ sourceRef:
+ kind: HelmRepository
+ name: podinfo
+ interval: 1m0s
+ targetNamespace: dev
+// highlight-start
+ values:
+ ui:
+ color: "#C32148"
+// highlight-end
+```
+
+When you hit save, you'll see GitOps Run upload new files, and once
+it's reconciled the `podinfo` background will have been changed to a bright red.
+
+## Next steps: GitOps Mode
+
+Now that we've used this interactive environment to set up the
+resources we want, we can switch over to full GitOps mode, where Flux
+is permanently pulling from your remote Git repository.
+
+Hit `ctrl-c` to stop GitOps Run. It will ask you whether you want to bootstrap
+your cluster into full GitOps mode. If you answer yes, it
+will take you through a wizard to help you set this up. You'll need information
+such as the remote repository, the branch name, etc.
+
+When you hit submit, it will set up the repository and branch, add
+Flux manifests, as well as the files you were just working on. From
+this point on, you can make persistent changes by pushing them to this
+repository.
diff --git a/website/versioned_docs/version-0.29.0/gitops-run/overview.mdx b/website/versioned_docs/version-0.29.0/gitops-run/overview.mdx
new file mode 100644
index 0000000000..e1e855d48e
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/gitops-run/overview.mdx
@@ -0,0 +1,74 @@
+---
+title: Overview
+hide_title: true
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# GitOps Run Overview
+
+## Introduction
+
+GitOps is a powerful mechanism for creating consistent environments and having
+multiple clusters stay in sync. If you build out your infrastructure correctly
+you get predictable behaviours for your teams and you can have new environments
+up and running quickly.
+
+However, GitOps can be challenging for the everyday developer
+to work with and it can create some friction, especially for developers who are
+less familiar with Kubernetes or Flux.
+
+The purpose of GitOps Run is to remove the complexity for developers so that
+platform operators can create developer environments easily, and application developers
+can benefit from GitOps and focus on writing code.
+
+Watch this video to learn more about how GitOps Run can help your team
+get started with GitOps:
+
+
+
+### Additional Benefits
+* No need to run `kubectl`, `helm`, `kustomize`, or `flux` CLI commands. Just create the manifests and we'll put them on the cluster for you.
+* Reduces the cycle time when configuring your cluster. With normal GitOps
+ there is a lot of commit/push/reconcile workflows that can be frustrating.
+ This skips that and you can test your changes directly before committing and
+ pushing code to your Git repository.
+* Multiple options for debugging Flux such as using the Dashboard that comes with Weave GitOps or getting live feedback by leveraging the [GitOps Tools for Flux](https://marketplace.visualstudio.com/items?itemName=Weaveworks.vscode-gitops-tools) VSCode extension.
+
+## Terminology
+
+### Modes
+
+#### GitOps:
+This is the default mode we are always aiming for when using Weave GitOps. Whenever GitOps Run
+is not active we want users to be in this mode. This means that the cluster is being driven by
+some mechanism reading from Git, ideally Flux, and that system is applying those changes
+to the cluster.
+
+#### Run:
+This is when the cluster has GitOps Run running on the cluster. There is a live reload session
+that is occurring and the cluster is no longer in a pure GitOps or Snowflake mode. Ideally, when
+GitOps Run stops running that the cluster enters into the GitOps mode that is defined above.
+
+#### Snowflake:
+We are referring to a cluster that is driven by some other mechanism outside of GitOps or Run.
+For example, a platform operator could have run various kubectl apply commands and installed
+a few helm charts using helm. The only way for this cluster to reach this state again is to
+rerun those commands or to transition to GitOps mode.
+
+### Sessions
+
+Weave GitOps Run can has two different ways of interacting with your cluster.
+
+#### Sandboxed
+
+This means we spin up a virtual cluster on your cluster creating a sandbox environment for your applications.
+What this means is that you are running this application in an isolated environment and it will not impact the
+rest of your cluster. When you are done and turn off GitOps Run we will then clean up the virtual cluster and
+everything that was installed on it. You can push your changes to Git and then our system will take care of
+pulling those changes onto the cluster.
+
+#### Cluster
+When you pass the `--no-session` flag when starting up GitOps Run this means we do not put those payloads in
+their own sandboxed environment. We will load them up directly into the cluster just as you would any other app.
diff --git a/website/versioned_docs/version-0.29.0/gitops-templates/annotations.mdx b/website/versioned_docs/version-0.29.0/gitops-templates/annotations.mdx
new file mode 100644
index 0000000000..95a4890f02
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/gitops-templates/annotations.mdx
@@ -0,0 +1,34 @@
+---
+title: Annotations
+hide_title: true
+---
+
+import TierLabel from "../_components/TierLabel";
+
+# Annotations
+
+## The `add-common-bases` annotation
+
+The `templates.weave.works/add-common-bases: "true"` annotation can be used to
+enable and disable the addition of a "common bases" `Kustomization` to the
+list of rendered files.
+This kustomization will sync a path that is common to all clusters (`clusters/bases`).
+
+An example usecase would be to ensure that certain RBAC or policies are applied
+to all clusters using this template.
+
+## The `inject-prune-annotation` annotation
+
+The `templates.weave.works/inject-prune-annotation: "true"` annotation can be used to
+enable and disable the injection of Flux's `prune` annotation into certain resources.
+
+When enabled, GitOps automatically injects a `kustomize.toolkit.fluxcd.io/prune: disabled`
+annotation into every resource in the `spec.resourcetemplates` that is **not** a
+`cluster.x-k8s.io.Cluster` and **not** a `gitops.weave.works.GitopsCluster`.
+
+The intention here is stop Flux from explicitly deleting subresources of the `Cluster` like
+`AWSCluster`, `KubeadmControlPlane`, `AWSMachineTemplate` etc and let the CAPI
+controllers handle their removal.
+
+This is the pattern recommended in the capi-quickstart guide https://cluster-api.sigs.k8s.io/user/quick-start.html#clean-up.
+
diff --git a/website/versioned_docs/version-0.29.0/gitops-templates/cli.mdx b/website/versioned_docs/version-0.29.0/gitops-templates/cli.mdx
new file mode 100644
index 0000000000..ca9231dc03
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/gitops-templates/cli.mdx
@@ -0,0 +1,109 @@
+---
+title: CLI
+hide_title: true
+---
+
+import TierLabel from "../_components/TierLabel";
+
+# Template CLI
+
+The Enterprise `gitops` CLI tool provides a set of commands to help you manage your templates.
+
+Here we're going to talk about the `gitops create template` command that allows
+you to render templates locally and airgapped, without a full WGE installation
+in a Kubernetes cluster.
+
+## Use cases
+
+- In CI/CD systems where you want to render a template and then use the raw output in a pipeline
+- For quickly debugging templates
+
+## Restrictions
+
+The `gitops create template` command only works with `GitOpsTemplate` objects.
+It does not work with `CAPITemplate` objects. You should be able to migrate any
+`CAPITemplate` objects to `GitOpsTemplate` with some small tweaks.
+
+:::info
+
+GitOpsTemplate or CAPITemplate?
+
+The only difference between `CAPITemplate` and `GitOpsTemplate` is the default
+value of these two annotations:
+
+| Annotation | default value for `CAPITemplate` | default value for `GitOpsTemplate` |
+| ----------- | ---------------- | ------------------ |
+| `templates.weave.works/add-common-bases` | `"true"` | `"false"` |
+| `templates.weave.works/inject-prune-annotations` | `"true"` | `"false"` |
+
+:::
+
+
+## Installation
+
+See the Weave Gitops Enterprise [installation instructions](../enterprise/getting-started/install-enterprise.mdx#7-install-the-cli) for details on how to install the EE `gitops` CLI tool.
+
+## Getting started
+
+Using a local `GitOpsTemplate` manifest with required parameters exported in the
+environment, the command can render the template to one of the following:
+1. The current kubecontext directly (default)
+1. stdout with `--export`
+1. The local file system with `--output-dir`, this will use the
+ `spec.resourcestemplates[].path` fields in the template to determine where to
+ write the rendered files.
+ This is the recommended approach for GitOps as you can then commit the
+ rendered files to your repository.
+
+```bash
+gitops create template \
+ --template-file capd-template.yaml \
+ --output-dir ./clusters/ \
+ --values CLUSTER_NAME=foo
+```
+
+## Profiles
+
+As in the UI you can add profiles to your template. However instead of reading
+the latest version of a profile and its layers from a `HelmRepository` object
+in the cluster, we instead read from your local helm cache.
+
+```bash
+helm repo add weaveworks-charts https://raw.githubusercontent.com/weaveworks/weave-gitops-profile-examples/gh-pages
+helm repo update
+```
+
+This particular helm repo provides a version of the `cert-manager` repo and others.
+
+### Supplying values to a profile
+
+You can supply a `values.yaml` file to a profile using the `values` parameter.
+For example we can supply `cert-manager`'s `values.yaml` with:
+
+```bash
+gitops create template \
+ --template-file capd-template.yaml \
+ --output-dir ./out \
+ --values CLUSTER_NAME=foo \
+ --profiles "name=cert-manager,namespace=foo,version=>0.1,values=cert-manager-values.yaml"
+```
+
+## Using a config file
+
+Instead of specifying the parameters on the command line you can supply a
+config file. For example the above invocation can be replaced like so:
+
+```yaml title=config.yaml
+template-file: capd-capi-template.yaml
+output-dir: ./out
+values:
+ - CLUSTER_NAME=foo
+profiles:
+ - name=cert-manager,namespace=foo,version=>0.1,values=cert-manager-values.yaml
+```
+
+and executed with:
+
+```bash
+gitops create template --config config.yaml
+```
diff --git a/website/versioned_docs/version-0.29.0/gitops-templates/create-cluster-example.mdx b/website/versioned_docs/version-0.29.0/gitops-templates/create-cluster-example.mdx
new file mode 100644
index 0000000000..b0d67e1151
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/gitops-templates/create-cluster-example.mdx
@@ -0,0 +1,33 @@
+---
+title: 'Example: Template to Create a CAPI Cluster'
+hide_title: true
+---
+
+import TierLabel from "../_components/TierLabel";
+
+# CAPI Cluster Template Example
+
+GitOps template objects need to be wrapped with the `GitOpsTemplate` custom
+resource and then loaded into the management cluster.
+
+```yaml
+apiVersion: templates.weave.works/v1alpha2
+kind: GitOpsTemplate
+metadata:
+ name: cluster-template-development
+ labels:
+ weave.works/template-type: cluster
+spec:
+ description: This is the std. CAPD template
+ renderType: templating
+ params:
+ - name: CLUSTER_NAME
+ description: This is used for the cluster naming.
+ resourcetemplates:
+ - apiVersion: cluster.x-k8s.io/v1alpha3
+ kind: Cluster
+ metadata:
+ name: "{{ .params.CLUSTER_NAME }}"
+```
+
+
diff --git a/website/versioned_docs/version-0.29.0/gitops-templates/creating-templates.mdx b/website/versioned_docs/version-0.29.0/gitops-templates/creating-templates.mdx
new file mode 100644
index 0000000000..5ce78ad37a
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/gitops-templates/creating-templates.mdx
@@ -0,0 +1,128 @@
+---
+title: Creating Templates
+hide_title: true
+---
+
+import TierLabel from "../_components/TierLabel";
+
+# Creating GitOpsTemplates
+
+:::tip
+
+For complete examples of widely-used templates, see the [Quickstart
+guide](../quickstart-templates).
+
+:::
+
+GitOps Templates were originally introduced to enable self-service operations
+for the the cluster creation workflow.
+
+We have since extended this capability to cover Terraform, Crossplane and
+general Kubernetes resources.
+
+An example template could, upon merging to a GitOps repository and reconciling in
+a cluster, provide a running developer environment consisting of
+an EKS cluster, an RDS database, and a branch and revision of the current
+application through single template.
+
+Templates can be loaded into the cluster by Platform Operator by adding them to
+the Flux-manage GitOps repository for the target cluster. Alternatively, they
+can be applied directly to the cluster with `kubectl`.
+
+:::info
+
+Weave GitOps will search for templates in the `default` namespace.
+This can be changed by configuring the `config.capi.namespace` value in the
+Weave GitOps Enterprise Helm Chart.
+
+:::
+
+
+## Template Type
+
+Template types are used by Weave GitOps to group the templates nicely in the
+Dashboard UI.
+
+There are 4 recommended template types:
+- `application` - for application templates
+- `cluster` - for cluster templates
+- `terraform` - for Terraform templates
+- `pipeline` - for Pipeline templates
+
+Declare this in the object manifest by using the `weave.works/template-type`
+label and setting the value as the name of the type.
+
+```yaml {7-8}
+---
+apiVersion: templates.weave.works/v1alpha2
+kind: GitOpsTemplate
+metadata:
+ name: example-template
+ namespace: default
+ labels:
+ weave.works/template-type: pipeline
+spec:
+# ...
+```
+
+## Template Components
+
+The rendering of certain component sections in a template can be enabled or
+disabled with annotations. The annotation keys are of the form
+`templates.weave.works/COMPONENT-enabled` and have `boolean` values.
+
+Supported components:
+- `profiles`
+- `kustomizations`
+- `credentials`
+
+Example:
+
+```yaml
+annotations:
+ templates.weave.works/profiles-enabled: "true"
+ templates.weave.works/kustomizations-enabled: "false"
+ templates.weave.works/credentials-enabled: "true"
+```
+
+## In-UI Template Editing
+
+When rendering a template, a `templates.weave.works/create-request` annotation
+is added by default to the first resource in the `resourcetemplates`.
+
+It can be added to any other resource by simply adding the annotation in empty form.
+This annotation holds information about which template generated the resource
+and the parameter values used as a json string.
+
+If the resource type is one of the following and has this annotation, an
+`Edit resource` button will appear in the GitOps UI which allows the editing of
+the resource by users, after which it will be re-rendered:
+- Applications:
+ - `HelmRelease`
+ - `Kustomization`
+- Sources:
+ - `HelmRepository`
+ - `GitRepository`
+- Clusters:
+ - `GitopsCluster`
+
+Example:
+```yaml {10,14}
+spec:
+ resourcetemplates:
+ - apiVersion: v1
+ kind: ConfigMap
+ metadata:
+ name: my-configmap
+ data:
+ my-key: my-value
+ - apiVersion: source.toolkit.fluxcd.io/v1beta1
+ kind: HelmRepository
+ metadata:
+ # This annotation will add an `Edit resource` button in the UI for this resource
+ annotations:
+ templates.weave.works/create-request: ''
+ name: nginx
+ namespace: default
+```
+
diff --git a/website/versioned_docs/version-0.29.0/gitops-templates/imgs/quickstart-templates-deployed.png b/website/versioned_docs/version-0.29.0/gitops-templates/imgs/quickstart-templates-deployed.png
new file mode 100644
index 0000000000..8cc86d6fc2
Binary files /dev/null and b/website/versioned_docs/version-0.29.0/gitops-templates/imgs/quickstart-templates-deployed.png differ
diff --git a/website/versioned_docs/version-0.29.0/gitops-templates/imgs/quickstart-templates-view.png b/website/versioned_docs/version-0.29.0/gitops-templates/imgs/quickstart-templates-view.png
new file mode 100644
index 0000000000..f38d1bc413
Binary files /dev/null and b/website/versioned_docs/version-0.29.0/gitops-templates/imgs/quickstart-templates-view.png differ
diff --git a/website/versioned_docs/version-0.29.0/gitops-templates/intro.mdx b/website/versioned_docs/version-0.29.0/gitops-templates/intro.mdx
new file mode 100644
index 0000000000..0f3f9ed061
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/gitops-templates/intro.mdx
@@ -0,0 +1,45 @@
+---
+title: Introduction
+hide_title: true
+---
+
+import TierLabel from "../_components/TierLabel";
+
+# Introduction
+
+A `GitOpsTemplate` enables application developers to self-service components and
+services easily through the Weave GitOps Dashboard. It's a simple YAML file that you can enrich with parameters, variables,
+metadata, and conditions.
+
+Use a `GitOpsTemplate` to template any resource that can be expressed in YAML
+(basic Kubernetes resources, Flux primitives, Terraform controller, Crossplane, Cluster API, etc.)
+into a standardised definition.
+
+Application developers can use a template through our GUI. The rendered
+template is added to their GitOps repository via a pull request. When merged and reconciled, the resources in
+the template are created. A resource can be a `MachinePool` for
+CAPI objects, a Flux Kustomization, or a Terraform Controller resource, to name a few examples.
+
+:::tip
+
+A `GitOpsTemplate` must be valid `yaml`. Beyond
+this, a rendered template can create any resource you need :sparkles:.
+
+:::
+
+![quickstart templates view](imgs/quickstart-templates-view.png)
+
+:::info
+
+GitOpsTemplate or CAPITemplate?
+
+The only difference between `CAPITemplate` and `GitOpsTemplate` is the default
+value of these two annotations:
+
+| Annotation | default value for `CAPITemplate` | default value for `GitOpsTemplate` |
+| ----------- | ---------------- | ------------------ |
+| `templates.weave.works/add-common-bases` | `"true"` | `"false"` |
+| `templates.weave.works/inject-prune-annotations` | `"true"` | `"false"` |
+
+:::
+
diff --git a/website/versioned_docs/version-0.29.0/gitops-templates/params.mdx b/website/versioned_docs/version-0.29.0/gitops-templates/params.mdx
new file mode 100644
index 0000000000..89f524fdb8
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/gitops-templates/params.mdx
@@ -0,0 +1,50 @@
+---
+title: Parameters
+hide_title: true
+---
+
+import TierLabel from "../_components/TierLabel";
+
+# Parameters
+
+When users have chosen a template, they will be presented with a form to
+complete.
+
+This form will collect the specific resource configuration which they would like
+applied to their instance.
+
+Resource variables, or parameters, are set by the template author in the
+template object manifest under `spec.params`.
+
+## Required params
+
+Some params are **required** for all resources as they will be used to generate
+paths for the eventually rendered resources.
+
+These are:
+- `CLUSTER_NAME`
+- `RESOURCE_NAME`
+
+## Parameters metadata
+
+The following metadata fields can be added for each parameter under
+`spec.params`. These will get rendered nicely in the UI form allowing users to understand
+what each field is for.
+
+- `name`: The variable name within the resource templates.
+- `description`: Description of the parameter. This will be rendered in both the UI
+ and CLI.
+- `options`: The list of possible values this parameter can be set to.
+- `required` - Whether the parameter must contain a non-empty value.
+- `default` - Default value of the parameter.
+
+Example:
+```yaml
+spec:
+ params:
+ - name: IP_ADDRESS
+ description: 'The IP address of this service'
+ options: [1.2.3.4, 5.6.7.8]
+ default: 1.2.3.4
+```
+
diff --git a/website/versioned_docs/version-0.29.0/gitops-templates/profiles.mdx b/website/versioned_docs/version-0.29.0/gitops-templates/profiles.mdx
new file mode 100644
index 0000000000..77a4e6d06d
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/gitops-templates/profiles.mdx
@@ -0,0 +1,109 @@
+---
+title: Profiles
+hide_title: true
+---
+
+import TierLabel from "../_components/TierLabel";
+
+# Adding Profiles to Templates
+
+Profiles are enhanched Helm Charts which allow operators to make additional
+components either optional or required to developers using self-service
+templates.
+
+Default and required profiles can be added via the template `spec.charts` section.
+
+```yaml
+spec:
+ charts:
+ items:
+ - name: nginx
+ version: 1.0.0
+ targetNamespace: nginx
+ - name: cert-manager
+ targetNamespace: cert-manager
+```
+
+A template with the above profiles would offer Application Developers the option
+to add `nginx` and `cert-manager` resources to their templated resources, ready
+for deployment to their cluster.
+
+## Profile Operator Settings
+
+Keys available in the `spec.charts` section and the template variables available to them.
+
+| **Key** | **Description** | **Template vars** |
+| ----------------------------- | -------------------------------------------- | ----------------- |
+| `helmRepositoryTemplate.path` | Path the `HelmRepository` will be written to | `params` |
+| `items` | list of charts to configure, see below | |
+
+Keys available in the `spec.charts.items` entries and the template variables available to them.
+
+| **Key** | **Description** | **Template vars** |
+| ------------------ | ---------------------------------------------------------------------- | ----------------- |
+| `template.content` | Full or partial `HelmRelease` CR template | `params` |
+| `template.path` | Path the HelmRelease will be written to | `params` |
+| `chart` | Shortcut to `HelmRelease.spec.chart.spec.chart` | |
+| `version` | Shortcut to `HelmRelease.spec.chart.spec.version` | |
+| `targetNamespace` | Shortcut to `HelmRelease.spec.targetNamespace` | |
+| `values` | Shortcut to `HelmRelease.spec.values` | `params` |
+| `layer` | Layer to install as | |
+| `required` | (default=false) Allow the user to de-select this profile |
+| `editable` | (default=false) Allow the user to edit the values.yaml of this profile |
+
+Expand for a complete yaml example
+
+```yaml
+spec:
+ charts:
+ helmRepositoryTemplate:
+ path: clusters/${CLUSTER_NAME}/helm-repositories.yaml
+ items:
+ - chart: cert-manager
+ version: v1.5.3
+ editable: false
+ required: true
+ values:
+ installCRDs: ${CERT_MANAGER_INSTALL_CRDS}
+ targetNamespace: cert-manager
+ layer: layer-1
+ template:
+ path: clusters/${CLUSTER_NAME}/cert-manager.yaml
+ content:
+ metadata:
+ labels:
+ app.kubernetes.io/name: cert-manager
+ spec:
+ retries: ${CERT_MANAGER_RETRY_COUNT}
+```
+
+:::tip
+
+`template.content` will be merged over the top of a default `HelmRelease` CR so it does not need to be complete.
+
+:::
+
+
+
+## Declaring Profiles with Annotations
+
+:::caution Deprecated feature
+
+Where possible please use the `spec.charts` section as detailed above to declare profiles.
+
+:::
+
+Profiles can also be included within templates by the
+`capi.weave.works/profile-INDEX` annotation.
+
+```yaml
+annotations:
+ capi.weave.works/profile-0: '{"name": "NAME", "version": "VERSION", "editable": EDITABLE, "namespace": "NAMESPACE"}'
+```
+
+Where:
+
+- `name` - is the name of the profile in the default profiles repository
+- `version` - (optional) will choose the default version
+- `namespace` - (optional) is the default target namespace for the profile
+- `editable` - (optional, default=`false`), allow the user to de-select this profile, making it a default instead of a requirement.
diff --git a/website/versioned_docs/version-0.29.0/gitops-templates/quickstart-templates.mdx b/website/versioned_docs/version-0.29.0/gitops-templates/quickstart-templates.mdx
new file mode 100644
index 0000000000..cf787813d1
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/gitops-templates/quickstart-templates.mdx
@@ -0,0 +1,106 @@
+---
+title: Quickstart
+hide_title: true
+---
+
+import Link from "@docusaurus/Link";
+import TierLabel from "../_components/TierLabel";
+
+# Quickstart GitOps Templates
+
+`Quickstart` templates are [`GitOpsTemplate`s](https://docs.gitops.weave.works/docs/gitops-templates/templates/)
+that you could use when getting started with [Weave Gitops Enterprise](../enterprise/getting-started/intro-enterprise.mdx)
+It aims to provide a simplified basic experience.
+
+## Getting Started
+
+The templates exist as a Helm Chart in the [weave-gitops-quickstart](https://github.com/weaveworks/weave-gitops-quickstart)
+github repo.
+
+To get started, add the following `HelmRelease` object to your Weave GitOps Enterprise
+configuration repo for your management cluster.
+
+Expand to view
+
+```yaml
+---
+apiVersion: source.toolkit.fluxcd.io/v1beta2
+kind: GitRepository
+metadata:
+ name: weave-gitops-quickstart
+ namespace: flux-system
+spec:
+ interval: 10m0s
+ ref:
+ branch: main
+ url: https://github.com/weaveworks/weave-gitops-quickstart
+---
+apiVersion: helm.toolkit.fluxcd.io/v2beta1
+kind: HelmRelease
+metadata:
+ name: quickstart-templates
+ namespace: flux-system
+spec:
+ chart:
+ spec:
+ chart: "quickstart-templates"
+ version: ">=0.1.0"
+ sourceRef:
+ kind: GitRepository
+ name: weave-gitops-quickstart
+ namespace: flux-system
+ interval: 10m0s
+```
+
+
+
+Commit and merge the above file. Once the `HelmRelease` has been successfully
+deployed to your cluster, navigate to your Weave GitOps UI Dashboard. You will
+see that the `templates` Chart is now deployed to your cluster.
+
+![quickstart templates deployed](imgs/quickstart-templates-deployed.png)
+
+If you click on the `Templates` tab in the sidebar, you will see the Quickstart
+templates are now available for use:
+
+![quickstart templates view](imgs/quickstart-templates-view.png)
+
+## Available Templates
+
+The following [pipeline](../pipelines/pipeline-templates.mdx) templates have
+been made available on your Weave GitOps Enterprise instance:
+
+- `pipeline-view`: A template to create a sample pipeline to visualize a
+ `HelmRelease` application delivered to dev, test and prod environments.
+- `pipeline-promotion-resources`: A template to create the Flux Notification
+ Controller resources required for promoting applications via pipelines.
+- `pipeline-view-promote-by-cluster`: A template to create pipelines for hard
+ tenancy when applications are isolated by cluster.
+- `pipeline-view-promote-by-namespace`: A template to create pipelines for soft
+ tenancy when applications are isolated by namespace.
+
+## Using `GitOpsTemplate`s as a Platform Engineer
+
+The above Quickstart templates are designed to provide a practical getting started
+experience. We encourage Platform Operators to start off with these templates
+within their team to ramp up on using Weave GitOps.
+
+If the need arises later, operators can always expand on these templates to
+develop their own set of self-service capabilities.
+
+## Using `GitOpsTemplate`s as an Application Developer
+
+As a developer using Weave GitOps Enterprise, use the templates to explore
+GitOps's capabilities. For example, to create a pipeline for your application:
+use the above template provided by your Operations team to create required
+resources. Once they have been added to your GitOps repository, you can adapt
+the rendered resources to meet your needs.
+
+:::tip Want to contribute?
+
+The Quickstart templates are maintained by the Weave Gitops team. If you would
+like to make alterations, suggest fixes, or even contribute a new template which
+you find cool, just head to the [repo](https://github.com/weaveworks/weave-gitops-quickstart)
+and open a new issue or PR!
+
+:::
diff --git a/website/versioned_docs/version-0.29.0/gitops-templates/repo-rendered-paths.mdx b/website/versioned_docs/version-0.29.0/gitops-templates/repo-rendered-paths.mdx
new file mode 100644
index 0000000000..cb3f3d7866
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/gitops-templates/repo-rendered-paths.mdx
@@ -0,0 +1,121 @@
+---
+title: Rendered Template Paths
+hide_title: true
+---
+
+import TierLabel from "../_components/TierLabel";
+
+# Rendered Template Paths
+
+Template authors can configure the eventual locatation of the rendered template
+in the user's GitOps repository.
+
+This allows for more control over where different resources in the template are rendered.
+
+## Configuring Paths
+
+The path for rendered resources is configured via the
+`spec.resourcetemplates[].path` field.
+
+:::tip Important to note:
+- The path is relative to the repository root
+- The path can be templated using params
+:::
+
+Expand to see example
+
+```yaml
+spec:
+ resourcetemplates:
+ // highlight-next-line
+ - path: clusters/${CLUSTER_NAME}/definition/cluster.yaml
+ content:
+ - apiVersion: cluster.x-k8s.io/v1alpha4
+ kind: Cluster
+ metadata:
+ name: ${CLUSTER_NAME}
+ ...
+ - apiVersion: infrastructure.cluster.x-k8s.io/v1alpha4
+ kind: AWSCluster
+ metadata:
+ name: ${CLUSTER_NAME}
+ ...
+ // highlight-next-line
+ - path: clusters/${CLUSTER_NAME}/workloads/helmreleases.yaml
+ content:
+ - apiVersion: helm.toolkit.fluxcd.io/v2beta1
+ kind: HelmRelease
+ metadata:
+ name: ${CLUSTER_NAME}-nginx
+ ...
+ - apiVersion: helm.toolkit.fluxcd.io/v2beta1
+ kind: HelmRelease
+ metadata:
+ name: ${CLUSTER_NAME}-cert-manager
+ ...
+```
+
+
+
+### Configuring paths for `charts`
+
+The `spec.charts.helmRepositoryTemplate.path` and `spec.charts.items[].template.path` fields can be used to specify the paths of these resources:
+
+Example
+
+```yaml
+spec:
+ charts:
+ helmRepositoryTemplate:
+ // highlight-next-line
+ path: clusters/${CLUSTER_NAME}/workloads/helm-repo.yaml
+ items:
+ - chart: cert-manager
+ version: 0.0.8
+ template:
+ // highlight-next-line
+ path: clusters/${CLUSTER_NAME}/workloads/cert-manager.yaml
+```
+
+
+## Default Paths
+
+If the `spec.resourcetemplates[].path` is omitted, a default path for the
+rendered template is calculated.
+
+In this case some of the submitted params are used. Users **must** provide one of the following parameters:
+- `CLUSTER_NAME`
+- `RESOURCE_NAME`
+
+To ensure users supply these values, set the parameters to `required` in the the
+template definition:
+
+```yaml
+spec:
+ params:
+ - name: RESOURCE_NAME
+ required: true
+ # or
+ - name: CLUSTER_NAME
+ required: true
+```
+
+:::caution Important
+
+The **kustomization** feature and the `add-common-bases` annotation feature **always** use a calculated default path.
+If you are using these features one of `CLUSTER_NAME` or `RESOURCE_NAME`
+**must** be provided, even if you specify a `path` for all the other resources in the template.
+
+:::
+
+The default path for a template has a few components:
+- From the params: `CLUSTER_NAME` or `RESOURCE_NAME`, **required**.
+- From the params: `NAMESPACE`, default: `default`
+- From `values.yaml` for the Weave GitOps Enterprise `mccp` chart: `values.config.capi.repositoryPath`, default: `clusters/management/clusters`
+
+These are composed to create the path:
+`${repositoryPath}/${NAMESPACE}/${CLUSTER_OR_RESOURCE_NAME}.yaml`
+
+Using the default values and supplying `CLUSTER_NAME` as `my-cluster` will result in the path:
+`clusters/management/clusters/default/my-cluster.yaml`
+
diff --git a/website/versioned_docs/version-0.29.0/gitops-templates/resource-templates.mdx b/website/versioned_docs/version-0.29.0/gitops-templates/resource-templates.mdx
new file mode 100644
index 0000000000..aae7548ee5
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/gitops-templates/resource-templates.mdx
@@ -0,0 +1,63 @@
+---
+title: Resource Templates
+hide_title: true
+---
+
+import TierLabel from "../_components/TierLabel";
+
+# Resource templates
+
+Resource templates are used to create Kubernetes resources. They are defined in the `spec.resourcetemplates` section of the template.
+
+### The `content` key
+
+The `content` key is used to define a list of resources:
+
+```yaml
+spec:
+ resourcetemplates:
+ - content:
+ - apiVersion: v1
+ kind: Namespace
+ metadata:
+ name: nginx
+ - apiVersion: v1
+ kind: Namespace
+ metadata:
+ name: cert-manager
+```
+
+### The `raw` key
+
+The `raw` key is used to define a raw string that will written to the specified path.
+
+This can be useful to preserve comments or formatting in the rendered resource.
+
+```yaml
+spec:
+ resourcetemplates:
+ - path: "helm-release.yaml"
+ raw: |
+ apiVersion: helm.toolkit.fluxcd.io/v2beta1
+ kind: HelmRelease
+ metadata:
+ name: podinfo
+ namespace: prod-github
+ spec:
+ interval: 1m
+ chart:
+ spec:
+ chart: podinfo
+ version: "6.0.0" # {"$promotion": "flux-system:podinfo-github:prod"}
+ sourceRef:
+ kind: HelmRepository
+ name: podinfo
+ interval: 1m
+```
+
+:::info
+
+- The `raw` key is not compatible with the `content` key. Only one of the two can be used.
+- The `raw` key data must still be a valid kubernetes unstructured object.
+
+:::
diff --git a/website/versioned_docs/version-0.29.0/gitops-templates/supported-langs.mdx b/website/versioned_docs/version-0.29.0/gitops-templates/supported-langs.mdx
new file mode 100644
index 0000000000..bc61865948
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/gitops-templates/supported-langs.mdx
@@ -0,0 +1,93 @@
+---
+title: Supported Templating Languages
+hide_title: true
+---
+import TierLabel from "../_components/TierLabel";
+
+# Supported Templating Languages
+
+The following templating languages are supported:
+- envsubst (default)
+- templating
+
+Declare the templating language to be used to render the template by setting `spec.renderType`.
+
+## Envsubst
+
+`envsubst`, which is short for 'environment substitution', uses [envsubst](https://github.com/a8m/envsubst)
+for rendering.
+This templating format is used by [clusterctl](https://cluster-api.sigs.k8s.io/clusterctl/overview.html).
+
+Variables can be set for rendering into the template in the `${VAR_NAME}`
+syntax.
+
+### Supported Functions
+
+| __Expression__ | __Meaning__ |
+| ----------------- | -------------- |
+| `${var}` | Value of `$var`
+| `${#var}` | String length of `$var`
+| `${var^}` | Uppercase first character of `$var`
+| `${var^^}` | Uppercase all characters in `$var`
+| `${var,}` | Lowercase first character of `$var`
+| `${var,,}` | Lowercase all characters in `$var`
+| `${var:n}` | Offset `$var` `n` characters from start
+| `${var:n:len}` | Offset `$var` `n` characters with max length of `len`
+| `${var#pattern}` | Strip shortest `pattern` match from start
+| `${var##pattern}` | Strip longest `pattern` match from start
+| `${var%pattern}` | Strip shortest `pattern` match from end
+| `${var%%pattern}` | Strip longest `pattern` match from end
+| `${var-default}` | If `$var` is not set, evaluate expression as `$default`
+| `${var:-default}` | If `$var` is not set or is empty, evaluate expression as `$default`
+| `${var=default}` | If `$var` is not set, evaluate expression as `$default`
+| `${var:=default}` | If `$var` is not set or is empty, evaluate expression as `$default`
+| `${var/pattern/replacement}` | Replace as few `pattern` matches as possible with `replacement`
+| `${var//pattern/replacement}` | Replace as many `pattern` matches as possible with `replacement`
+| `${var/#pattern/replacement}` | Replace `pattern` match with `replacement` from `$var` start
+| `${var/%pattern/replacement}` | Replace `pattern` match with `replacement` from `$var` end
+
+## Templating
+
+Templating uses text/templating for rendering, using go-templating style syntax `{{ .params.CLUSTER_NAME }}`
+where params are provided by the `.params` variable.
+Template functions can also be used with the syntax `{{ .params.CLUSTER_NAME | FUNCTION }}`.
+
+### Supported Functions
+
+As taken (from the [Sprig library](http://masterminds.github.io/sprig/))
+
+| __Function Type__ | __Functions__ |
+| ----------------- | -------------- |
+| String Functions | *trim*, *wrap*, *randAlpha*, *plural*
+| String List Functions | *splitList*, *sortAlpha*
+| Integer Math Functions | *add*, *max*, *mul*
+| Integer Slice Functions | *until*, untilStep
+| Float Math Functions | *addf*, *maxf*, *mulf*
+| Date Functions | *now*, *date*
+| Defaults Functions | *default*, *empty*, *coalesce*, *fromJson*, *toJson*, *toPrettyJson*, *toRawJson*, ternary
+| Encoding Functions | *b64enc*, *b64dec*
+| Lists and List Functions | *list*, *first*, *uniq*
+| Dictionaries and Dict Functions | *get*, *set*, *dict*, *hasKey*, *pluck*, *dig*, *deepCopy*
+| Type Conversion Functions | *atoi*, *int64*, *toString*
+| Flow Control Functions | *fail*
+| UUID Functions | *uuidv4*
+| Version Comparison Functions | *semver*, semverCompare
+| Reflection | *typeOf*, *kindIs*, *typeIsLike*
+
+### Custom Delimiters
+
+The default delimiters for `renderType: templating` are `{{` and `}}`.
+These can be changed by setting the `templates.weave.works/delimiters` annotation
+on the template. For example:
+
+- `templates.weave.works/delimiters: "{{,}}"` - default
+- `templates.weave.works/delimiters: "${{,}}"`
+ - Use `${{` and `}}`, for example `"${{ .params.CLUSTER_NAME }}"`
+ - Useful as `{{` in yaml is invalid syntax and needs to be quoted. If you need to provide a un-quoted number value like `replicas: 3` you should use these delimiters.
+ - :x: `replicas: {{ .params.REPLICAS }}` Invalid yaml
+ - :x: `replicas: "{{ .params.REPLICAS }}"` Valid yaml, incorrect type. The type is a `string` not a `number` and will fail validation.
+ - :white_check_mark: `replicas: ${{ .params.REPLICAS }}` Valid yaml and correct `number` type.
+- `templates.weave.works/delimiters: "<<,>>" `
+ - Use `<<` and `>>`, for example `<< .params.CLUSTER_NAME >>`
+ - Useful if you are nesting templates and need to differentiate between the delimiters used in the inner and outer templates.
+
diff --git a/website/versioned_docs/version-0.29.0/gitops-templates/versions.mdx b/website/versioned_docs/version-0.29.0/gitops-templates/versions.mdx
new file mode 100644
index 0000000000..7d123925b2
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/gitops-templates/versions.mdx
@@ -0,0 +1,67 @@
+---
+title: Version Information
+hide_title: true
+---
+
+import TierLabel from "../_components/TierLabel";
+
+# Version Information
+
+There are now multiple published versions of the template CRD.
+
+## Migration notes
+
+### `v1alpha1` to `v1alpha2`
+
+When manually migrating a template from `v1alpha1` to `v1alpha2` (for example in git) you will need to:
+1. Update the `apiVersion` to `templates.weave.works/v1alpha2`
+1. Move the `spec.resourcetemplates` field to `spec.resourcetemplates[0].contents`
+1. Either leave the `spec.resourcetemplates[0].path` field empty or give it a sensible value.
+
+If you experience issues with the path not being recognised when Flux reconciles
+the new template versions, try manually applying the new template to the cluster directly with:
+1. Run `kubectl apply -f capi-template.yaml`
+1. Run `flux reconcile kustomization --with-source flux-system` **twice**.
+
+## Conversion Webhook
+
+A conversion webhook is hosted by the `flux-system/templates-controller-webhook-service` service.
+`v1alpha1` templates are automatically converted to `v1alpha2` when they are loaded into the cluster.
+
+### v1alpha1 to v1alpha2 conversion
+
+The `spec.resourcetemplates` field is moved to `spec.resourcetemplates[0].contents` and the `spec.resourcetemplates[0].path` is left empty.
+When the tempalte is rendered the `spec.resourcetemplates[0].path` field has a default value calculated.
+
+## `v1alpha2` (default) notes
+
+This version changes the type of `spec.resourcetemplates` from a list of objects to a list of files with a `path` and `contents`:
+
+Example:
+```yaml
+spec:
+ resourcetemplates:
+ - path: "clusters/{{ .params.CLUSTER_NAME }}.yaml"
+ contents:
+ - apiVersion: cluster.x-k8s.io/v1alpha3
+ kind: Cluster
+ metadata:
+ name: "{{ .params.CLUSTER_NAME }}"
+ path: "clusters/{{ .params.CLUSTER_NAME }}.yaml"
+```
+
+## `v1alpha1` notes
+
+The original version of the template. This version is deprecated and will be removed in a future release.
+
+It uses `spec.resourcetemplates` as a list of resources to render.
+
+Example:
+```yaml
+spec:
+ resourcetemplates:
+ - apiVersion: cluster.x-k8s.io/v1alpha3
+ kind: Cluster
+ metadata:
+ name: "{{ .params.CLUSTER_NAME }}"
+```
diff --git a/website/versioned_docs/version-0.29.0/gitopssets/_api-toc.json b/website/versioned_docs/version-0.29.0/gitopssets/_api-toc.json
new file mode 100644
index 0000000000..6f2df6c977
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/gitopssets/_api-toc.json
@@ -0,0 +1,39 @@
+[
+{ "level": 3, "value": "GitOpsSet", "id": "templates.weave.works/v1alpha1.GitOpsSet" }
+,
+{ "level": 3, "value": "APIClientGenerator", "id": "templates.weave.works/v1alpha1.APIClientGenerator" }
+,
+{ "level": 3, "value": "ClusterGenerator", "id": "templates.weave.works/v1alpha1.ClusterGenerator" }
+,
+{ "level": 3, "value": "ConfigGenerator", "id": "templates.weave.works/v1alpha1.ConfigGenerator" }
+,
+{ "level": 3, "value": "GitOpsSetGenerator", "id": "templates.weave.works/v1alpha1.GitOpsSetGenerator" }
+,
+{ "level": 3, "value": "GitOpsSetNestedGenerator", "id": "templates.weave.works/v1alpha1.GitOpsSetNestedGenerator" }
+,
+{ "level": 3, "value": "GitOpsSetSpec", "id": "templates.weave.works/v1alpha1.GitOpsSetSpec" }
+,
+{ "level": 3, "value": "GitOpsSetStatus", "id": "templates.weave.works/v1alpha1.GitOpsSetStatus" }
+,
+{ "level": 3, "value": "GitOpsSetTemplate", "id": "templates.weave.works/v1alpha1.GitOpsSetTemplate" }
+,
+{ "level": 3, "value": "GitRepositoryGenerator", "id": "templates.weave.works/v1alpha1.GitRepositoryGenerator" }
+,
+{ "level": 3, "value": "GitRepositoryGeneratorDirectoryItem", "id": "templates.weave.works/v1alpha1.GitRepositoryGeneratorDirectoryItem" }
+,
+{ "level": 3, "value": "GitRepositoryGeneratorFileItem", "id": "templates.weave.works/v1alpha1.GitRepositoryGeneratorFileItem" }
+,
+{ "level": 3, "value": "HeadersReference", "id": "templates.weave.works/v1alpha1.HeadersReference" }
+,
+{ "level": 3, "value": "ImagePolicyGenerator", "id": "templates.weave.works/v1alpha1.ImagePolicyGenerator" }
+,
+{ "level": 3, "value": "ListGenerator", "id": "templates.weave.works/v1alpha1.ListGenerator" }
+,
+{ "level": 3, "value": "MatrixGenerator", "id": "templates.weave.works/v1alpha1.MatrixGenerator" }
+,
+{ "level": 3, "value": "PullRequestGenerator", "id": "templates.weave.works/v1alpha1.PullRequestGenerator" }
+,
+{ "level": 3, "value": "ResourceInventory", "id": "templates.weave.works/v1alpha1.ResourceInventory" }
+,
+{ "level": 3, "value": "ResourceRef", "id": "templates.weave.works/v1alpha1.ResourceRef" }
+]
diff --git a/website/versioned_docs/version-0.29.0/gitopssets/_api.mdx b/website/versioned_docs/version-0.29.0/gitopssets/_api.mdx
new file mode 100644
index 0000000000..d288ebe879
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/gitopssets/_api.mdx
@@ -0,0 +1,1179 @@
+
If set, this will configure the Method to be POST automatically.
+
+
+
+
+singleElement
+
+bool
+
+
+
+(Optional)
+
SingleElement means generate a single element with the result of the API
+call.
+
When true, the response must be a JSON object and will be returned as a
+single element, i.e. only one element will be generated containing the
+entire object.
GitOpsSetNestedGenerator describes the generators usable by the MatrixGenerator.
+This is a subset of the generators allowed by the GitOpsSetGenerator because the CRD format doesn’t support recursive declarations.
+
+
+
+
Field
+
Description
+
+
+
+
+
+name
+
+string
+
+
+
+(Optional)
+
Name is an optional field that will be used to prefix the values generated
+by the nested generators, this allows multiple generators of the same
+type in a single Matrix generator.
ResourceRef contains the information necessary to locate a resource within a cluster.
+
+
+
+
Field
+
Description
+
+
+
+
+
+id
+
+string
+
+
+
+
ID is the string representation of the Kubernetes resource object’s metadata,
+in the format ‘namespace_name_group_kind’.
+
+
+
+
+v
+
+string
+
+
+
+
Version is the API version of the Kubernetes resource object’s kind.
+
+
+
+
+
+
This page was automatically generated with gen-crd-api-reference-docs
+
diff --git a/website/versioned_docs/version-0.29.0/gitopssets/api-reference.mdx b/website/versioned_docs/version-0.29.0/gitopssets/api-reference.mdx
new file mode 100644
index 0000000000..94c3b31de6
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/gitopssets/api-reference.mdx
@@ -0,0 +1,10 @@
+---
+title: API reference
+hide_title: true
+---
+
+import GeneratedAPI from './_api.mdx';
+import apiToc from './_api-toc.json';
+export const toc = apiToc;
+
+
diff --git a/website/versioned_docs/version-0.29.0/gitopssets/guide.mdx b/website/versioned_docs/version-0.29.0/gitopssets/guide.mdx
new file mode 100644
index 0000000000..76b19bfaad
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/gitopssets/guide.mdx
@@ -0,0 +1,1214 @@
+# Templating from Generators
+
+## Basics
+
+Currently rendering templates operates in two phases:
+
+- Generate all template parameters from the configured generators
+- Render all the templates for each set of template parameters
+
+Please read the [security information](#security) below before using this.
+
+## General behaviour
+
+GitOpsSets can be suspended, by setting the `spec.suspend` flag to be true.
+
+When this is the case, updates will not be applied, no resources created _or_
+deleted.
+
+In addition, a manual reconciliation can be requested by annotating a GitOpsSet
+with the `reconcile.fluxcd.io/requestedAt` annotation.
+
+## Generation
+
+The simplest generator is the `List` generator.
+
+```yaml
+apiVersion: templates.weave.works/v1alpha1
+kind: GitOpsSet
+metadata:
+ name: gitopsset-sample
+spec:
+ generators:
+ - list:
+ elements:
+ - env: dev
+ team: dev-team
+ - env: production
+ team: ops-team
+ - env: staging
+ team: ops-team
+```
+
+The elements in there are a set JSON of objects[^yaml], there are three in this example, and each of them has two keys, `env` and `team`.
+
+Other generators provide different sets of keys and values.
+
+The [generators](#generators) documentation below provides more information on what the other generators output.
+
+## Rendering templates
+
+Templates are Kubernetes resources in YAML format.
+
+Each template is rendered for each element generated by the generators.
+
+```yaml
+apiVersion: templates.weave.works/v1alpha1
+kind: GitOpsSet
+metadata:
+ name: gitopsset-sample
+spec:
+ generators:
+ - list:
+ elements:
+ - env: dev
+ team: dev-team
+ - env: production
+ team: ops-team
+ - env: staging
+ team: ops-team
+ templates:
+ - content:
+ kind: Kustomization
+ apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
+ metadata:
+ name: "{{ .Element.env }}-demo"
+ labels:
+ app.kubernetes.io/name: go-demo
+ app.kubernetes.io/instance: "{{ .Element.env }}"
+ com.example/team: "{{ .Element.team }}"
+ spec:
+ interval: 5m
+ path: "./examples/kustomize/environments/{{ .Element.env }}"
+ prune: true
+ sourceRef:
+ kind: GitRepository
+ name: go-demo-repo
+```
+
+The generated elements are provided to the template in the `Element` scope, so
+`.Element.dev` refers to the `dev` field from the List element.
+
+The output from all generators is exposed in the `Element` scope, not just List
+generators.
+
+## Repeating templates
+
+The output from a generator is an array of JSON objects[^yaml], the keys of which can contain repeating elements, either further JSON objects, or scalar values.
+
+It can be desirable to repeat a template for a repeated element in a generated
+value.
+
+```yaml
+apiVersion: templates.weave.works/v1alpha1
+kind: GitOpsSet
+metadata:
+ name: repeated-gitopsset-sample
+spec:
+ generators:
+ - list:
+ elements:
+ - env: dev
+ team: dev-team
+ teams:
+ - name: "team1"
+ - name: "team2"
+ - name: "team3"
+ - env: staging
+ team: staging-team
+ teams:
+ - name: "team4"
+ - name: "team5"
+ - name: "team6"
+ templates:
+ - repeat: "{ .teams }"
+ content:
+ kind: ConfigMap
+ apiVersion: v1
+ metadata:
+ name: "{{ .Repeat.name }}-demo"
+ data:
+ name: "{{ .Repeat.name }}-demo"
+ team: "{{ .Element.team }}"
+```
+
+The template `repeat` field is a [JSONPath](https://kubernetes.io/docs/reference/kubectl/jsonpath/) expression that is applied to each element during the template rendering.
+
+Templates that use `repeat` will have two separate scopes for the template params, `.Element` which is the top-level element generated by the generator, and the additional `.Repeat` scope, which is the repeating element.
+
+In this case, six different `ConfigMaps` are generated, three for the "dev-team" and three for the "staging-team".
+
+## Delimiters
+
+The default delimiters for the template engine are `{{` and `}}`, which is the same as the Go template engine.
+
+These can be changed by adding an annotation to the `GitOpsSet`:
+
+```yaml
+apiVersion: templates.weave.works/v1alpha1
+kind: GitOpsSet
+metadata:
+ name: gitopsset-sample
+ annotations:
+ templates.weave.works/delimiters: "${{,}}"
+```
+
+Changing the delimiters can useful for:
+
+- Nesting GitopsSets within each other, as the default delimiters will conflict
+- Providing unquoted values to yaml
+
+### Unquoted values
+
+In yaml `{{` is invalid syntax and needs to be quoted. If you need to provide a un-quoted number value like `replicas: 3` you should use the `${{,}}` delimiters.
+
+- ❌ `replicas: {{ .params.REPLICAS }}` Invalid yaml
+- ❌ `replicas: "{{ .params.REPLICAS }}"` Valid yaml, incorrect type. The type is a string not a number and will fail validation.
+- ✅ `replicas: ${{ .params.REPLICAS }}` Valid yaml and correct number type.
+
+Unquoted values allow you to include objects in your templates too.
+
+```yaml
+apiVersion: templates.weave.works/v1alpha1
+kind: GitOpsSet
+metadata:
+ name: gitopsset-sample
+ annotations:
+ templates.weave.works/delimiters: "${{,}}"
+spec:
+ generators:
+ - list:
+ elements:
+ - env: dev
+ resources:
+ limits:
+ cpu: 100m
+ memory: 128Mi
+ - env: staging
+ resources:
+ limits:
+ cpu: 100m
+ memory: 128Mi
+ templates:
+ - content:
+ kind: Deployment
+ apiVersion: apps/v1
+ metadata:
+ name: go-demo
+ spec:
+ template:
+ spec:
+ containers:
+ - name: go-demo
+ image: weaveworks/go-demo:0.2.0
+ resources: ${{ .Element.resources | toJson }}
+```
+
+With the default `{{,}}` delimiters this would fail as the "resources" field would need to be quoted.
+
+Again, if we quote them we would get a string value, not an object.
+
+## Generators
+
+We currently provide these generators:
+- [list](#list-generator)
+- [pullRequests](#pullrequests-generator)
+- [gitRepository](#gitrepository-generator)
+- [matrix](#matrix-generator)
+- [apiClient](#apiclient-generator)
+- [cluster](#cluster-generator)
+- [imagepolicy](#imagepolicy-generator)
+- [config](#config-generator)
+
+### List generator
+
+This is the simplest generator, which is a hard-coded array of JSON objects, described as YAML mappings.
+
+### GitRepository generator
+
+The `GitRepository` generator operates on [Flux GitRepositories](https://fluxcd.io/flux/components/source/gitrepositories/).
+
+When a `GitRepository` is updated, this will trigger a regeneration of templates.
+
+The generator operates in two different ways, you can parse files (YAML or JSON) into Elements, or you can scan directories for subdirectories.
+
+#### Generation from files
+
+```yaml
+apiVersion: templates.weave.works/v1alpha1
+kind: GitOpsSet
+metadata:
+ name: repository-sample
+spec:
+ generators:
+ - gitRepository:
+ repositoryRef: go-demo-repo
+ files:
+ - path: examples/generation/dev.yaml
+ - path: examples/generation/production.yaml
+ - path: examples/generation/staging.yaml
+ templates:
+ - content:
+ kind: Kustomization
+ apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
+ metadata:
+ name: "{{ .Element.env }}-demo"
+ labels:
+ app.kubernetes.io/name: go-demo
+ app.kubernetes.io/instance: "{{ .Element.env }}"
+ com.example/team: "{{ .Element.team }}"
+ spec:
+ interval: 5m
+ path: "./examples/kustomize/environments/{{ .Element.env }}"
+ prune: true
+ sourceRef:
+ kind: GitRepository
+ name: go-demo-repo
+```
+
+In this example, a [Flux `GitRepository`](https://fluxcd.io/flux/components/source/gitrepositories/) called `go-demo-repo` in the same namespace as the `GitOpsSet` will be tracked, and `Kustomization` resources will be generated from the three files listed.
+
+These files can be JSON or YAML.
+
+In this example we expect to find the following structure in the files:
+
+```yaml
+env: dev
+team: developers
+```
+
+Changes pushed to the `GitRepository` will result in rereconciliation of the templates into the cluster.
+
+For security reasons, you need to explicitly list out the files that the generator should parse.
+
+#### Generation from directories
+
+```yaml
+apiVersion: templates.weave.works/v1alpha1
+kind: GitOpsSet
+metadata:
+ labels:
+ app.kubernetes.io/name: gitopsset
+ app.kubernetes.io/instance: gitopsset-sample
+ app.kubernetes.io/part-of: gitopssets-controller
+ app.kubernetes.io/managed-by: kustomize
+ app.kubernetes.io/created-by: gitopssets-controller
+ name: repository-sample
+spec:
+ generators:
+ - gitRepository:
+ repositoryRef: go-demo-repo
+ directories:
+ - path: examples/kustomize/environments/*
+ templates:
+ - content:
+ kind: Kustomization
+ apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
+ metadata:
+ name: "{{ .Element.Base }}-demo"
+ labels:
+ app.kubernetes.io/name: go-demo
+ app.kubernetes.io/instance: "{{ .Element.Base }}"
+ com.example/team: "{{ .Element.Base }}"
+ spec:
+ interval: 5m
+ path: "{{ .Element.Directory }}"
+ prune: true
+ sourceRef:
+ kind: GitRepository
+ name: go-demo-repo
+```
+
+In this example, a [Flux `GitRepository`](https://fluxcd.io/flux/components/source/gitrepositories/) called `go-demo-repo` in the same namespace as the `GitOpsSet` will be tracked, and `Kustomization` resources are generated from paths within the `examples/kustomize/environments/*` directory within the repository.
+
+Each generated element has two keys, `.Element.Directory` which will be a repo-relative path and `.Element.Base` which contains the last element of the path, for example, for a directory `./examples/kustomize/environments/production` this will be `production`.
+
+It is also possible to exclude paths from the generated list, for example, if you do not want to generate for a directory you can exclude it with:
+
+```yaml
+apiVersion: templates.weave.works/v1alpha1
+kind: GitOpsSet
+metadata:
+ name: repository-sample
+spec:
+ generators:
+ - gitRepository:
+ repositoryRef: go-demo-repo
+ directories:
+ - path: examples/kustomize/environments/*
+ - path: examples/kustomize/environments/production
+ exclude: true
+ templates:
+ - content:
+```
+
+In this case, all directories that are subdirectories of `examples/kustomize/environments` will be generated, **but** not `examples/kustomize/environments/production`.
+
+**Note**: The directory tree detection is restricted to the same directory as the path, no recursion is done.
+
+In fact the path is treated as a [Glob](https://pkg.go.dev/path/filepath#Glob).
+
+### PullRequests generator
+
+This will require to make authenticated requests to your Git hosting provider e.g. GitHub, GitLab, Bitbucket etc.
+
+It does only require read-only access, but all API tokens should be guarded as carefully as possible, what is a "read-only" token today, might become a token with higher-privilege in the future.
+
+_There have been many security compromises using API access tokens, do not let this happen to you!_
+
+```yaml
+apiVersion: templates.weave.works/v1alpha1
+kind: GitOpsSet
+metadata:
+ name: pull-requests-sample
+spec:
+ generators:
+ - pullRequests:
+ interval: 5m
+ driver: github
+ repo: bigkevmcd/go-demo
+ secretRef:
+ name: github-secret
+ templates:
+ - content:
+ apiVersion: source.toolkit.fluxcd.io/v1beta2
+ kind: GitRepository
+ metadata:
+ name: "pr-{{ .Element.Number }}-gitrepository"
+ namespace: default
+ spec:
+ interval: 5m0s
+ url: "{{ .Element.CloneURL }}"
+ ref:
+ branch: "{{ .Element.Branch }}"
+ - content:
+ apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
+ kind: Kustomization
+ metadata:
+ name: "pr-{{ .Element.Number }}-demo"
+ namespace: default
+ spec:
+ interval: 5m
+ path: "./examples/kustomize/environments/dev"
+ prune: true
+ targetNamespace: "{{ .Element.Branch }}-ns"
+ sourceRef:
+ kind: GitRepository
+ name: "pr-{{ .Element.Number }}-gitrepository"
+```
+
+This example will poll "github.com/bigkevmcd/go-demo" for open pull requests and trigger the deployment of these by creating a Flux `GitRepository` and a `Kustomization` to deploy.
+
+As the generator only queries open pull requests, when a PR is closed, the generated resources will be removed.
+
+For non-public installations, you can configure the `serverURL` field and point it to your own installation.
+
+The `driver` field can be `github` or `gitlab` or `bitbucketserver`, other options can be supported from [go-scm](https://github.com/jenkins-x/go-scm/blob/main/scm/factory/factory.go).
+
+The `forks` flag field can be used to indicate whether to include forks in the target pull requests or not. If set to `true` any pull request from a fork repository will be included, otherwise if `false` or not indicated the pull requests from fork repositories are discarded.
+
+Additionally labels can be provided for querying pull requests with matching labels e.g.
+
+```yaml
+- pullRequests:
+ interval: 5m
+ driver: github
+ repo: bigkevmcd/go-demo
+ secretRef:
+ name: github-secret
+ forks: false
+ labels:
+ - deploy
+```
+
+The fields emitted by the pull-request are as follows:
+
+- `Number` this is generated as a string representation
+- `Branch` this is the source branch
+- `HeadSHA` this is the SHA of the commit in the merge branch
+- `CloneURL` this is the HTTPS clone URL for this repository
+- `CloneSSHURL` this is the SSH clone URL for this repository
+- `Fork` this indicates whether the pull request is from a fork (true) or not (false)
+
+Create a read-only token that can list Pull Requests, and store it in a secret:
+
+```shell
+$ kubectl create secret generic github-secret \
+ --from-literal password=
+```
+
+### Matrix generator
+
+The matrix generator doesn't generate resources by itself. It combines the results of
+generation from other generators e.g.:
+
+```yaml
+apiVersion: templates.weave.works/v1alpha1
+kind: GitOpsSet
+metadata:
+ name: matrix-sample
+spec:
+ generators:
+ - matrix:
+ generators:
+ - gitRepository:
+ repositoryRef: go-demo-repo
+ files:
+ - path: examples/generation/dev.yaml
+ - path: examples/generation/production.yaml
+ - path: examples/generation/staging.yaml
+ - list:
+ elements:
+ - cluster: dev-cluster
+ version: 1.0.0
+```
+
+Given the files mentioned all have the following structure:
+
+```yaml
+env: dev
+team: developers
+```
+
+This will result in three sets of generated parameters, which are a combination of the maps in the files in the gitRepository, and the elements in the list generator, this can result in a combinatorial explosion of resources being created in your cluster.
+
+```yaml
+- env: dev
+ team: developers
+ cluster: dev-cluster
+ version: 1.0.0
+- env: staging
+ team: staging-team
+ cluster: dev-cluster
+ version: 1.0.0
+- env: production
+ team: production-team
+ cluster: dev-cluster
+ version: 1.0.0
+```
+
+These can be referenced in the templates, note that all keys in the merged generators from the Matrix are contained in the `Element` scope.
+
+```yaml
+apiVersion: templates.weave.works/v1alpha1
+kind: GitOpsSet
+metadata:
+ name: matrix-sample
+spec:
+ generators:
+ - matrix:
+ generators:
+ - gitRepository:
+ repositoryRef: go-demo-repo
+ files:
+ - path: examples/generation/dev.yaml
+ - path: examples/generation/production.yaml
+ - path: examples/generation/staging.yaml
+ - list:
+ elements:
+ - cluster: dev-cluster
+ version: 1.0.0
+ templates:
+ - content:
+ kind: Kustomization
+ apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
+ metadata:
+ name: "{{ .Element.env }}-demo"
+ labels:
+ app.kubernetes.io/name: go-demo
+ app.kubernetes.io/instance: "{{ .Element.env }}"
+ com.example/team: "{{ .Element.team }}"
+ com.example/cluster: "{{ .Element.cluster }}"
+ com.example/version: "{{ .Element.version }}"
+ spec:
+ interval: 5m
+ path: "./examples/kustomize/environments/{{ .Element.env }}"
+ prune: true
+ sourceRef:
+ kind: GitRepository
+ name: go-demo-repo
+```
+
+#### Optional Name for Matrix elements
+
+If you want to use two generators in a Matrix that output the same fields, they
+will collide, for example, the `ImagePolicy` generator outputs a `latestImage`
+field, if you have two, they will collide.
+
+You can provide a name for the generator in the Matrix:
+
+```yaml
+apiVersion: templates.weave.works/v1alpha1
+kind: GitOpsSet
+metadata:
+ name: matrix-sample
+spec:
+ generators:
+ - matrix:
+ generators:
+ - name: gen1
+ gitRepository:
+ repositoryRef: go-demo-repo
+ files:
+ - path: examples/generation/dev.yaml
+ - path: examples/generation/production.yaml
+ - path: examples/generation/staging.yaml
+ - name: gen2
+ list:
+ elements:
+ - cluster: dev-cluster
+ version: 1.0.0
+ templates:
+ - content:
+ kind: Kustomization
+ apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
+ metadata:
+ name: "{{ .Element.gen1.env }}-demo"
+ labels:
+ app.kubernetes.io/name: go-demo
+ app.kubernetes.io/instance: "{{ .Element.gen1.env }}"
+ com.example/team: "{{ .Element.gen1.team }}"
+ com.example/cluster: "{{ .Element.gen2.cluster }}"
+ com.example/version: "{{ .Element.gen2.version }}"
+ spec:
+ interval: 5m
+ path: "./examples/kustomize/environments/{{ .Element.gen1.env }}"
+ prune: true
+ sourceRef:
+ kind: GitRepository
+ name: go-demo-repo
+```
+The name value is used as a key in the generated results.
+
+The example above will yield:
+
+```yaml
+- gen1:
+ env: dev
+ team: developers
+ gen2:
+ cluster: dev-cluster
+ ersion: 1.0.0
+- gen1:
+ env: staging
+ team: staging-team
+ gen2:
+ cluster: dev-cluster
+ version: 1.0.0
+- gen1:
+ env: production
+ team: production-team
+ gen2:
+ cluster: dev-cluster
+ version: 1.0.0
+```
+
+### apiClient generator
+
+This generator is configured to poll an HTTP endpoint and parse the result as the generated values.
+
+This will poll an endpoint on the interval, instead of using the simpler to use PullRequest generator, you can access GitHub's API with the APIClient generator.
+
+The PullRequest generator is simpler to use, and works across multiple different git-providers.
+
+The GitHub [documentation](https://docs.github.com/en/rest/pulls/pulls?apiVersion=2022-11-28#list-pull-requests) for the API endpoint shows:
+
+```shell
+curl \
+ -H "Accept: application/vnd.github+json" \
+ -H "Authorization: Bearer "\
+ -H "X-GitHub-Api-Version: 2022-11-28" \
+ https://api.github.com/repos/OWNER/REPO/pulls
+```
+
+This can be translated into...
+
+```yaml
+apiVersion: templates.weave.works/v1alpha1
+kind: GitOpsSet
+metadata:
+ labels:
+ app.kubernetes.io/name: gitopsset
+ app.kubernetes.io/instance: gitopsset-sample
+ app.kubernetes.io/part-of: gitopssets-controller
+ app.kubernetes.io/managed-by: kustomize
+ app.kubernetes.io/created-by: gitopssets-controller
+ name: api-client-sample
+spec:
+ generators:
+ - apiClient:
+ interval: 5m
+ endpoint: https://api.github.com/repos/bigkevmcd/go-demo/pulls
+ headersRef:
+ name: github-secret
+ kind: Secret
+ templates:
+ - content:
+ apiVersion: source.toolkit.fluxcd.io/v1beta2
+ kind: GitRepository
+ metadata:
+ name: "pr-{{ .Element.id | toJson}}-gitrepository"
+ namespace: default
+ spec:
+ interval: 5m0s
+ url: "{{ .Element.head.repo.clone_url }}"
+ ref:
+ branch: "{{ .Element.head.ref }}"
+ - content:
+ apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
+ kind: Kustomization
+ metadata:
+ name: "pr-{{ .Element.id | toJson }}-demo"
+ namespace: default
+ spec:
+ interval: 5m
+ path: "./examples/kustomize/environments/dev"
+ prune: true
+ targetNamespace: "{{ .Element.head.ref }}-ns"
+ sourceRef:
+ kind: GitRepository
+ name: "pr-{{ .Element.id | toJson }}-gitrepository"
+```
+
+As with the [Pull Request generator](#pullrequests-generator), this also requires a secret token to be able to access the API
+
+We need to pass this as an HTTP header.
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+ name: github-secret
+ namespace: default
+type: Opaque
+stringData:
+ Accept: application/vnd.github+json
+ Authorization: Bearer ghp_
+ X-GitHub-Api-Version: "2022-11-28"
+```
+
+The keys in the secret match the command-line example using curl.
+
+Unlike the Pull Request generator, you need to figure out the paths to the elements yourself.
+
+#### APIClient JSONPath
+
+Not all APIs return an array of JSON objects, sometimes it's nested within a result type structure e.g.
+
+```json
+{
+ "things": [
+ {
+ "env": "dev",
+ "team": "dev-team"
+ },
+ {
+ "env": "production",
+ "team": "opts-team"
+ },
+ {
+ "env": "staging",
+ "team": "opts-team"
+ }
+ ]
+}
+```
+
+You can use JSONPath to extract the fields from this data...
+
+```yaml
+apiVersion: templates.weave.works/v1alpha1
+kind: GitOpsSet
+metadata:
+ labels:
+ app.kubernetes.io/name: gitopsset
+ app.kubernetes.io/instance: gitopsset-sample
+ app.kubernetes.io/part-of: gitopssets-controller
+ app.kubernetes.io/managed-by: kustomize
+ app.kubernetes.io/created-by: gitopssets-controller
+ name: api-client-sample
+spec:
+ generators:
+ - apiClient:
+ interval: 5m
+ endpoint: https://api.example.com/demo
+ jsonPath: "{ $.things }"
+```
+
+This will generate three maps for templates, with just the _env_ and _team_ keys.
+
+#### APIClient POST body
+
+Another piece of functionality in the APIClient generator is the ability to POST
+JSON to the API.
+
+```yaml
+apiVersion: templates.weave.works/v1alpha1
+kind: GitOpsSet
+metadata:
+ labels:
+ app.kubernetes.io/name: gitopsset
+ app.kubernetes.io/instance: gitopsset-sample
+ app.kubernetes.io/part-of: gitopssets-controller
+ app.kubernetes.io/managed-by: kustomize
+ app.kubernetes.io/created-by: gitopssets-controller
+ name: api-client-sample
+spec:
+ generators:
+ - apiClient:
+ interval: 5m
+ endpoint: https://api.example.com/demo
+ body:
+ name: "testing"
+ value: "testing2"
+```
+
+This will send a request body as JSON (Content-Type "application/json") to the
+server and interpret the result.
+
+The JSON body sent will look like this:
+
+```json
+{ "name": "testing", "value": "testing2" }
+```
+
+#### APIClient simple results
+
+Instead of using the JSONPath to extract from a complex structure, you can configure the result to be a single element.
+
+```yaml
+apiVersion: templates.weave.works/v1alpha1
+kind: GitOpsSet
+metadata:
+ labels:
+ app.kubernetes.io/name: gitopsset
+ app.kubernetes.io/instance: gitopsset-sample
+ app.kubernetes.io/part-of: gitopssets-controller
+ app.kubernetes.io/managed-by: kustomize
+ app.kubernetes.io/created-by: gitopssets-controller
+ name: api-client-sample
+spec:
+ generators:
+ - apiClient:
+ singleElement: true
+ interval: 5m
+ endpoint: https://api.example.com/demo
+```
+
+Whatever result is parsed from the API endpoint will be returned as a map in a single element.
+
+For generation, you might need to use the `repeat` mechanism to generate repeating results.
+
+### Cluster generator
+
+The cluster generator generates from in-cluster GitOpsCluster resources.
+
+For example, this `GitOpsSet` will generate a `Kustomization` resource for each cluster matching the [Label selector](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/).
+
+```yaml
+apiVersion: templates.weave.works/v1alpha1
+kind: GitOpsSet
+metadata:
+ name: cluster-sample
+spec:
+ generators:
+ - cluster:
+ selector:
+ matchLabels:
+ env: dev
+ team: dev-team
+ templates:
+ - content:
+ kind: Kustomization
+ apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
+ metadata:
+ name: "{{ .Element.ClusterName }}-demo"
+ labels:
+ app.kubernetes.io/name: go-demo
+ app.kubernetes.io/instance: "{{ .Element.ClusterName }}"
+ com.example/team: "{{ .Element.ClusterLabels.team }}"
+ spec:
+ interval: 5m
+ path: "./examples/kustomize/environments/{{ .Element.ClusterLabels.env }}"
+ prune: true
+ sourceRef:
+ kind: GitRepository
+ name: go-demo-repo
+```
+
+The following fields are generated for each GitOpsCluster.
+
+- `ClusterName` the name of the cluster
+- `ClusterNamespace` the namespace that this cluster is from
+- `ClusterLabels` the labels from the metadata field on the GitOpsCluster
+- `ClusterAnnotations` the annotations from the metadata field on the GitOpsCluster
+
+If the selector is not provided, all clusters from all namespaces will be returned:
+
+```yaml
+apiVersion: templates.weave.works/v1alpha1
+kind: GitOpsSet
+metadata:
+ name: cluster-sample
+spec:
+ generators:
+ - cluster: {}
+```
+
+Otherwise if the selector is empty, no clusters will be generated:
+
+```yaml
+apiVersion: templates.weave.works/v1alpha1
+kind: GitOpsSet
+metadata:
+ name: cluster-sample
+spec:
+ generators:
+ - cluster:
+ selector: {}
+```
+
+### ImagePolicy generator
+
+The `ImagePolicy` generator works with the [Flux Image Automation](https://fluxcd.io/flux/components/image/).
+
+When an `ImagePolicy` is updated, this will trigger a regeneration of templates.
+
+The generated elements have the following fields:
+
+* latestImage - the latest image from the status field on the `ImagePolicy`
+* latestTag - only the tag part of the latestImage, e.g. will be v0.1 for an image of "testing/image:v0.1"
+* previousImage - the previous image from the status field on the `ImagePolicy`
+
+This can be used simply, to create a deployment with an image...or, combined with a Matrix generator, to manage multiple workloads with the same image.
+
+```yaml
+apiVersion: templates.weave.works/v1alpha1
+kind: GitOpsSet
+metadata:
+ name: imagepolicy-example
+ namespace: default
+spec:
+ generators:
+ - imagePolicy:
+ policyRef: podinfo
+ templates:
+ - content:
+ kind: ConfigMap
+ apiVersion: v1
+ metadata:
+ name: "demo-configmap"
+ data:
+ image: "{{ .Element.latestImage }}"
+```
+
+In this example, a `ConfigMap` is generated containing the latest image whenever an `ImagePolicy` called `podinfo` is updated.
+
+Combined in a Matrix, like this, it will generate two `ConfigMaps` with the values.
+
+```yaml
+apiVersion: templates.weave.works/v1alpha1
+kind: GitOpsSet
+metadata:
+ name: imagepolicy-matrix-example
+ namespace: default
+spec:
+ generators:
+ - matrix:
+ generators:
+ - imagePolicy:
+ policyRef: podinfo
+ - list:
+ elements:
+ - cluster: dev-cluster
+ version: 1.0.0
+ - cluster: prod-cluster
+ version: 1.0.0
+ templates:
+ - content:
+ kind: ConfigMap
+ apiVersion: v1
+ metadata:
+ name: "demo-configmap-{{ .Element.cluster }}"
+ data:
+ image: "{{ .Element.latestImage }}"
+ cluster: "{{ .Element.cluster }}"
+ version: "{{ .Element.version }}"
+```
+
+The resulting ConfigMaps look like this:
+
+```shell
+$ kubectl get configmaps
+NAME DATA AGE
+demo-configmap-dev-cluster 3 3m19s
+demo-configmap-prod-cluster 3 3m19s
+```
+
+With the templated fields like this:
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+ name: demo-configmap-dev-cluster
+ namespace: default
+data:
+ cluster: dev-cluster
+ image: stefanprodan/podinfo:5.1.4
+ version: 1.0.0
+```
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+ name: demo-configmap-prod-cluster
+ namespace: default
+data:
+ cluster: prod-cluster
+ image: stefanprodan/podinfo:5.1.4
+ version: 1.0.0
+```
+
+### Config generator
+
+The `Config` generator with Kubernetes [ConfigMaps](https://kubernetes.io/docs/concepts/configuration/configmap/) and [Secrets](https://kubernetes.io/docs/concepts/configuration/secret/).
+
+When an `ConfigMap` or `Secret` is updated, this will trigger a regeneration of templates.
+
+This can be used simply, to create a resource with an config variable...or, combined with a Matrix generator, to manage multiple workloads with the same values.
+
+With the existing `ConfigMap`
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+ name: test-cm
+data:
+ name: test-config
+ demo: test-value
+```
+And the GitOpsSet below
+```yaml
+apiVersion: templates.weave.works/v1alpha1
+kind: GitOpsSet
+metadata:
+ name: config-sample
+spec:
+ generators:
+ - config:
+ kind: ConfigMap
+ name: test-cm
+ templates:
+ - content:
+ kind: ConfigMap
+ apiVersion: v1
+ metadata:
+ name: "{{ .Element.name }}-demo"
+ labels:
+ app.kubernetes.io/name: go-demo
+ app.kubernetes.io/instance: "{{ .Element.name }}"
+ data:
+ generatedValue: "{{ .Element.demo }}"
+```
+In this example, a new `ConfigMap` is generated containing the value of the "demo" field from the existing `ConfigMap` _test-cm_.
+
+As with the other generators, the `Config` generator can be combined with other generators:
+
+This will generate two `ConfigMaps` with the values.
+```yaml
+apiVersion: templates.weave.works/v1alpha1
+kind: GitOpsSet
+metadata:
+ name: imagepolicy-matrix-example
+ namespace: default
+spec:
+ generators:
+ - matrix:
+ generators:
+ - config:
+ kind: ConfigMap
+ name: test-cm
+ - list:
+ elements:
+ - cluster: dev-cluster
+ version: 1.0.0
+ - cluster: prod-cluster
+ version: 1.0.0
+ templates:
+ - content:
+ kind: ConfigMap
+ apiVersion: v1
+ metadata:
+ name: "demo-configmap-{{ .Element.cluster }}"
+ data:
+ generatedValue: "{{ .Element.demo }}"
+ cluster: "{{ .Element.cluster }}"
+ version: "{{ .Element.version }}"
+```
+
+The resulting ConfigMaps look like this:
+
+```shell
+$ kubectl get configmaps
+NAME DATA AGE
+demo-configmap-dev-cluster 3 3m19s
+demo-configmap-prod-cluster 3 3m19s
+```
+
+With the templated fields like this:
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+ name: demo-configmap-dev-cluster
+ namespace: default
+data:
+ cluster: dev-cluster
+ generatedValue: test-value
+ version: 1.0.0
+```
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+ name: demo-configmap-prod-cluster
+ namespace: default
+data:
+ cluster: prod-cluster
+ generatedValue: test-value
+ version: 1.0.0
+```
+
+## Templating functions
+
+Currently, the [Sprig](http://masterminds.github.io/sprig/) functions are available in the templating, with some functions removed[^sprig] for security reasons.
+
+In addition, we also provide two additional functions:
+
+- sanitize - sanitises strings to be compatible with [Kubernetes DNS](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names) name requirements
+- getordefault - gets a key from the `.Element` or defaults to another value.
+
+The examples below assume an element that looks like this:
+
+```json
+{
+ "team": "engineering dev"
+}
+```
+
+### sanitize template function
+
+And a template that looks like this:
+
+```yaml
+kind: Service
+metadata:
+ name: {{ sanitize .Element.team }}-demo
+```
+
+This would output:
+
+```yaml
+kind: Service
+metadata:
+ name: engineeringdev-demo
+```
+
+### getordefault
+
+For template that looks like this:
+
+```yaml
+kind: Service
+metadata:
+ name: {{ getordefault .Element "name" "defaulted" }}-demo
+```
+
+This would output:
+
+```yaml
+kind: Service
+metadata:
+ name: defaulted-demo
+```
+
+If the _key_ to get does exist in the `.Element` it will be inserted, the "default" is only inserted if it doesn't exist.
+
+## Security
+
+**WARNING** generating resources and applying them directly into your cluster can be dangerous to the health of your cluster.
+
+This is especially true for the `GitRepository` generator, where it may not be obvious to the author of the files, or the author of the template the consequences of the template rendering.
+
+The default `ServiceAccount` that is used by the gitopssets-controller is extremely limited, and can not create resources, you will need to explicitly grant permissions to create any of the resources you declare in the template, missing permissions will appear in the controller logs.
+
+It is not recommended that you create a role with blanket permissions, under the right circumstances, someone could accidentally _or_ maliciously overwrite the cluster control-plane, which could be very dangerous.
+
+## Limiting via service-accounts
+
+You can configure the service-account that is used to create resources.
+
+```yaml
+apiVersion: templates.weave.works/v1alpha1
+kind: GitOpsSet
+metadata:
+ name: matrix-sample
+spec:
+ # the controller will impersonate this service account
+ serviceAccountName: test-sa
+ generators:
+ - list:
+ elements:
+ - env: dev
+ team: dev-team
+ - env: production
+ team: ops-team
+ - env: staging
+ team: ops-team
+ templates:
+ - content:
+ kind: Kustomization
+ apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
+ metadata:
+ name: "{{ .Element.env }}-demo"
+ labels:
+ app.kubernetes.io/name: go-demo
+ app.kubernetes.io/instance: "{{ .Element.env }}"
+ com.example/team: "{{ .Element.team }}"
+ spec:
+ interval: 5m
+ path: "./examples/kustomize/environments/{{ .Element.env }}"
+ prune: true
+ sourceRef:
+ kind: GitRepository
+ name: go-demo-repo
+```
+
+## gitopsset-controller configuration
+
+The enabled generators can be configured via the `--enabled-generators` flag, which takes a comma separated list of generators to enable.
+
+The default is to enable all generators.
+
+For example to enable only the `List` and `GitRepository` generators:
+
+```yaml
+--enabled-generators=List,GitRepository
+```
+
+When a GitOpsSet that uses disabled generators is created, the disabled generators will be silently ignored.
+
+## Notifications
+
+Events are enabled which will trigger Kubernetes events when successful reconciliation occurs with a `Normal` event or when reconciliation fails with an `Error` event. Fluxcd's [Events](https://pkg.go.dev/github.com/fluxcd/pkg/runtime/events) package is used including the `EventRecorder` to record these events.
+
+To configure receiving the recorded events on a specific host, this can be provided via the `--events-addr` flag in `RUN_ARGS` when starting the controller. This can be any HTTP endpoint.
+
+See [fluxcd event](https://github.com/fluxcd/pkg/blob/main/apis/event/v1beta1/event.go) for the struct of the event created.
+
+[^yaml]: These are written as YAML mappings
+[^sprig]: The following functions are removed "env", "expandenv", "getHostByName", "genPrivateKey", "derivePassword", "sha256sum", "base", "dir", "ext", "clean", "isAbs", "osBase", "osDir", "osExt", "osClean", "osIsAbs"
diff --git a/website/versioned_docs/version-0.29.0/gitopssets/installation.mdx b/website/versioned_docs/version-0.29.0/gitopssets/installation.mdx
new file mode 100644
index 0000000000..f9c8137bd4
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/gitopssets/installation.mdx
@@ -0,0 +1,63 @@
+---
+title: Installation
+hide_title: true
+---
+
+import TierLabel from "../_components/TierLabel";
+
+# Installation
+
+The gitopssets-controller can be installed in two ways:
+
+- As part of the Weave Gitops Enterprise installation. (installed by default)
+- As a standalone installation using a Helm chart.
+
+The standalone installation can be useful for leaf clusters that don't have Weave Gitops Enterprise installed.
+
+## Prerequisites
+
+Before installing the gitopssets-controller, ensure that the following is installed:
+
+- flux
+
+## Installing the gitopssets-controller
+
+To install the gitopssets-controller using a Helm chart, use the following HelmRelease:
+
+```yaml
+apiVersion: v1
+kind: Namespace
+metadata:
+ name: gitopssets-system
+---
+apiVersion: source.toolkit.fluxcd.io/v1beta1
+kind: HelmRepository
+metadata:
+ name: weaveworks-artifacts-charts
+ namespace: gitopssets-system
+spec:
+ interval: 1m
+ url: https://artifacts.wge.dev.weave.works/dev/charts
+---
+apiVersion: helm.toolkit.fluxcd.io/v2beta1
+kind: HelmRelease
+metadata:
+ name: gitopssets-controller
+ namespace: gitopssets-system
+spec:
+ interval: 10m
+ chart:
+ spec:
+ chart: gitopssets-controller
+ sourceRef:
+ kind: HelmRepository
+ name: weaveworks-artifacts-charts
+ namespace: gitopssets-system
+ version: 0.6.1
+ install:
+ crds: CreateReplace
+ upgrade:
+ crds: CreateReplace
+```
+
+After adding the Namespace, HelmRepository and HelmRelease to a git repository synced by flux, commit the changes to complete the installation process.
diff --git a/website/versioned_docs/version-0.29.0/gitopssets/intro.mdx b/website/versioned_docs/version-0.29.0/gitopssets/intro.mdx
new file mode 100644
index 0000000000..6a89eac327
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/gitopssets/intro.mdx
@@ -0,0 +1,42 @@
+---
+title: Introduction
+hide_title: true
+---
+
+import TierLabel from "../_components/TierLabel";
+
+# GitOpsSets
+
+:::caution
+
+**This feature is in alpha and certain aspects will change**
+
+We're very excited for people to use this feature.
+However, please note that some changes will be made to the API and behavior,
+particularly to enhance security by implementing impersonation for more
+fine-grained control over how the generated resources are applied.
+
+:::
+
+## Introduction
+
+GitOpsSets enable Platform Operators to have a single definition for an application for multiple environments and a fleet of clusters. A single definition can be used to generate the environment and cluster-specific configuration.
+
+As an example, we can take an application that needs to be deployed to various environments (Dev, Test, Prod) built by a fleet of clusters. Each of those environments + clusters requires a specialized configuration powering the same Application. With GitOpsSets and the generators you just declare the template, you want to use, the selector that will match the cluster of the inventory, and where to get the special configuration.
+
+GitOpsSets will create out of the single resource all the objects and Flux primitives that are required to successfully deploy this application. An operation that required the editing of 100s files can be done now with a single command.
+
+**The initial generators that are coming with the preview release are:**
+
+- [List Generator](./guide.mdx#list-generator): The simplest generator. Provide a list of Key/Value pairs that you want to feed the template with.
+- [Git Generator](./guide.mdx#gitrepository-generator): Enable to extract a set of files (environment-specific configurations) from a Flux GitRepository, and make the contents of these available to the templates, this would let you have config in *app-dev.json*, *app-staging.json* and *app-production.json* for example, and the contents of these would be available to the templates.
+- [Matrix Generator](./guide.mdx#matrix-generator): Combine slices of generators into the desired compounded input.
+- [Pull request Generator](./guide.mdx#pullrequests-generator): Automatically discover open pull requests within a repository to generate a new deployment.
+- [API Client Generator](./guide.mdx#apiclient-generator): Poll an HTTP endpoint and parse the result as the generated values.
+
+
+## Use cases
+
+- Single application definition for different environments (EU-West, North America, Germany)
+- Deployment of a single definition across fleet of clusters matching any cluster based on a label (Production)
+- Separation of concerns between teams (Teams managing different artifacts flowing into a single definition via generators)
diff --git a/website/versioned_docs/version-0.29.0/gitopssets/releases.mdx b/website/versioned_docs/version-0.29.0/gitopssets/releases.mdx
new file mode 100644
index 0000000000..fd29ef3034
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/gitopssets/releases.mdx
@@ -0,0 +1,24 @@
+---
+title: Releases
+hide_title: true
+---
+
+import TierLabel from "../_components/TierLabel";
+
+# Gitopssets Controller Releases
+
+## v0.8.0
+2023-04-13
+
+- Add events recording to gitopssets
+- Fix updating of ConfigMaps
+
+## v0.7.0
+2023-03-30
+
+- Implement custom delimiters.
+
+## v0.6.1
+2023-03-20
+
+- Implement optional list expansion
\ No newline at end of file
diff --git a/website/versioned_docs/version-0.29.0/guides/cert-manager.md b/website/versioned_docs/version-0.29.0/guides/cert-manager.md
new file mode 100644
index 0000000000..40aa760de3
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/guides/cert-manager.md
@@ -0,0 +1,106 @@
+---
+title: Generating TLS certificates with cert-manager and Let's Encrypt
+---
+
+This guide shows you how to add cert-manager to a cluster bootstrapped with Weave GitOps, and how
+to configure the use of [Let's Encrypt](https://letsencrypt.org/) to issue TLS certificates.
+
+### Prerequisites
+
+- A Kubernetes cluster such as [Kind](https://kind.sigs.k8s.io/docs/user/quick-start/), running a
+[Flux-supported version of Kubernetes](https://fluxcd.io/docs/installation/#prerequisites)
+- Weave GitOps is [installed](../open-source/getting-started/install-OSS.mdx).
+
+## What Is cert-manager?
+
+[cert-manager](https://cert-manager.io/), a CNCF project, provides a way to automatically manage certificates
+in Kubernetes and OpenShift clusters. "It will obtain certificates from a variety of Issuers, both popular public
+Issuers as well as private Issuers, and ensure the certificates are valid and up-to-date, and will attempt to
+renew certificates at a configured time before expiry."
+
+## Install cert-manager
+
+As cert-manager can be installed using a [Helm Chart](https://cert-manager.io/docs/installation/helm/), we can
+simply create a `HelmRepository` and a `HelmRelease` to have Flux install everything.
+
+Commit the following to a location being reconciled by Flux.
+
+Expand to see manifest contents
+
+```yaml
+---
+apiVersion: v1
+kind: Namespace
+metadata:
+ name: cert-manager
+---
+apiVersion: source.toolkit.fluxcd.io/v1beta1
+kind: HelmRepository
+metadata:
+ name: cert-manager
+ namespace: cert-manager
+spec:
+ interval: 1h
+ url: https://charts.jetstack.io
+---
+apiVersion: helm.toolkit.fluxcd.io/v2beta1
+kind: HelmRelease
+metadata:
+ name: cert-manager
+ namespace: cert-manager
+spec:
+ interval: 5m
+ chart:
+ spec:
+ chart: cert-manager
+ version: 1.8.0
+ sourceRef:
+ kind: HelmRepository
+ name: cert-manager
+ namespace: cert-manager
+ interval: 1m
+ values:
+ installCRDs: true
+```
+
+
+
+:::note cert-manager version
+At time of writing, cert manager v1.8.0 was the latest available release and a newer version may exist, please
+ensure to check for updates.
+:::
+
+Now that `cert-manager` is running, we can create a `ClusterIssuer` to represent the certificate authority
+from which we will obtain signed certificates, in this example we are using Let's Encrypt. After changing
+the email address, commit this to the same location as above.
+
+Expand to see manifest contents
+
+```yaml
+---
+apiVersion: cert-manager.io/v1
+kind: ClusterIssuer
+metadata:
+ name: letsencrypt-prod
+spec:
+ acme:
+ # You must replace this email address with your own.
+ # Let's Encrypt will use this to contact you about expiring
+ # certificates, and issues related to your account.
+ email: weave-gitops@example.tld
+ server: https://acme-v02.api.letsencrypt.org/directory
+ privateKeySecretRef:
+ # Secret resource that will be used to store the account's private key.
+ name: letsencrypt-prod-account-key
+ solvers:
+ # Add a single challenge solver, HTTP01 using nginx
+ - http01:
+ ingress:
+ class: nginx
+```
+
+
+
+Once this `ClusterIssuer` resource is installed, the cluster is now configured to request and use certificates generated by cert-manager.
+
+This could be manually requested through the creation of a [Certificate resource](https://cert-manager.io/docs/usage/certificate/#creating-certificate-resources) or configured to be automatic, as shown in our [Configuring OIDC with Dex and GitHub](./setting-up-dex.md) guide.
diff --git a/website/versioned_docs/version-0.29.0/guides/displaying-custom-metadata.mdx b/website/versioned_docs/version-0.29.0/guides/displaying-custom-metadata.mdx
new file mode 100644
index 0000000000..8c228c40d4
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/guides/displaying-custom-metadata.mdx
@@ -0,0 +1,65 @@
+---
+title: Displaying Custom Metadata
+---
+
+Weave GitOps lets you add annotations with custom metadata to your
+Flux automations and sources, and they will be displayed in the main UI.
+
+For example, you might use this to add links to dashboards, issue
+systems, or documentation and comments that you wish to be directly visible in
+the GitOps UI.
+
+We will use the `podinfo` application that we installed in the [getting
+started guide](../open-source/getting-started/deploy-OSS.mdx) as an example. Open up the
+podinfo kustomization and add annotations to it so it looks like this:
+
+```yaml title="./clusters/my-cluster/podinfo-kustomization.yaml"
+---
+apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
+kind: Kustomization
+metadata:
+ name: podinfo
+ namespace: flux-system
+// highlight-start
+ annotations:
+ metadata.weave.works/description: |
+ Podinfo is a tiny web application made with Go that showcases best practices of running microservices in Kubernetes.
+ Podinfo is used by CNCF projects like Flux and Flagger for end-to-end testing and workshops.
+ metadata.weave.works/grafana-dashboard: https://grafana.my-org.example.com/d/podinfo-dashboard
+// highlight-end
+spec:
+ interval: 5m0s
+ path: ./kustomize
+ prune: true
+ sourceRef:
+ kind: GitRepository
+ name: podinfo
+ targetNamespace: flux-system
+```
+
+Close the file and commit and push your changes.
+
+Back in your GitOps dashboard, navigate to the 'Applications' tab and select the
+`podinfo` kustomization. At the bottom of the 'Details' section you will see the
+new 'Metadata' entries:
+
+![Application detail view showing custom metadata](/img/metadata-display.png)
+
+:::caution Restrictions
+
+ * The annotation key **must** start with the domain
+ `metadata.weave.works`. Any other annotations will be ignored.
+ * The key that will be displayed is whatever you put after the
+ domain, title cased, and with dashes replaced with spaces. Above,
+ `metadata.weave.works/grafana-dashboard` was displayed as "Grafana Dashboard".
+ * The value can either be a link, or can be plain text. Newlines in
+ plain text will be respected.
+ * The key is subject to certain limitations that kubernetes imposes on
+ annotations, including:
+ - it must be shorter than 63 characters (not including
+ the domain)
+ - it must be an English alphanumeric character, or one of `-._`.
+ - See the [kubernetes documentation](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/#syntax-and-character-set)
+ for the full list of restrictions.
+
+:::
diff --git a/website/versioned_docs/version-0.29.0/guides/fluxga-upgrade.mdx b/website/versioned_docs/version-0.29.0/guides/fluxga-upgrade.mdx
new file mode 100644
index 0000000000..d1302009da
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/guides/fluxga-upgrade.mdx
@@ -0,0 +1,156 @@
+---
+title: Upgrade to Flux GA
+hide_title: true
+---
+
+# Upgrade to Flux GA
+
+We are very excited for the release of the [Flux v2.0 GA!](https://github.com/fluxcd/flux2/releases)
+
+This guide aims to answer some [common questions](#faq) before starting the upgrade, and provides step-by-step
+instructions.
+
+## Before Starting the Upgrade
+
+Useful terms used in this guide:
+
+- `Flux Beta or Flux v0.x` as the [latest Flux Beta Release](https://github.com/fluxcd/flux2/releases/tag/v0.41.2).
+- `Flux GA` as the [latest Flux GA Release Candidate](https://github.com/fluxcd/flux2/releases/tag/v2.0.0-rc.3)
+- `Weave GitOps` as the [latest Weave GitOps Enterprise release](https://github.com/weaveworks/weave-gitops-enterprise/releases/latest)
+
+## FAQ
+
+Here you can find the most common questions around upgrading.
+
+### Why Upgrade to Flux GA
+
+Although Flux Beta APIs have been stable and used in production for quite some time, Flux GA is the main supported API version for new features and development. Features like [horizontal scaling](https://fluxcd.io/flux/cheatsheets/sharding/)
+are only available in Flux GA. Also, beta APIs will be removed after six months.
+
+### Can I Use Weave GitOps with Flux GA?
+
+Yes. This has been possible since Weave Gitops v0.22.0. Use the [latest available release](https://github.com/weaveworks/weave-gitops/releases) for the best experience.
+
+### Can I Use Weave GitOps Enterprise with Flux GA?
+
+Yes. This has been possible since Weave GitOps Enterprise v0.22.0. Use the [latest available release](https://docs.gitops.weave.works/docs/enterprise/getting-started/releases-enterprise/) for the best experience.
+
+The following limitations are knowns by version:
+
+#### v0.23.0 onwards
+
+No limitations
+
+#### v0.22.0
+
+If you are using GitOpsSets, upgrade that component to v0.10.0 for Flux GA compatibility.
+Update the Weave GitOps Enterprise HelmRelease values to use the new version.
+
+```yaml
+gitopssets-controller:
+ controllerManager:
+ manager:
+ image:
+ tag: v0.10.0
+```
+
+### Can I Use Weave GitOps with Flux v2 0.x (pre-GA versions)?
+
+As of Weave GitOps v0.29, only Flux v2.0 GA is supported. Please follow the [Upgrade](#upgrade) section to help you with the process.
+
+Earlier versions of Weave GitOps work with both Flux v2 GA and Flux v2 0.x (the pre-GA ones), but it is encouraged that you upgrade to the latest version for the best experience.
+
+## Upgrade
+
+:::info Hosted flux?
+If you are using a hosted Flux version, please check with your provider if they support Flux GA before upgrading following this guide.
+Known hosted Flux providers:
+
+- EKS Anywhere
+- [Azure AKS Flux-Gitops extension](https://learn.microsoft.com/en-us/azure/azure-arc/kubernetes/extensions-release#flux-gitops)
+
+As of writing they do not yet support the new version, so please wait before upgrading to Flux GA.
+:::
+
+Below, we'll take you through the multiple steps required to migrate to your system to Flux GA. After each step the cluster will be
+in a working state, so you can take your time to complete the migration.
+
+1. Upgrade to Flux GA on your existing leaf clusters and management clusters
+2. Upgrade to Flux GA in `ClusterBootstrapConfig`s.
+3. Upgrade to [latest Weave Gitops](https://docs.gitops.weave.works/docs/enterprise/getting-started/releases-enterprise/).
+4. Upgrade GitopsTemplates, GitopsSets and ClusterBootstrapConfigs.
+
+### 1. Upgrade to Flux GA on your existing leaf clusters and management clusters
+
+Follow the upgrade instructions from the [Flux v2.0.0 release notes](https://github.com/fluxcd/flux2/releases/tag/v2.0.0).
+
+At minimum, you'll need to rerun the `flux bootstrap` command on your leaf clusters and management clusters.
+
+You'll also need to bump API versions in your manifests to `v1` as described in the Flux upgrade instructions:
+
+> Bumping the APIs version in manifests can be done gradually. It is advised to not delay this procedure as the beta
+> versions will be removed after 6 months.
+
+At this stage all clusters are running Flux GA.
+
+### 2. Upgrade to Flux GA in ClusterBootstrapConfigs
+
+First, we ensure any new clusters are bootstrapped with Flux GA. Then we'll upgrade the existing clusters.
+
+`ClusterBootstrapConfig` will most often contain an invocation of `flux bootstrap`. Make sure the image is using `v2`.
+
+Expand to see an example
+
+```patch
+diff --git a/tools/dev-resources/user-guide/cluster-bootstrap-config.yaml b/tools/dev-resources/user-guide/cluster-bootstrap-config.yaml
+index bd41ec036..1b21df860 100644
+--- a/tools/dev-resources/user-guide/cluster-bootstrap-config.yaml
++++ b/tools/dev-resources/user-guide/cluster-bootstrap-config.yaml
+@@ -1,34 +1,34 @@
+ apiVersion: capi.weave.works/v1alpha1
+ kind: ClusterBootstrapConfig
+ metadata:
+ name: capi-gitops
+ namespace: default
+ spec:
+ clusterSelector:
+ matchLabels:
+ weave.works/capi: bootstrap
+ jobTemplate:
+ generateName: "run-gitops-{{ .ObjectMeta.Name }}"
+ spec:
+ containers:
+- - image: ghcr.io/fluxcd/flux-cli:v0.34.0
++ - image: ghcr.io/fluxcd/flux-cli:v2.0.0
+ name: flux-bootstrap
+ ...
+```
+
+
+At this stage, your new bootstrapped clusters will run Flux GA.
+
+### 3. Upgrade to latest WGE
+
+Use your regular WGE upgrade procedure to bring it to the [latest version](https://docs.gitops.weave.works/docs/enterprise/getting-started/releases-enterprise/)
+
+At this stage you have Weave GitOps running Flux GA.
+
+### 4. Upgrade GitOpsTemplates, GitOpsSets, and ClusterBootstrapConfigs
+
+Bumping the APIs version in manifests can be done gradually. We advise against delaying this procedure as the Beta versions will be removed after six months.
+
+#### `GitOpsTemplate` and `CAPITemplate`
+
+Update `GitRepository` and `Kustomization` CRs in the `spec.resourcetemplates` to `v1` as described in the flux upgrade instructions.
+
+#### `GitOpsSets`
+
+Update `GitRepository` and `Kustomization` CRs in the `spec.template` of your `GitOpsSet` resources to `v1` as described in the Flux upgrade instructions.
+
+### 5. Future steps
+
+If you haven't done it yet, plan to update your `Kustomization` , `GitRepository` and `Receiver` resources to `v1`, you can also upgrade to the future release of Flux that will drop support for `< v1` APIs.
+
+## Contact us
+
+If you find any issues, please let us know via [support](https://docs.gitops.weave.works/help-and-support/).
\ No newline at end of file
diff --git a/website/versioned_docs/version-0.29.0/guides/setting-up-dex.md b/website/versioned_docs/version-0.29.0/guides/setting-up-dex.md
new file mode 100644
index 0000000000..b2fcaf2258
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/guides/setting-up-dex.md
@@ -0,0 +1,291 @@
+---
+title: Configuring OIDC with Dex and GitHub
+---
+
+In this guide we will show you how to enable users to login to the Weave GitOps dashboard by authenticating with their GitHub account.
+
+This example uses [Dex][tool-dex] and its GitHub connector, and assumes Weave GitOps has already been installed on a Kubernetes clusters.
+
+### Pre-requisites
+
+- A Kubernetes cluster such as [Kind](https://kind.sigs.k8s.io/docs/user/quick-start/) cluster running a
+[Flux-supported version of Kubernetes](https://fluxcd.io/docs/installation/#prerequisites)
+- Weave GitOps is [installed](../open-source/getting-started/install-OSS.mdx) and [TLS has been enabled](../configuration/tls.md).
+
+## What is Dex?
+
+[Dex][tool-dex] is an identity service that uses [OpenID Connect][oidc] to
+drive authentication for other apps.
+
+Alternative solutions for identity and access management exist such as [Keycloak](https://www.keycloak.org/).
+
+[tool-dex]: https://dexidp.io/
+[oidc]: https://openid.net/connect/
+
+## Create Dex namespace
+
+Create a namespace where Dex will be installed:
+
+```yaml
+---
+apiVersion: v1
+kind: Namespace
+metadata:
+ name: dex
+```
+
+## Add credentials
+
+There are a [lot of options][dex-connectors] available with Dex, in this guide we will
+use the [GitHub connector][dex-github].
+
+We can get a GitHub ClientID and Client secret by creating a
+[new OAuth application][github-oauth].
+
+![GitHub OAuth configuration](/img/guides/setting-up-dex/github-oauth-application.png)
+
+```bash
+kubectl create secret generic github-client \
+ --namespace=dex \
+ --from-literal=client-id=${GITHUB_CLIENT_ID} \
+ --from-literal=client-secret=${GITHUB_CLIENT_SECRET}
+```
+
+[dex-connectors]: https://dexidp.io/docs/connectors/
+[dex-github]: https://dexidp.io/docs/connectors/github/
+[github-oauth]: https://docs.github.com/en/developers/apps/building-oauth-apps/creating-an-oauth-app
+
+## Deploy Dex
+
+As we did before, we can use `HelmRepository` and `HelmRelease` objects to let
+Flux deploy everything.
+
+Expand to see resource manifests
+
+```yaml
+---
+apiVersion: source.toolkit.fluxcd.io/v1beta1
+kind: HelmRepository
+metadata:
+ name: dex
+ namespace: dex
+spec:
+ interval: 1m
+ url: https://charts.dexidp.io
+---
+apiVersion: helm.toolkit.fluxcd.io/v2beta1
+kind: HelmRelease
+metadata:
+ name: dex
+ namespace: dex
+spec:
+ interval: 5m
+ chart:
+ spec:
+ chart: dex
+ version: 0.6.5
+ sourceRef:
+ kind: HelmRepository
+ name: dex
+ namespace: dex
+ interval: 1m
+ values:
+ image:
+ tag: v2.31.0
+ envVars:
+ - name: GITHUB_CLIENT_ID
+ valueFrom:
+ secretKeyRef:
+ name: github-client
+ key: client-id
+ - name: GITHUB_CLIENT_SECRET
+ valueFrom:
+ secretKeyRef:
+ name: github-client
+ key: client-secret
+ config:
+ # Set it to a valid URL
+ issuer: https://dex.dev.example.tld
+
+ # See https://dexidp.io/docs/storage/ for more options
+ storage:
+ type: memory
+
+ staticClients:
+ - name: 'Weave GitOps Core'
+ id: weave-gitops
+ secret: AiAImuXKhoI5ApvKWF988txjZ+6rG3S7o6X5En
+ redirectURIs:
+ - 'https://localhost:9001/oauth2/callback'
+ - 'https://0.0.0.0:9001/oauth2/callback'
+ - 'http://0.0.0.0:9001/oauth2/callback'
+ - 'http://localhost:4567/oauth2/callback'
+ - 'https://localhost:4567/oauth2/callback'
+ - 'http://localhost:3000/oauth2/callback'
+
+ connectors:
+ - type: github
+ id: github
+ name: GitHub
+ config:
+ clientID: $GITHUB_CLIENT_ID
+ clientSecret: $GITHUB_CLIENT_SECRET
+ redirectURI: https://dex.dev.example.tld/callback
+ orgs:
+ - name: weaveworks
+ teams:
+ - team-a
+ - team-b
+ - QA
+ - name: ww-test-org
+ ingress:
+ enabled: true
+ className: nginx
+ annotations:
+ cert-manager.io/cluster-issuer: letsencrypt-prod
+ hosts:
+ - host: dex.dev.example.tld
+ paths:
+ - path: /
+ pathType: ImplementationSpecific
+ tls:
+ - hosts:
+ - dex.dev.example.tld
+ secretName: dex-dev-example-tld
+```
+
+
+
+:::note SSL certificate without cert manager
+If we don't want to use cert manager, we can remove the related annotation and
+use our predefined secret in the `tls` section.
+:::
+
+An important part of the configuration is the `orgs` field on the GitHub
+connector.
+
+```yaml
+orgs:
+- name: weaveworks
+ teams:
+ - team-a
+ - team-b
+ - QA
+```
+
+Here we can define groups under a GitHub organisation. In this example the
+GitHub organisation is `weaveworks` and all members of the `team-a`,
+`team-b`, and `QA` teams can authenticate. Group membership will be added to
+the user.
+
+Based on these groups, we can bind roles to groups:
+
+Expand to see group role bindings
+
+```yaml
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: RoleBinding
+metadata:
+ name: wego-test-user-read-resources
+ namespace: flux-system
+subjects:
+ - kind: Group
+ name: weaveworks:QA
+ namespace: flux-system
+roleRef:
+ kind: Role
+ name: wego-admin-role
+ apiGroup: rbac.authorization.k8s.io
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: Role
+metadata:
+ name: wego-admin-role
+ namespace: flux-system
+rules:
+ - apiGroups: [""]
+ resources: ["secrets", "pods" ]
+ verbs: [ "get", "list" ]
+ - apiGroups: ["apps"]
+ resources: [ "deployments", "replicasets"]
+ verbs: [ "get", "list" ]
+ - apiGroups: ["kustomize.toolkit.fluxcd.io"]
+ resources: [ "kustomizations" ]
+ verbs: [ "get", "list", "patch" ]
+ - apiGroups: ["helm.toolkit.fluxcd.io"]
+ resources: [ "helmreleases" ]
+ verbs: [ "get", "list", "patch" ]
+ - apiGroups: ["source.toolkit.fluxcd.io"]
+ resources: ["buckets", "helmcharts", "gitrepositories", "helmrepositories", "ocirepositories"]
+ verbs: ["get", "list", "patch"]
+ - apiGroups: [""]
+ resources: ["events"]
+ verbs: ["get", "watch", "list"]
+```
+
+
+
+The same way we can bind cluster roles to a group:
+
+Expand to see group cluster role bindings
+
+```yaml
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+ name: weaveworks:team-a
+subjects:
+- kind: Group
+ name: weaveworks:team-a
+ apiGroup: rbac.authorization.k8s.io
+roleRef:
+ kind: ClusterRole
+ name: cluster-admin
+ apiGroup: rbac.authorization.k8s.io
+```
+
+
+
+### Set up static user
+
+For static user, add `staticPasswords` to the `config`:
+
+```yaml
+spec:
+ values:
+ config:
+ staticPasswords:
+ - email: "admin@example.tld"
+ hash: "$2a$10$2b2cU8CPhOTaGrs1HRQuAueS7JTT5ZHsHSzYiFPm1leZck7Mc8T4W"
+ username: "admin"
+ userID: "08a8684b-db88-4b73-90a9-3cd1661f5466"
+```
+
+A static user password can be generated with the `gitops` CLI:
+
+```bash
+PASSWORD=""
+echo -n $PASSWORD | gitops get bcrypt-hash
+$2a$10$OS5NJmPNEb13UgTOSKnMxOWlmS7mlxX77hv4yAiISvZ71Dc7IuN3q
+```
+
+## OIDC login
+
+Using the "Login with OIDC Provider" button:
+
+![Login page](/img/guides/setting-up-dex/oidc-login.png)
+
+We have to authorize the GitHub OAuth application:
+
+![GitHub OAuth page](/img/guides/setting-up-dex/github-auth.png)
+
+After that, grant access to Dex:
+
+![Dex grant access](/img/guides/setting-up-dex/dex-auth.png)
+
+Now we are logged in with our GitHub user and we can see all resources we have
+access to:
+
+![UI logged in](/img/guides/setting-up-dex/ui-logged-in.png)
diff --git a/website/versioned_docs/version-0.29.0/intro-weave-gitops.mdx b/website/versioned_docs/version-0.29.0/intro-weave-gitops.mdx
new file mode 100644
index 0000000000..06f1bc6fb1
--- /dev/null
+++ b/website/versioned_docs/version-0.29.0/intro-weave-gitops.mdx
@@ -0,0 +1,58 @@
+---
+title: Introducing Weave GitOps
+hide_title: true
+---
+
+# Introducing Weave GitOps
+
+> "GitOps is the best thing since configuration as code. Git changed how we collaborate, but declarative configuration is the key to dealing with infrastructure at scale, and sets the stage for the next generation of management tools"
+
+- Kelsey Hightower, Staff Developer Advocate, Google.