website: fix broken links

Schema API is unclear, Author API is more clear the API is intended for
component authors.

.cspell.json

@@ -0,0 +1,163 @@
+{
+  "version": "0.2",
+  "language": "en",
+  "enableFiletypes": [
+    "mdx"
+  ],
+  "words": [
+    "admissionregistration",
+    "apiextensions",
+    "applicationset",
+    "argoproj",
+    "authcode",
+    "authorizationpolicies",
+    "authpolicy",
+    "authproxy",
+    "authroutes",
+    "buildplan",
+    "cainjector",
+    "CAROOT",
+    "certificaterequests",
+    "certificatesigningrequests",
+    "clsx",
+    "clusterissuer",
+    "clusterissuers",
+    "clusterrole",
+    "clusterrolebinding",
+    "configmap",
+    "cookiesecret",
+    "coredns",
+    "corev",
+    "CRD's",
+    "crds",
+    "creds",
+    "crossplane",
+    "cuecontext",
+    "cuelang",
+    "customresourcedefinition",
+    "daemonset",
+    "destinationrules",
+    "devicecode",
+    "dnsmasq",
+    "dscacheutil",
+    "entgo",
+    "envoyfilters",
+    "errgroup",
+    "fctr",
+    "fieldmaskpb",
+    "flushcache",
+    "gatewayclasses",
+    "gendoc",
+    "ggnpl",
+    "ghaction",
+    "gitops",
+    "godoc",
+    "golangci",
+    "goreleaser",
+    "grpcreflect",
+    "grpcroutes",
+    "grpcurl",
+    "holos",
+    "holoslogger",
+    "horizontalpodautoscaler",
+    "httpbin",
+    "httproute",
+    "httproutes",
+    "Infima",
+    "isatty",
+    "istiod",
+    "jbrx",
+    "jeffmccune",
+    "jetstack",
+    "Jsonnet",
+    "killall",
+    "kubeadm",
+    "kubeconfig",
+    "kubelogin",
+    "Kustomization",
+    "Kustomizations",
+    "kustomize",
+    "ldflags",
+    "leaderelection",
+    "libnss",
+    "loadbalancer",
+    "mattn",
+    "mccutchen",
+    "mindmap",
+    "mktemp",
+    "msqbn",
+    "mtls",
+    "Multicluster",
+    "mutatingwebhookconfiguration",
+    "mxcl",
+    "myhostname",
+    "nameserver",
+    "organizationconnect",
+    "orgid",
+    "otelconnect",
+    "Parentspanid",
+    "pcjc",
+    "peerauthentications",
+    "pflag",
+    "pipefail",
+    "PKCE",
+    "platformconnect",
+    "poddisruptionbudget",
+    "podinfo",
+    "portmapping",
+    "promhttp",
+    "protobuf",
+    "protojson",
+    "proxyconfigs",
+    "Pulumi",
+    "putenv",
+    "qjbp",
+    "quickstart",
+    "referencegrant",
+    "referencegrants",
+    "requestauthentications",
+    "retryable",
+    "rolebinding",
+    "ropc",
+    "seccomp",
+    "SECRETKEY",
+    "secretstores",
+    "serverlb",
+    "serverside",
+    "serviceaccount",
+    "serviceentries",
+    "spanid",
+    "spiffe",
+    "startupapicheck",
+    "stefanprodan",
+    "structpb",
+    "subjectaccessreviews",
+    "svclb",
+    "systemconnect",
+    "tablewriter",
+    "Tiltfile",
+    "timestamppb",
+    "Timoni",
+    "tlsclientconfig",
+    "tokencache",
+    "Tokener",
+    "Traceid",
+    "traefik",
+    "uibutton",
+    "untar",
+    "Upsert",
+    "urandom",
+    "usecases",
+    "userconnect",
+    "userdata",
+    "userservice",
+    "validatingwebhookconfiguration",
+    "virtualservices",
+    "wasmplugins",
+    "workloadentries",
+    "workloadgroups",
+    "zerolog",
+    "zitadel",
+    "ztunnel"
+  ]
+}

.github/workflows.disabed/test.yaml

@@ -41,10 +41,6 @@ jobs:
         run: |
           set -x
           make tools
-          make buf
-          go generate ./...
-          make frontend
-          go mod tidy
 
       - name: Test
         run: ./scripts/test

.github/workflows/dev-deploy.yaml

@@ -0,0 +1,57 @@
+name: Dev Deploy
+
+on:
+  push:
+    branches: ['main', 'dev-deploy']
+
+jobs:
+  deploy:
+    name: Deploy
+    runs-on: ubuntu-latest
+    steps:
+      ## Not needed on ubuntu-latest
+      # - name: Provide GPG and Git
+      #   run: sudo apt update && sudo apt -qq -y install gnupg git curl zip unzip tar bzip2 make jq
+
+      ## Not needed on ubuntu-latest
+      # - name: Provide Holos Dependencies
+      #   run: |
+      #     sudo mkdir -p -m 755 /etc/apt/keyrings
+      #     curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
+      #     sudo chmod 644 /etc/apt/keyrings/kubernetes-apt-keyring.gpg
+      #     echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
+      #     sudo chmod 644 /etc/apt/sources.list.d/kubernetes.list
+      #     sudo apt update
+      #     sudo apt install -qq -y kubectl
+      #     curl -fsSL -o-  https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
+
+      # Must come after git executable is provided
+      - name: Checkout
+        uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+
+      - uses: actions/setup-go@v5
+        with:
+          go-version: '1.22.x'
+
+      - uses: ko-build/setup-ko@v0.7
+        env:
+          KO_DOCKER_REPO: quay.io/holos-run/holos
+
+      - name: Setup SSH
+        run: |
+          mkdir -p ~/.ssh
+          echo "${{ secrets.DEPLOY_SSH_PRIVATE_KEY }}" > ~/.ssh/id_ed25519
+          chmod 600 ~/.ssh/id_ed25519
+          ssh-keyscan github.com >> ~/.ssh/known_hosts
+          git config --global user.name "github-actions[bot]"
+          git config --global user.email "github-actions[bot]@users.noreply.github.com"
+
+      - name: make dev-deploy
+        env:
+          auth_user: holos-run+pusher
+          auth_token: ${{ secrets.QUAY_TOKEN }}
+        run: |
+          echo "${auth_token}" | ko login quay.io --username "${auth_user}" --password-stdin
+          make dev-deploy

.github/workflows/golangci-lint.yaml

@@ -0,0 +1,30 @@
+name: golangci-lint
+on:
+  push:
+    branches:
+      - main
+      - test
+  pull_request:
+    types: [opened, synchronize]
+
+permissions:
+  # Required: allow read access to the content for analysis.
+  contents: read
+  # Optional: allow read access to pull request. Use with `only-new-issues` option.
+  pull-requests: read
+  # Optional: allow write access to checks to allow the action to annotate code in the PR.
+  checks: write
+
+jobs:
+  golangci:
+    name: lint
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-go@v5
+        with:
+          go-version: stable
+      - name: golangci-lint
+        uses: golangci/golangci-lint-action@v6
+        with:
+          version: v1.60

.github/workflows/lint.yaml

@@ -13,9 +13,9 @@ permissions:
   contents: read
 
 jobs:
-  golangci:
+  lint:
     name: lint
-    runs-on: gha-rs
+    runs-on: ubuntu-latest
     steps:
       - name: Checkout code
         uses: actions/checkout@v4
@@ -30,20 +30,13 @@ jobs:
         with:
           go-version: stable
 
-      - name: Install Packages
-        run: sudo apt update && sudo apt -qq -y install git curl zip unzip tar bzip2 make
+      ## Not needed on ubuntu-latest
+      # - name: Install Packages
+      #   run: sudo apt update && sudo apt -qq -y install git curl zip unzip tar bzip2 make
 
       - name: Install Tools
-        run: |
-          set -x
-          make tools
-          make buf
-          go generate ./...
-          make frontend
-          go mod tidy
+        run: make tools
 
-      - name: golangci-lint
-        uses: golangci/golangci-lint-action@v4
-        with:
-          version: latest
-          skip-pkg-cache: true
+      - name: Lint
+        # golangci-lint runs in a separate workflow.
+        run: make lint -o golangci-lint

.github/workflows/release.yaml

@@ -12,11 +12,12 @@ permissions:
 
 jobs:
   goreleaser:
-    runs-on: gha-rs
+    runs-on: ubuntu-latest
     steps:
+      ## Not needed on ubuntu-latest
       # Must come before Checkout, otherwise goreleaser fails
-      - name: Provide GPG and Git
-        run: sudo apt update && sudo apt -qq -y install gnupg git curl zip unzip tar bzip2 make
+      # - name: Provide GPG and Git
+      #   run: sudo apt update && sudo apt -qq -y install gnupg git curl zip unzip tar bzip2 make
 
       # Must come after git executable is provided
       - name: Checkout
@@ -40,10 +41,6 @@ jobs:
         run: |
           set -x
           make tools
-          make buf
-          go generate ./...
-          make frontend
-          go mod tidy
 
       - name: Import GPG key
         uses: crazy-max/ghaction-import-gpg@v6
@@ -54,6 +51,9 @@ jobs:
       - name: List keys
         run: gpg -K
 
+      - name: Git diff
+        run: git diff
+
       - name: Run GoReleaser
         uses: goreleaser/goreleaser-action@v5
         with:

.gitignore

@@ -1,8 +1,14 @@
 /bin/
-vendor/
 .idea/
 coverage.out
 /dist/
 *.hold/
 /deploy/
 .vscode/
+tmp/
+.DS_*
+
+# In case we run through the tutorial in this directory.
+/holos-k3d/
+/holos-infra/
+node_modules/

.ko.yaml

@@ -0,0 +1,13 @@
+# Refer to https://ko.build/configuration/#overriding-go-build-settings
+builds:
+- id: holos
+  dir: .
+  main: ./cmd/holos
+  env:
+  - GOPRIVATE=github.com/holos-run/\*
+  ldflags:
+  - -s
+  - -w
+  - -X
+  # Makefile provides GIT_DETAIL and GIT_SUFFIX.
+  - github.com/holos-run/holos/version.GitDescribe={{.Env.GIT_DETAIL}}{{.Env.GIT_SUFFIX}}

Dockerfile

@@ -1,4 +1,4 @@
-FROM 271053619184.dkr.ecr.us-east-2.amazonaws.com/holos-run/container-images/debian:bullseye AS final
+FROM quay.io/holos-run/debian:bullseye AS final
 USER root
 WORKDIR /app
 ADD bin bin

LICENSE

@@ -0,0 +1,202 @@
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

Makefile

@@ -7,7 +7,7 @@ REPO_PATH=$(ORG_PATH)/$(PROJ)
 VERSION := $(shell cat version/embedded/major version/embedded/minor version/embedded/patch | xargs printf "%s.%s.%s")
 BIN_NAME := holos
 
-DOCKER_REPO=quay.io/openinfrastructure/holos
+DOCKER_REPO=quay.io/holos-run/holos
 IMAGE_NAME=$(DOCKER_REPO)
 
 $( shell mkdir -p bin)
@@ -16,10 +16,12 @@ $( shell mkdir -p bin)
 export PATH := $(PWD)/internal/frontend/holos/node_modules/.bin:$(PATH)
 
 GIT_COMMIT=$(shell git rev-parse HEAD)
+GIT_SUFFIX=$(shell test -n "`git status --porcelain`" && echo "-dirty" || echo "")
+GIT_DETAIL=$(shell git describe --tags HEAD)
 GIT_TREE_STATE=$(shell test -n "`git status --porcelain`" && echo "dirty" || echo "clean")
 BUILD_DATE=$(shell date -Iseconds)
 
-LD_FLAGS="-w -X ${ORG_PATH}/${PROJ}/version.GitCommit=${GIT_COMMIT} -X ${ORG_PATH}/${PROJ}/version.GitTreeState=${GIT_TREE_STATE} -X ${ORG_PATH}/${PROJ}/version.BuildDate=${BUILD_DATE}"
+LD_FLAGS="-w -X ${ORG_PATH}/${PROJ}/version.GitDescribe=${GIT_DETAIL}${GIT_SUFFIX} -X ${ORG_PATH}/${PROJ}/version.GitCommit=${GIT_COMMIT} -X ${ORG_PATH}/${PROJ}/version.GitTreeState=${GIT_TREE_STATE} -X ${ORG_PATH}/${PROJ}/version.BuildDate=${BUILD_DATE}"
 
 .PHONY: default
 default: test
@@ -46,33 +48,38 @@ bumpmajor: ## Bump the major version.
 show-version: ## Print the full version.
 	@echo $(VERSION)
 
+.PHONY: tag
+tag: ## Tag a release
+	git tag v$(VERSION)
+
 .PHONY: tidy
 tidy: ## Tidy go module.
 	go mod tidy
 
 .PHONY: fmt
 fmt: ## Format code.
-	cd docs/examples && cue fmt ./...
+	cd internal/generate/platforms && cue fmt ./...
 	go fmt ./...
 
 .PHONY: vet
 vet: ## Vet Go code.
 	go vet ./...
 
-.PHONY: gencue
-gencue: ## Generate CUE definitions
-	cd docs/examples && cue get go github.com/holos-run/holos/api/...
-
 .PHONY: generate
 generate: ## Generate code.
 	go generate ./...
 
 .PHONY: build
-build: generate frontend ## Build holos executable.
+build: ## Build holos executable.
 	@echo "building ${BIN_NAME} ${VERSION}"
 	@echo "GOPATH=${GOPATH}"
 	go build -trimpath -o bin/$(BIN_NAME) -ldflags $(LD_FLAGS) $(REPO_PATH)/cmd/$(BIN_NAME)
 
+linux: ## Build holos executable for tilt.
+	@echo "building ${BIN_NAME}.linux ${VERSION}"
+	@echo "GOPATH=${GOPATH}"
+	GOOS=linux go build -trimpath -o bin/$(BIN_NAME).linux -ldflags $(LD_FLAGS) $(REPO_PATH)/cmd/$(BIN_NAME)
+
 .PHONY: install
 install: build ## Install holos to GOPATH/bin
 	install bin/$(BIN_NAME) $(shell go env GOPATH)/bin/$(BIN_NAME)
@@ -85,10 +92,16 @@ clean: ## Clean executables.
 test: ## Run tests.
 	scripts/test
 
-.PHONY: lint
-lint: ## Run linters.
+.PHONY: golangci-lint
+golangci-lint:
 	golangci-lint run
 
+.PHONY: lint
+lint: golangci-lint ## Run linters.
+	buf lint
+	cd internal/frontend/holos && ng lint
+	./hack/cspell
+
 .PHONY: coverage
 coverage: test  ## Test coverage profile.
 	go tool cover   -html=coverage.out
@@ -97,39 +110,45 @@ coverage: test  ## Test coverage profile.
 snapshot:  ## Go release snapshot
 	goreleaser release --snapshot --clean
 
-.PHONY: buf
-buf: ## buf generate
-	cd service && buf mod update
-	buf generate
-
 .PHONY: tools
-tools: go-deps frontend-deps  ## install tool dependencies
+tools: go-deps frontend-deps website-deps ## install tool dependencies
 
 .PHONY: go-deps
 go-deps: ## tool versions pinned in tools.go
+	go install cuelang.org/go/cmd/cue
 	go install github.com/bufbuild/buf/cmd/buf
 	go install github.com/fullstorydev/grpcurl/cmd/grpcurl
 	go install google.golang.org/protobuf/cmd/protoc-gen-go
 	go install connectrpc.com/connect/cmd/protoc-gen-connect-go
-	go install honnef.co/go/tools/cmd/staticcheck@latest
+	go install honnef.co/go/tools/cmd/staticcheck
+	go install golang.org/x/tools/cmd/godoc
+	go install github.com/princjef/gomarkdoc/cmd/gomarkdoc
+	go install github.com/google/ko
 	# curl https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | bash
 
 .PHONY: frontend-deps
-frontend-deps: ## Setup npm and vite
+frontend-deps: ## Install Angular deps for go generate
 	cd internal/frontend/holos && npm install
-	cd internal/frontend/holos && npm install --save-dev @bufbuild/buf @connectrpc/protoc-gen-connect-es
-	cd internal/frontend/holos && npm install @connectrpc/connect @connectrpc/connect-web @bufbuild/protobuf
-	# https://github.com/connectrpc/connect-query-es/blob/1350b6f07b6aead81793917954bdb1cc3ce09df9/packages/protoc-gen-connect-query/README.md?plain=1#L23
-	cd internal/frontend/holos && npm install --save-dev @connectrpc/protoc-gen-connect-query @bufbuild/protoc-gen-es
-	cd internal/frontend/holos && npm install @connectrpc/connect-query @bufbuild/protobuf
 
+.PHONY: website-deps
+website-deps: ## Install Docusaurus deps for go generate
+	cd doc/website && npm install
 
-.PHONY: frontend
-frontend: buf
-	cd internal/frontend/holos && rm -rf dist
-	mkdir -p internal/frontend/holos/dist
-	cd internal/frontend/holos && ng build
-	touch internal/frontend/frontend.go
+.PHONY: image # refer to .ko.yaml as well
+image:  ## Container image build for workflows/publish.yaml
+	KO_DOCKER_REPO=$(DOCKER_REPO) GIT_DETAIL=$(GIT_DETAIL) GIT_SUFFIX=$(GIT_SUFFIX) ko build --platform=all --bare ./cmd/holos --tags $(GIT_DETAIL)$(GIT_SUFFIX) --tags latest
+
+.PHONY: prod-deploy
+prod-deploy: install image  ## deploy to PROD
+	GIT_DETAIL=$(GIT_DETAIL) GIT_SUFFIX=$(GIT_SUFFIX) bash ./hack/deploy
+
+.PHONY: dev-deploy
+dev-deploy: install image  ## deploy to dev
+	GIT_DETAIL=$(GIT_DETAIL) GIT_SUFFIX=$(GIT_SUFFIX) bash ./hack/deploy-dev
+
+.PHONY: website
+website: ## Build website
+	./hack/build-website
 
 .PHONY: help
 help:  ## Display this help menu.

README.md

@@ -0,0 +1,35 @@
+## Holos - A Holistic Development Platform
+
+<img width="50%"
+align="right"
+style="display: block; margin: 40px auto;"
+src="https://openinfrastructure.co/blog/2016/02/27/logo/logorectangle.png">
+
+Building and maintaining a software development platform is a complex and time
+consuming endeavour.  Organizations often dedicate a team of 3-4 who need 6-12
+months to build the platform.
+
+Holos is a tool and a reference platform to reduce the complexity and speed up
+the process of building a modern, cloud native software development platform.
+
+- **Accelerate new projects** - Reduce time to market and operational complexity by starting your new project on top of the Holos reference platform.
+- **Modernize existing projects** - Incrementally incorporate your existing platform services into Holos for simpler integration.
+- **Unified configuration model** - Increase safety and reduce the risk of config changes with CUE.
+- **First class Helm and Kustomize support** - Leverage and reuse your existing investment in existing configuration tools such as Helm and Kustomize.
+- **Modern Authentication and Authorization** - Holos seamlessly integrates platform identity and access management with zero-trust beyond corp style authorization policy.
+
+## Quick Installation
+
+```console
+go install github.com/holos-run/holos/cmd/holos@latest
+```
+
+## Docs and Support
+
+The documentation for developing and using Holos is available at: https://holos.run
+
+For discussion and support, [open a discussion](https://github.com/orgs/holos-run/discussions/new/choose).
+
+## License
+
+Holos is licensed under Apache 2.0 as found in the [LICENSE file](LICENSE).

Tiltfile

@@ -1,5 +1,5 @@
 # -*- mode: Python -*-
-# This Tiltfile manages a Go project with live leload in Kubernetes
+# This Tiltfile manages a Go project with live reload in Kubernetes
 
 listen_port = 3000
 metrics_port = 9090
@@ -8,56 +8,21 @@ metrics_port = 9090
 if os.getenv('TILT_WRAPPER') != '1':
     fail("could not run, ./hack/tilt/bin/tilt was not used to start tilt")
 
-# AWS Account to work in
-aws_account = '271053619184'
-aws_region = 'us-east-2'
-
 # Resource ids
-holos_backend = 'Holos Backend'
-pg_admin = 'pgAdmin'
-pg_cluster = 'PostgresCluster'
-pg_svc = 'Database Pod'
+holos_backend = 'Holos Server'
 compile_id = 'Go Build'
-auth_id = 'Auth Policy'
-lint_id = 'Run Linters'
-tests_id = 'Run Tests'
-
-# PostgresCluster resource name in k8s
-pg_cluster_name = 'holos'
-# Database name inside the PostgresCluster
-pg_database_name = 'holos'
-# PGAdmin name
-pg_admin_name = 'pgadmin'
 
 # Default Registry.
 # See: https://github.com/tilt-dev/tilt.build/blob/master/docs/choosing_clusters.md#manual-configuration
 # Note, Tilt will append the image name to the registry uri path
-default_registry('{account}.dkr.ecr.{region}.amazonaws.com/holos-run/holos-server'.format(account=aws_account, region=aws_region))
+# default_registry('{account}.dkr.ecr.{region}.amazonaws.com/holos-run/holos'.format(account=aws_account, region=aws_region))
 
 # Set a name prefix specific to the user.  Multiple developers share the tilt-holos namespace.
 developer = os.getenv('USER')
 holos_server = 'holos'
-# See ./hack/tilt/bin/tilt
-namespace = os.getenv('NAMESPACE')
-# We always develop against the k1 cluster.
+
+# We always develop against the k3d-workload cluster
 os.putenv('KUBECONFIG', os.path.abspath('./hack/tilt/kubeconfig'))
-# The context defined in ./hack/tilt/kubeconfig
-allow_k8s_contexts('sso@k1')
-allow_k8s_contexts('sso@k2')
-allow_k8s_contexts('sso@k3')
-allow_k8s_contexts('sso@k4')
-allow_k8s_contexts('sso@k5')
-# PG db connection for localhost -> k8s port-forward
-os.putenv('PGHOST', 'localhost')
-os.putenv('PGPORT', '15432')
-# We always develop in the dev aws account.
-os.putenv('AWS_CONFIG_FILE', os.path.abspath('./hack/tilt/aws.config'))
-os.putenv('AWS_ACCOUNT', aws_account)
-os.putenv('AWS_DEFAULT_REGION', aws_region)
-os.putenv('AWS_PROFILE', 'dev-holos')
-os.putenv('AWS_SDK_LOAD_CONFIG', '1')
-# Authenticate to AWS ECR when tilt up is run by the developer
-local_resource('AWS Credentials', './hack/tilt/aws-login.sh', auto_init=True)
 
 # Extensions are open-source, pre-packaged functions that extend Tilt
 #
@@ -81,8 +46,8 @@ developer_paths = [
     './service/holos',
 ]
 
-# Builds the holos-server executable
-local_resource(compile_id, 'make build', deps=developer_paths)
+# Builds the holos executable GOOS=linux
+local_resource(compile_id, 'make linux', deps=developer_paths)
 
 # Build Docker image
 #   Tilt will automatically associate image builds with the resource(s)
@@ -91,84 +56,33 @@ local_resource(compile_id, 'make build', deps=developer_paths)
 #   More info: https://docs.tilt.dev/api.html#api.docker_build
 #
 docker_build_with_restart(
-    'holos',
+    'k3d-registry.holos.localhost:5100/holos',
     context='.',
     entrypoint=[
-        '/app/bin/holos',
+        '/app/bin/holos.linux',
         'server',
-        '--listen-port={}'.format(listen_port),
-        '--oidc-issuer=https://login.ois.run',
-        '--oidc-audience=262096764402729854@holos_platform',
-        '--log-level=debug',
-        '--metrics-port={}'.format(metrics_port),
+        '--log-format=text',
+        '--oidc-issuer=https://login.holos.run',
+        '--oidc-audience=275804490387516853@holos_quickstart', # auth proxy
+        '--oidc-audience=270319630705329162@holos_platform', # holos cli
     ],
-    dockerfile='./hack/tilt/Dockerfile',
+    dockerfile='./Dockerfile',
     only=['./bin'],
     # (Recommended) Updating a running container in-place
     # https://docs.tilt.dev/live_update_reference.html
     live_update=[
         # Sync files from host to container
-        sync('./bin', '/app/bin'),
-        # Wait for aws-login https://github.com/tilt-dev/tilt/issues/3048
-        sync('./tilt/aws-login.last', '/dev/null'),
-        # Execute commands in the container when paths change
-        # run('/app/hack/codegen.sh', trigger=['./app/api'])
+        sync('./bin/', '/app/bin/'),
     ],
 )
 
-
-# Run local commands
-#   Local commands can be helpful for one-time tasks like installing
-#   project prerequisites. They can also manage long-lived processes
-#   for non-containerized services or dependencies.
-#
-#   More info: https://docs.tilt.dev/local_resource.html
-#
-# local_resource('install-helm',
-#                cmd='which helm > /dev/null || brew install helm',
-#                # `cmd_bat`, when present, is used instead of `cmd` on Windows.
-#                cmd_bat=[
-#                    'powershell.exe',
-#                    '-Noninteractive',
-#                    '-Command',
-#                    '& {if (!(Get-Command helm -ErrorAction SilentlyContinue)) {scoop install helm}}'
-#                ]
-# )
-
-# Teach tilt about our custom resources (Note, this may be intended for workloads)
-# k8s_kind('authorizationpolicy')
-# k8s_kind('requestauthentication')
-# k8s_kind('virtualservice')
-k8s_kind('pgadmin')
-
-
 # Troubleshooting
 def resource_name(id):
     print('resource: {}'.format(id))
     return id.name
 
-
 workload_to_resource_function(resource_name)
 
-# Apply Kubernetes manifests
-#   Tilt will build & push any necessary images, re-deploying your
-#   resources as they change.
-#
-#   More info: https://docs.tilt.dev/api.html#api.k8s_yaml
-#
-
-def holos_yaml():
-    """Return a k8s Deployment personalized for the developer."""
-    k8s_yaml_template = str(read_file('./hack/tilt/k8s.yaml'))
-    return k8s_yaml_template.format(
-        name=holos_server,
-        developer=developer,
-        namespace=namespace,
-        listen_port=listen_port,
-        metrics_port=metrics_port,
-        tz=os.getenv('TZ'),
-    )
-
 # Customize a Kubernetes resource
 #   By default, Kubernetes resource names are automatically assigned
 #   based on objects in the YAML manifests, e.g. Deployment name.
@@ -179,133 +93,18 @@ def holos_yaml():
 #
 #   More info: https://docs.tilt.dev/api.html#api.k8s_resource
 #
-k8s_yaml(blob(holos_yaml()))
+k8s_yaml(blob(str(read_file('./hack/tilt/k8s/dev-holos-app/deployment.yaml'))))
 
 # Backend server process
 k8s_resource(
     workload=holos_server,
     new_name=holos_backend,
-    objects=[
-        '{}:serviceaccount'.format(holos_server),
-        '{}:servicemonitor'.format(holos_server),
-    ],
+    objects=[],
     resource_deps=[compile_id],
     links=[
-        link('https://{}.app.dev.k2.holos.run/ui/'.format(developer), "Holos Web UI")
-    ],
-)
-
-
-# AuthorizationPolicy - Beyond Corp functionality
-k8s_resource(
-    new_name=auth_id,
-    objects=[
-      '{}:virtualservice'.format(holos_server),
+        link('https://app.holos.localhost/ui/'.format(developer), "Holos Web UI")
     ],
 )
 
 # Database
-# Note: Tilt confuses the backup pods with the database server pods, so this code is careful to tease the pods
-# apart so logs are streamed correctly.
-# See: https://github.com/tilt-dev/tilt.specs/blob/master/resource_assembly.md
-
-# pgAdmin Web UI
-k8s_resource(
-    workload=pg_admin_name,
-    new_name=pg_admin,
-    port_forwards=[
-        port_forward(15050, 5050, pg_admin),
-    ],
-)
-
-# Disabled because these don't group resources nicely
-# k8s_kind('postgrescluster')
-
-# Postgres database in-cluster
-k8s_resource(
-    new_name=pg_cluster,
-    objects=['holos:postgrescluster'],
-)
-
-# Needed to select the database by label
-# https://docs.tilt.dev/api.html#api.k8s_custom_deploy
-k8s_custom_deploy(
-    pg_svc,
-    apply_cmd=['./hack/tilt/k8s-get-db-sts', pg_cluster_name],
-    delete_cmd=['echo', 'Skipping delete.  Object managed by custom resource.'],
-    deps=[],
-)
-k8s_resource(
-    pg_svc,
-    port_forwards=[
-        port_forward(15432, 5432, 'psql'),
-    ],
-    resource_deps=[pg_cluster]
-)
-
-
-# Run tests
-local_resource(
-    tests_id,
-    'make test',
-    allow_parallel=True,
-    auto_init=False,
-    deps=developer_paths,
-)
-
-# Run linter
-local_resource(
-    lint_id,
-    'make lint',
-    allow_parallel=True,
-    auto_init=False,
-    deps=developer_paths,
-)
-
-# UI Buttons for helpful things.
-# Icons: https://fonts.google.com/icons
-os.putenv("GH_FORCE_TTY", "80%")
-cmd_button(
-    '{}:go-test-failfast'.format(tests_id),
-    argv=['./hack/tilt/go-test-failfast'],
-    resource=tests_id,
-    icon_name='quiz',
-    text='Fail Fast',
-)
-cmd_button(
-    '{}:issues'.format(holos_server),
-    argv=['./hack/tilt/gh-issues'],
-    resource=holos_backend,
-    icon_name='folder_data',
-    text='Issues',
-)
-cmd_button(
-    '{}:gh-issue-view'.format(holos_server),
-    argv=['./hack/tilt/gh-issue-view'],
-    resource=holos_backend,
-    icon_name='task',
-    text='View Issue',
-)
-cmd_button(
-    '{}:get-pgdb-creds'.format(holos_server),
-    argv=['./hack/tilt/get-pgdb-creds', pg_cluster_name, pg_database_name],
-    resource=pg_svc,
-    icon_name='lock_open_right',
-    text='DB Creds',
-)
-cmd_button(
-    '{}:get-pgdb-creds'.format(pg_admin_name),
-    argv=['./hack/tilt/get-pgdb-creds', pg_cluster_name, pg_database_name],
-    resource=pg_admin,
-    icon_name='lock_open_right',
-    text='DB Creds',
-)
-cmd_button(
-    '{}:get-pgadmin-creds'.format(pg_admin_name),
-    argv=['./hack/tilt/get-pgadmin-creds', pg_admin_name],
-    resource=pg_admin,
-    icon_name='lock_open_right',
-    text='pgAdmin Login',
-)
-
 print("✨ Tiltfile evaluated")

api/author/v1alpha3/definitions.go

@@ -0,0 +1,163 @@
+// Package v1alpha3 contains CUE definitions intended as convenience wrappers
+// around the core data types defined in package core.  The purpose of these
+// wrappers is to make life easier for platform engineers by reducing boiler
+// plate code and generating component build plans in a consistent manner.
+package v1alpha3
+
+import (
+	core "github.com/holos-run/holos/api/core/v1alpha3"
+	"google.golang.org/protobuf/types/known/structpb"
+)
+
+//go:generate ../../../hack/gendoc
+
+// Component represents the fields common the different kinds of component.  All
+// components have a name, support mixing in resources, and produce a BuildPlan.
+type ComponentFields struct {
+	// Name represents the Component name.
+	Name string
+	// Resources are kubernetes api objects to mix into the output.
+	Resources map[string]any
+	// ArgoConfig represents the ArgoCD GitOps configuration for this Component.
+	ArgoConfig ArgoConfig
+	// BuildPlan represents the derived BuildPlan for the Holos cli to render.
+	BuildPlan core.BuildPlan
+}
+
+// Helm provides a BuildPlan via the Output field which contains one HelmChart
+// from package core.  Useful as a convenience wrapper to render a HelmChart
+// with optional mix-in resources and Kustomization post-processing.
+type Helm struct {
+	ComponentFields `json:",inline"`
+
+	// Version represents the chart version.
+	Version string
+	// Namespace represents the helm namespace option when rendering the chart.
+	Namespace string
+
+	// Repo represents the chart repository
+	Repo struct {
+		Name string `json:"name"`
+		URL  string `json:"url"`
+	}
+
+	// Values represents data to marshal into a values.yaml for helm.
+	Values interface{} `cue:"{...}"`
+
+	// Chart represents the derived HelmChart for inclusion in the BuildPlan
+	// Output field value.  The default HelmChart field values are derived from
+	// other Helm field values and should be sufficient for most use cases.
+	Chart core.HelmChart
+
+	// EnableKustomizePostProcessor processes helm output with kustomize if true.
+	EnableKustomizePostProcessor bool `cue:"true | *false"`
+
+	// KustomizeFiles represents additional files to include in a Kustomization
+	// resources list.  Useful to patch helm output.  The implementation is a
+	// struct with filename keys and structs as values.  Holos encodes the struct
+	// value to yaml then writes the result to the filename key.  Component
+	// authors may then reference the filename in the kustomization.yaml resources
+	// or patches lists.
+	// Requires EnableKustomizePostProcessor: true.
+	KustomizeFiles map[string]any `cue:"{[string]: {...}}"`
+
+	// KustomizePatches represents patches to apply to the helm output.  Requires
+	// EnableKustomizePostProcessor: true.
+	KustomizePatches map[core.InternalLabel]any `cue:"{[string]: {...}}"`
+
+	// KustomizeResources represents additional resources files to include in the
+	// kustomize resources list.
+	KustomizeResources map[string]any `cue:"{[string]: {...}}"`
+}
+
+// Kustomize provides a BuildPlan via the Output field which contains one
+// KustomizeBuild from package core.
+type Kustomize struct {
+	ComponentFields `json:",inline"`
+	// Kustomization represents the kustomize build plan for holos to render.
+	Kustomization core.KustomizeBuild
+}
+
+// Kubernetes provides a BuildPlan via the Output field which contains inline
+// API Objects provided directly from CUE.
+type Kubernetes struct {
+	ComponentFields `json:",inline"`
+	// Objects represents the kubernetes api objects for the Component.
+	Objects core.KubernetesObjects
+}
+
+// ArgoConfig represents the ArgoCD GitOps configuration for a Component.
+// Useful to define once at the root of the Platform configuration and reuse
+// across all Components.
+type ArgoConfig struct {
+	// Enabled causes holos to render an ArgoCD Application resource for GitOps if true.
+	Enabled bool `cue:"true | *false"`
+	// ClusterName represents the cluster within the platform the Application
+	// resource is intended for.
+	ClusterName string
+	// DeployRoot represents the path from the git repository root to the `deploy`
+	// rendering output directory.  Used as a prefix for the
+	// Application.spec.source.path field.
+	DeployRoot string `cue:"string | *\".\""`
+	// RepoURL represents the value passed to the Application.spec.source.repoURL
+	// field.
+	RepoURL string
+	// TargetRevision represents the value passed to the
+	// Application.spec.source.targetRevision field.  Defaults to the branch named
+	// main.
+	TargetRevision string `cue:"string | *\"main\""`
+	// AppProject represents the ArgoCD Project to associate the Application with.
+	AppProject string `cue:"string | *\"default\""`
+}
+
+// Cluster represents a cluster managed by the Platform.
+type Cluster struct {
+	// Name represents the cluster name, for example "east1", "west1", or
+	// "management".
+	Name string `json:"name"`
+	// Primary represents if the cluster is marked as the primary among a set of
+	// candidate clusters.  Useful for promotion of database leaders.
+	Primary bool `json:"primary" cue:"true | *false"`
+}
+
+// Fleet represents a named collection of similarly configured Clusters.  Useful
+// to segregate workload clusters from their management cluster.
+type Fleet struct {
+	Name string `json:"name"`
+	// Clusters represents a mapping of Clusters by their name.
+	Clusters map[string]Cluster `json:"clusters" cue:"{[Name=_]: name: Name}"`
+}
+
+// StandardFleets represents the standard set of Clusters in a Platform
+// segmented into Fleets by their purpose.  The management Fleet contains a
+// single Cluster, for example a GKE autopilot cluster with no workloads
+// deployed for reliability and cost efficiency.  The workload Fleet contains
+// all other Clusters which contain workloads and sync Secrets from the
+// management cluster.
+type StandardFleets struct {
+	// Workload represents a Fleet of zero or more workload Clusters.
+	Workload Fleet `json:"workload" cue:"{name: \"workload\"}"`
+	// Management represents a Fleet with one Cluster named management.
+	Management Fleet `json:"management" cue:"{name: \"management\"}"`
+}
+
+// Platform is a convenience structure to produce a core Platform specification
+// value in the Output field.  Useful to collect components at the root of the
+// Platform configuration tree as a struct, which are automatically converted
+// into a list for the core Platform spec output.
+type Platform struct {
+	// Name represents the Platform name.
+	Name string `cue:"string | *\"holos\""`
+	// Components is a structured map of components to manage by their name.
+	Components map[string]core.PlatformSpecComponent
+	// Model represents the Platform model holos gets from from the
+	// PlatformService.GetPlatform rpc method and provides to CUE using a tag.
+	Model structpb.Struct `cue:"{...}"`
+	// Output represents the core Platform spec for the holos cli to iterate over
+	// and render each listed Component, injecting the Model.
+	Output core.Platform
+	// Domain represents the primary domain the Platform operates in.  This field
+	// is intended as a sensible default for component authors to reference and
+	// platform operators to define.
+	Domain string `cue:"string | *\"holos.localhost\""`
+}

api/core/v1alpha2/apiobjects.go

@@ -0,0 +1,44 @@
+package v1alpha2
+
+import "google.golang.org/protobuf/types/known/structpb"
+
+// Label is an arbitrary unique identifier internal to holos itself.  The holos
+// cli is expected to never write a Label value to rendered output files,
+// therefore use a [Label] then the identifier must be unique and internal.
+// Defined as a type for clarity and type checking.
+//
+// A Label is useful to convert a CUE struct to a list, for example producing a list of [APIObject] resources from an [APIObjectMap].  A CUE struct using
+// Label keys is guaranteed to not lose data when rendering output because a
+// Label is expected to never be written to the final output.
+type Label string
+
+// Kind is a kubernetes api object kind. Defined as a type for clarity and type checking.
+type Kind string
+
+// APIObject represents the most basic generic form of a single kubernetes api
+// object.  Represented as a JSON object internally for compatibility between
+// tools, for example loading from CUE.
+type APIObject structpb.Struct
+
+// APIObjectMap represents the marshalled yaml representation of kubernetes api
+// objects.  Do not produce an APIObjectMap directly, instead use [APIObjects]
+// to produce the marshalled yaml representation from CUE data, then provide the
+// result to [HolosComponent].
+type APIObjectMap map[Kind]map[Label]string
+
+// APIObjects represents Kubernetes API objects defined directly from CUE code.
+// Useful to mix in resources to any kind of [HolosComponent], for example
+// adding an ExternalSecret resource to a [HelmChart].
+//
+// [Kind] must be the resource kind, e.g. Deployment or Service.
+//
+// [Label] is an arbitrary internal identifier to uniquely identify the resource
+// within the context of a `holos` command.  Holos will never write the
+// intermediate label to rendered output.
+//
+// Refer to [HolosComponent] which accepts an [APIObjectMap] field provided by
+// [APIObjects].
+type APIObjects struct {
+	APIObjects   map[Kind]map[Label]APIObject `json:"apiObjects"`
+	APIObjectMap APIObjectMap                 `json:"apiObjectMap"`
+}

api/core/v1alpha2/buildplan.go

@@ -0,0 +1,96 @@
+package v1alpha2
+
+// FilePath represents a file path.
+type FilePath string
+
+// FileContent represents file contents.
+type FileContent string
+
+// FileContentMap represents a mapping of file paths to file contents.  Paths
+// are relative to the `holos` output "deploy" directory, and may contain
+// sub-directories.
+type FileContentMap map[FilePath]FileContent
+
+// BuildPlan represents a build plan for the holos cli to execute.  The purpose
+// of a BuildPlan is to define one or more [HolosComponent] kinds.  For example a
+// [HelmChart], [KustomizeBuild], or [KubernetesObjects].
+//
+// A BuildPlan usually has an additional empty [KubernetesObjects] for the
+// purpose of using the [HolosComponent] DeployFiles field to deploy an ArgoCD
+// or Flux gitops resource for the holos component.
+type BuildPlan struct {
+	Kind       string        `json:"kind" cue:"\"BuildPlan\""`
+	APIVersion string        `json:"apiVersion" cue:"string | *\"v1alpha2\""`
+	Spec       BuildPlanSpec `json:"spec"`
+}
+
+// BuildPlanSpec represents the specification of the build plan.
+type BuildPlanSpec struct {
+	// Disabled causes the holos cli to take no action over the [BuildPlan].
+	Disabled bool `json:"disabled,omitempty"`
+	// Components represents multiple [HolosComponent] kinds to manage.
+	Components BuildPlanComponents `json:"components,omitempty"`
+}
+
+type BuildPlanComponents struct {
+	Resources             map[Label]KubernetesObjects `json:"resources,omitempty"`
+	KubernetesObjectsList []KubernetesObjects         `json:"kubernetesObjectsList,omitempty"`
+	HelmChartList         []HelmChart                 `json:"helmChartList,omitempty"`
+	KustomizeBuildList    []KustomizeBuild            `json:"kustomizeBuildList,omitempty"`
+}
+
+// HolosComponent defines the fields common to all holos component kinds.  Every
+// holos component kind should embed HolosComponent.
+type HolosComponent struct {
+	// Kind is a string value representing the resource this object represents.
+	Kind string `json:"kind"`
+	// APIVersion represents the versioned schema of this representation of an object.
+	APIVersion string `json:"apiVersion" cue:"string | *\"v1alpha2\""`
+	// Metadata represents data about the holos component such as the Name.
+	Metadata Metadata `json:"metadata"`
+
+	// APIObjectMap holds the marshalled representation of api objects.  Useful to
+	// mix in resources to each HolosComponent type, for example adding an
+	// ExternalSecret to a HelmChart HolosComponent.  Refer to [APIObjects].
+	APIObjectMap APIObjectMap `json:"apiObjectMap,omitempty"`
+
+	// DeployFiles represents file paths relative to the cluster deploy directory
+	// with the value representing the file content.  Intended for defining the
+	// ArgoCD Application resource or Flux Kustomization resource from within CUE,
+	// but may be used to render any file related to the build plan from CUE.
+	DeployFiles FileContentMap `json:"deployFiles,omitempty"`
+
+	// Kustomize represents a kubectl kustomize build post-processing step.
+	Kustomize `json:"kustomize,omitempty"`
+
+	// Skip causes holos to take no action regarding this component.
+	Skip bool `json:"skip" cue:"bool | *false"`
+}
+
+// Metadata represents data about the holos component such as the Name.
+type Metadata struct {
+	// Name represents the name of the holos component.
+	Name string `json:"name"`
+	// Namespace is the primary namespace of the holos component.  A holos
+	// component may manage resources in multiple namespaces, in this case
+	// consider setting the component namespace to default.
+	//
+	// This field is optional because not all resources require a namespace,
+	// particularly CRD's and DeployFiles functionality.
+	// +optional
+	Namespace string `json:"namespace,omitempty"`
+}
+
+// Kustomize represents resources necessary to execute a kustomize build.
+// Intended for at least two use cases:
+//
+//  1. Process a [KustomizeBuild] [HolosComponent] which represents raw yaml
+//     file resources in a holos component directory.
+//  2. Post process a [HelmChart] [HolosComponent] to inject istio, patch jobs,
+//     add custom labels, etc...
+type Kustomize struct {
+	// KustomizeFiles holds file contents for kustomize, e.g. patch files.
+	KustomizeFiles FileContentMap `json:"kustomizeFiles,omitempty"`
+	// ResourcesFile is the file name used for api objects in kustomization.yaml
+	ResourcesFile string `json:"resourcesFile,omitempty"`
+}

api/core/v1alpha2/constants.go

@@ -0,0 +1,11 @@
+package v1alpha2
+
+const (
+	APIVersion    = "v1alpha2"
+	BuildPlanKind = "BuildPlan"
+	HelmChartKind = "HelmChart"
+	// ChartDir is the directory name created in the holos component directory to cache a chart.
+	ChartDir = "vendor"
+	// ResourcesFile is the file name used to store component output when post-processing with kustomize.
+	ResourcesFile = "resources.yaml"
+)

api/core/v1alpha2/core.go

@@ -0,0 +1,44 @@
+package v1alpha2
+
+import "google.golang.org/protobuf/types/known/structpb"
+
+type PlatformMetadata struct {
+	// Name represents the Platform name.
+	Name string `json:"name"`
+}
+
+// Platform represents a platform to manage.  A Platform resource informs holos
+// which components to build.  The platform resource also acts as a container
+// for the platform model form values provided by the PlatformService.  The
+// primary use case is to collect the cluster names, cluster types, platform
+// model, and holos components to build into one resource.
+type Platform struct {
+	// Kind is a string value representing the resource this object represents.
+	Kind string `json:"kind" cue:"\"Platform\""`
+	// APIVersion represents the versioned schema of this representation of an object.
+	APIVersion string `json:"apiVersion" cue:"string | *\"v1alpha2\""`
+	// Metadata represents data about the object such as the Name.
+	Metadata PlatformMetadata `json:"metadata"`
+
+	// Spec represents the specification.
+	Spec PlatformSpec `json:"spec"`
+}
+
+// PlatformSpec represents the specification of a Platform.  Think of a platform
+// specification as a list of platform components to apply to a list of
+// kubernetes clusters combined with the user-specified Platform Model.
+type PlatformSpec struct {
+	// Model represents the platform model holos gets from from the
+	// PlatformService.GetPlatform rpc method and provides to CUE using a tag.
+	Model structpb.Struct `json:"model"`
+	// Components represents a list of holos components to manage.
+	Components []PlatformSpecComponent `json:"components"`
+}
+
+// PlatformSpecComponent represents a holos component to build or render.
+type PlatformSpecComponent struct {
+	// Path is the path of the component relative to the platform root.
+	Path string `json:"path"`
+	// Cluster is the cluster name to provide when rendering the component.
+	Cluster string `json:"cluster"`
+}

api/core/v1alpha2/doc.go

@@ -0,0 +1,26 @@
+// Package v1alpha2 contains the core API contract between the holos cli and CUE
+// configuration code.  Platform designers, operators, and software developers
+// use this API to write configuration in CUE which `holos` loads.  The overall
+// shape of the API defines imperative actions `holos` should carry out to
+// render the complete yaml that represents a Platform.
+//
+// [Platform] defines the complete configuration of a platform.  With the holos
+// reference platform this takes the shape of one management cluster and at
+// least two workload cluster.  Each cluster has multiple [HolosComponent]
+// resources applied to it.
+//
+// Each holos component path, e.g. `components/namespaces` produces exactly one
+// [BuildPlan] which in turn contains a set of [HolosComponent] kinds.
+//
+// The primary kinds of [HolosComponent] are:
+//
+//  1. [HelmChart] to render config from a helm chart.
+//  2. [KustomizeBuild] to render config from [Kustomize]
+//  3. [KubernetesObjects] to render [APIObjects] defined directly in CUE
+//     configuration.
+//
+// Note that Holos operates as a data pipeline, so the output of a [HelmChart]
+// may be provided to [Kustomize] for post-processing.
+package v1alpha2
+
+//go:generate ../../../hack/gendoc

api/core/v1alpha2/helm.go

@@ -0,0 +1,38 @@
+package v1alpha2
+
+// HelmChart represents a holos component which wraps around an upstream helm
+// chart.  Holos orchestrates helm by providing values obtained from CUE,
+// renders the output using `helm template`, then post-processes the helm output
+// yaml using the general functionality provided by [HolosComponent], for
+// example [Kustomize] post-rendering and mixing in additional kubernetes api
+// objects.
+type HelmChart struct {
+	HolosComponent `json:",inline"`
+	Kind           string `json:"kind" cue:"\"HelmChart\""`
+
+	// Chart represents a helm chart to manage.
+	Chart Chart `json:"chart"`
+	// ValuesContent represents the values.yaml file holos passes to the `helm
+	// template` command.
+	ValuesContent string `json:"valuesContent"`
+	// EnableHooks enables helm hooks when executing the `helm template` command.
+	EnableHooks bool `json:"enableHooks" cue:"bool | *false"`
+}
+
+// Chart represents a helm chart.
+type Chart struct {
+	// Name represents the chart name.
+	Name string `json:"name"`
+	// Version represents the chart version.
+	Version string `json:"version"`
+	// Release represents the chart release when executing helm template.
+	Release string `json:"release"`
+	// Repository represents the repository to fetch the chart from.
+	Repository Repository `json:"repository,omitempty"`
+}
+
+// Repository represents a helm chart repository.
+type Repository struct {
+	Name string `json:"name"`
+	URL  string `json:"url"`
+}

api/core/v1alpha2/kubernetesobjects.go

@@ -0,0 +1,10 @@
+package v1alpha2
+
+const KubernetesObjectsKind = "KubernetesObjects"
+
+// KubernetesObjects represents a [HolosComponent] composed of Kubernetes API
+// objects provided directly from CUE using [APIObjects].
+type KubernetesObjects struct {
+	HolosComponent `json:",inline"`
+	Kind           string `json:"kind" cue:"\"KubernetesObjects\""`
+}

api/core/v1alpha2/kustomizebuild.go

@@ -0,0 +1,8 @@
+package v1alpha2
+
+// KustomizeBuild represents a [HolosComponent] that renders plain yaml files in
+// the holos component directory using `kubectl kustomize build`.
+type KustomizeBuild struct {
+	HolosComponent `json:",inline"`
+	Kind           string `json:"kind" cue:"\"KustomizeBuild\""`
+}

api/core/v1alpha3/apiobjects.go

@@ -0,0 +1,47 @@
+package v1alpha3
+
+import "google.golang.org/protobuf/types/known/structpb"
+
+// InternalLabel is an arbitrary unique identifier internal to holos itself.
+// The holos cli is expected to never write a InternalLabel value to rendered
+// output files, therefore use a [InternalLabel] when the identifier must be
+// unique and internal.  Defined as a type for clarity and type checking.
+//
+// A InternalLabel is useful to convert a CUE struct to a list, for example
+// producing a list of [APIObject] resources from an [APIObjectMap].  A CUE
+// struct using InternalLabel keys is guaranteed to not lose data when rendering
+// output because a InternalLabel is expected to never be written to the final
+// output.
+type InternalLabel string
+
+// Kind is a kubernetes api object kind. Defined as a type for clarity and type
+// checking.
+type Kind string
+
+// APIObject represents the most basic generic form of a single kubernetes api
+// object.  Represented as a JSON object internally for compatibility between
+// tools, for example loading from CUE.
+type APIObject structpb.Struct
+
+// APIObjectMap represents the marshalled yaml representation of kubernetes api
+// objects.  Do not produce an APIObjectMap directly, instead use [APIObjects]
+// to produce the marshalled yaml representation from CUE data, then provide the
+// result to [Component].
+type APIObjectMap map[Kind]map[InternalLabel]string
+
+// APIObjects represents Kubernetes API objects defined directly from CUE code.
+// Useful to mix in resources to any kind of [Component], for example
+// adding an ExternalSecret resource to a [HelmChart].
+//
+// [Kind] must be the resource kind, e.g. Deployment or Service.
+//
+// [InternalLabel] is an arbitrary internal identifier to uniquely identify the resource
+// within the context of a `holos` command.  Holos will never write the
+// intermediate label to rendered output.
+//
+// Refer to [Component] which accepts an [APIObjectMap] field provided by
+// [APIObjects].
+type APIObjects struct {
+	APIObjects   map[Kind]map[InternalLabel]APIObject `json:"apiObjects"`
+	APIObjectMap APIObjectMap                         `json:"apiObjectMap"`
+}

api/core/v1alpha3/buildplan.go

@@ -0,0 +1,52 @@
+package v1alpha3
+
+// FilePath represents a file path.
+type FilePath string
+
+// FileContent represents file contents.
+type FileContent string
+
+// FileContentMap represents a mapping of file paths to file contents.
+type FileContentMap map[FilePath]FileContent
+
+// BuildPlan represents a build plan for the holos cli to execute.  The purpose
+// of a BuildPlan is to define one or more [Component] kinds.  For example a
+// [HelmChart], [KustomizeBuild], or [KubernetesObjects].
+//
+// A BuildPlan usually has an additional empty [KubernetesObjects] for the
+// purpose of using the [Component] DeployFiles field to deploy an ArgoCD
+// or Flux gitops resource for the holos component.
+type BuildPlan struct {
+	Kind       string        `json:"kind" cue:"\"BuildPlan\""`
+	APIVersion string        `json:"apiVersion" cue:"string | *\"v1alpha3\""`
+	Spec       BuildPlanSpec `json:"spec"`
+}
+
+// BuildPlanSpec represents the specification of the build plan.
+type BuildPlanSpec struct {
+	// Disabled causes the holos cli to take no action over the [BuildPlan].
+	Disabled bool `json:"disabled,omitempty"`
+	// Components represents multiple [HolosComponent] kinds to manage.
+	Components BuildPlanComponents `json:"components,omitempty"`
+}
+
+type BuildPlanComponents struct {
+	Resources             map[InternalLabel]KubernetesObjects `json:"resources,omitempty"`
+	KubernetesObjectsList []KubernetesObjects                 `json:"kubernetesObjectsList,omitempty"`
+	HelmChartList         []HelmChart                         `json:"helmChartList,omitempty"`
+	KustomizeBuildList    []KustomizeBuild                    `json:"kustomizeBuildList,omitempty"`
+}
+
+// Kustomize represents resources necessary to execute a kustomize build.
+// Intended for at least two use cases:
+//
+//  1. Process a [KustomizeBuild] [Component] which represents raw yaml
+//     file resources in a holos component directory.
+//  2. Post process a [HelmChart] [Component] to inject istio, patch jobs,
+//     add custom labels, etc...
+type Kustomize struct {
+	// KustomizeFiles holds file contents for kustomize, e.g. patch files.
+	KustomizeFiles FileContentMap `json:"kustomizeFiles,omitempty"`
+	// ResourcesFile is the file name used for api objects in kustomization.yaml
+	ResourcesFile string `json:"resourcesFile,omitempty"`
+}

api/core/v1alpha3/component.go

@@ -0,0 +1,43 @@
+package v1alpha3
+
+// Component defines the fields common to all holos component kinds.  Every
+// holos component kind should embed Component.
+type Component struct {
+	// Kind is a string value representing the resource this object represents.
+	Kind string `json:"kind"`
+	// APIVersion represents the versioned schema of this representation of an object.
+	APIVersion string `json:"apiVersion" cue:"\"v1alpha3\""`
+	// Metadata represents data about the holos component such as the Name.
+	Metadata Metadata `json:"metadata"`
+
+	// APIObjectMap holds the marshalled representation of api objects.  Useful to
+	// mix in resources to each Component type, for example adding an
+	// ExternalSecret to a [HelmChart] Component.  Refer to [APIObjects].
+	APIObjectMap APIObjectMap `json:"apiObjectMap,omitempty"`
+
+	// DeployFiles represents file paths relative to the cluster deploy directory
+	// with the value representing the file content.  Intended for defining the
+	// ArgoCD Application resource or Flux Kustomization resource from within CUE,
+	// but may be used to render any file related to the build plan from CUE.
+	DeployFiles FileContentMap `json:"deployFiles,omitempty"`
+
+	// Kustomize represents a kubectl kustomize build post-processing step.
+	Kustomize `json:"kustomize,omitempty"`
+
+	// Skip causes holos to take no action regarding this component.
+	Skip bool `json:"skip" cue:"bool | *false"`
+}
+
+// Metadata represents data about the object such as the Name.
+type Metadata struct {
+	// Name represents the name of the holos component.
+	Name string `json:"name"`
+	// Namespace is the primary namespace of the holos component.  A holos
+	// component may manage resources in multiple namespaces, in this case
+	// consider setting the component namespace to default.
+	//
+	// This field is optional because not all resources require a namespace,
+	// particularly CRDs and DeployFiles functionality.
+	// +optional
+	Namespace string `json:"namespace,omitempty"`
+}

api/core/v1alpha3/constants.go

@@ -0,0 +1,11 @@
+package v1alpha3
+
+const (
+	APIVersion    = "v1alpha3"
+	BuildPlanKind = "BuildPlan"
+	HelmChartKind = "HelmChart"
+	// ChartDir is the directory name created in the holos component directory to cache a chart.
+	ChartDir = "vendor"
+	// ResourcesFile is the file name used to store component output when post-processing with kustomize.
+	ResourcesFile = "resources.yaml"
+)

api/core/v1alpha3/doc.go

@@ -0,0 +1,26 @@
+// Package v1alpha3 contains the core API contract between the holos cli and CUE
+// configuration code.  Platform designers, operators, and software developers
+// use this API to write configuration in CUE which `holos` loads.  The overall
+// shape of the API defines imperative actions `holos` should carry out to
+// render the complete yaml that represents a Platform.
+//
+// [Platform] defines the complete configuration of a platform.  With the holos
+// reference platform this takes the shape of one management cluster and at
+// least two workload cluster.  Each cluster has multiple [Component]
+// resources applied to it.
+//
+// Each holos component path, e.g. `components/namespaces` produces exactly one
+// [BuildPlan] which in turn contains a set of [Component] kinds.
+//
+// The primary kinds of [Component] are:
+//
+//  1. [HelmChart] to render config from a helm chart.
+//  2. [KustomizeBuild] to render config from [Kustomize]
+//  3. [KubernetesObjects] to render [APIObjects] defined directly in CUE
+//     configuration.
+//
+// Note that Holos operates as a data pipeline, so the output of a [HelmChart]
+// may be provided to [Kustomize] for post-processing.
+package v1alpha3
+
+//go:generate ../../../hack/gendoc

api/core/v1alpha3/helm.go

@@ -0,0 +1,38 @@
+package v1alpha3
+
+// HelmChart represents a holos component which wraps around an upstream helm
+// chart.  Holos orchestrates helm by providing values obtained from CUE,
+// renders the output using `helm template`, then post-processes the helm output
+// yaml using the general functionality provided by [Component], for
+// example [Kustomize] post-rendering and mixing in additional kubernetes api
+// objects.
+type HelmChart struct {
+	Component `json:",inline"`
+	Kind      string `json:"kind" cue:"\"HelmChart\""`
+
+	// Chart represents a helm chart to manage.
+	Chart Chart `json:"chart"`
+	// ValuesContent represents the values.yaml file holos passes to the `helm
+	// template` command.
+	ValuesContent string `json:"valuesContent"`
+	// EnableHooks enables helm hooks when executing the `helm template` command.
+	EnableHooks bool `json:"enableHooks" cue:"bool | *false"`
+}
+
+// Chart represents a helm chart.
+type Chart struct {
+	// Name represents the chart name.
+	Name string `json:"name"`
+	// Version represents the chart version.
+	Version string `json:"version"`
+	// Release represents the chart release when executing helm template.
+	Release string `json:"release"`
+	// Repository represents the repository to fetch the chart from.
+	Repository Repository `json:"repository,omitempty"`
+}
+
+// Repository represents a helm chart repository.
+type Repository struct {
+	Name string `json:"name"`
+	URL  string `json:"url"`
+}

api/core/v1alpha3/kubernetesobjects.go

@@ -0,0 +1,10 @@
+package v1alpha3
+
+const KubernetesObjectsKind = "KubernetesObjects"
+
+// KubernetesObjects represents a [Component] composed of Kubernetes API
+// objects provided directly from CUE using [APIObjects].
+type KubernetesObjects struct {
+	Component `json:",inline"`
+	Kind      string `json:"kind" cue:"\"KubernetesObjects\""`
+}

api/core/v1alpha3/kustomizebuild.go

@@ -0,0 +1,8 @@
+package v1alpha3
+
+// KustomizeBuild represents a [Component] that renders plain yaml files in
+// the holos component directory using `kubectl kustomize build`.
+type KustomizeBuild struct {
+	Component `json:",inline"`
+	Kind      string `json:"kind" cue:"\"KustomizeBuild\""`
+}

api/core/v1alpha3/platform.go

@@ -0,0 +1,44 @@
+package v1alpha3
+
+import "google.golang.org/protobuf/types/known/structpb"
+
+// Platform represents a platform to manage.  A Platform resource informs holos
+// which components to build.  The platform resource also acts as a container
+// for the platform model form values provided by the PlatformService.  The
+// primary use case is to collect the cluster names, cluster types, platform
+// model, and holos components to build into one resource.
+type Platform struct {
+	// Kind is a string value representing the resource this object represents.
+	Kind string `json:"kind" cue:"\"Platform\""`
+	// APIVersion represents the versioned schema of this representation of an object.
+	APIVersion string `json:"apiVersion" cue:"string | *\"v1alpha3\""`
+	// Metadata represents data about the object such as the Name.
+	Metadata PlatformMetadata `json:"metadata"`
+
+	// Spec represents the specification.
+	Spec PlatformSpec `json:"spec"`
+}
+
+type PlatformMetadata struct {
+	// Name represents the Platform name.
+	Name string `json:"name"`
+}
+
+// PlatformSpec represents the specification of a Platform.  Think of a platform
+// specification as a list of platform components to apply to a list of
+// kubernetes clusters combined with the user-specified Platform Model.
+type PlatformSpec struct {
+	// Model represents the platform model holos gets from from the
+	// PlatformService.GetPlatform rpc method and provides to CUE using a tag.
+	Model structpb.Struct `json:"model" cue:"{...}"`
+	// Components represents a list of holos components to manage.
+	Components []PlatformSpecComponent `json:"components"`
+}
+
+// PlatformSpecComponent represents a holos component to build or render.
+type PlatformSpecComponent struct {
+	// Path is the path of the component relative to the platform root.
+	Path string `json:"path"`
+	// Cluster is the cluster name to provide when rendering the component.
+	Cluster string `json:"cluster"`
+}

api/meta/v1alpha2/meta.go

@@ -0,0 +1,37 @@
+package v1alpha2
+
+// TypeMeta describes an individual object in an API response or request with
+// strings representing the type of the object and its API schema version.
+// Structures that are versioned or persisted should inline TypeMeta.
+type TypeMeta struct {
+	// Kind is a string value representing the resource this object represents.
+	Kind string `json:"kind"`
+	// APIVersion defines the versioned schema of this representation of an object.
+	APIVersion string `json:"apiVersion" cue:"string | *\"v1alpha2\""`
+}
+
+func (tm *TypeMeta) GetKind() string {
+	return tm.Kind
+}
+
+func (tm *TypeMeta) GetAPIVersion() string {
+	return tm.APIVersion
+}
+
+// Discriminator discriminates the kind of an api object.
+type Discriminator interface {
+	// GetKind returns Kind.
+	GetKind() string
+	// GetAPIVersion returns APIVersion.
+	GetAPIVersion() string
+}
+
+// ObjectMeta represents metadata of a holos component object. The fields are a
+// copy of upstream kubernetes api machinery but are holos objects distinct from
+// kubernetes api objects.
+type ObjectMeta struct {
+	// Name uniquely identifies the holos component instance and must be suitable as a file name.
+	Name string `json:"name,omitempty"`
+	// Namespace confines a holos component to a single namespace via kustomize if set.
+	Namespace string `json:"namespace,omitempty"`
+}

api/v1alpha1/buildplan.go

@@ -1,6 +1,7 @@
 package v1alpha1
 
 import (
+	"errors"
 	"fmt"
 	"strings"
 )
@@ -9,14 +10,17 @@ import (
 type BuildPlan struct {
 	TypeMeta `json:",inline" yaml:",inline"`
 	// Metadata represents the holos component name
-	Metadata ObjectMeta     `json:"metadata,omitempty" yaml:"metadata,omitempty"`
-	Spec     BuildPlanSpec  `json:"spec,omitempty" yaml:"spec,omitempty"`
-	Platform map[string]any `json:"platform,omitempty" yaml:"platform,omitempty"`
+	Metadata ObjectMeta    `json:"metadata,omitempty" yaml:"metadata,omitempty"`
+	Spec     BuildPlanSpec `json:"spec,omitempty" yaml:"spec,omitempty"`
 }
 
 type BuildPlanSpec struct {
 	Disabled   bool                `json:"disabled,omitempty" yaml:"disabled,omitempty"`
 	Components BuildPlanComponents `json:"components,omitempty" yaml:"components,omitempty"`
+	// DeployFiles keys represent file paths relative to the cluster deploy
+	// directory.  Map values represent the string encoded file contents.  Used to
+	// write the argocd Application, but may be used to render any file from CUE.
+	DeployFiles FileContentMap `json:"deployFiles,omitempty" yaml:"deployFiles,omitempty"`
 }
 
 type BuildPlanComponents struct {
@@ -35,7 +39,18 @@ func (bp *BuildPlan) Validate() error {
 		errs = append(errs, fmt.Sprintf("apiVersion invalid: want: %s have: %s", APIVersion, bp.APIVersion))
 	}
 	if len(errs) > 0 {
-		return fmt.Errorf("invalid BuildPlan: " + strings.Join(errs, ", "))
+		return errors.New("invalid BuildPlan: " + strings.Join(errs, ", "))
 	}
 	return nil
 }
+
+func (bp *BuildPlan) ResultCapacity() (count int) {
+	if bp == nil {
+		return 0
+	}
+	count = len(bp.Spec.Components.HelmChartList) +
+		len(bp.Spec.Components.KubernetesObjectsList) +
+		len(bp.Spec.Components.KustomizeBuildList) +
+		len(bp.Spec.Components.Resources)
+	return count
+}

api/v1alpha1/component.go

@@ -20,3 +20,11 @@ type HolosComponent struct {
 func (hc *HolosComponent) NewResult() *Result {
 	return &Result{HolosComponent: *hc}
 }
+
+func (hc *HolosComponent) GetAPIVersion() string {
+	return hc.APIVersion
+}
+
+func (hc *HolosComponent) GetKind() string {
+	return hc.Kind
+}

api/v1alpha1/form.go

@@ -0,0 +1,13 @@
+package v1alpha1
+
+import object "github.com/holos-run/holos/service/gen/holos/object/v1alpha1"
+
+// Form represents a collection of Formly json powered form.
+type Form struct {
+	TypeMeta `json:",inline" yaml:",inline"`
+	Spec     FormSpec `json:"spec" yaml:"spec"`
+}
+
+type FormSpec struct {
+	Form object.Form `json:"form" yaml:"form"`
+}

api/v1alpha1/helm.go

@@ -6,6 +6,7 @@ import (
 	"os"
 	"path/filepath"
 	"strings"
+	"syscall"
 
 	"github.com/holos-run/holos"
 	"github.com/holos-run/holos/internal/errors"
@@ -121,6 +122,14 @@ func (hc *HelmChart) helm(ctx context.Context, r *Result, path holos.InstancePat
 }
 
 // cacheChart stores a cached copy of Chart in the chart subdirectory of path.
+//
+// It is assumed that the only method responsible for writing to chartDir is
+// cacheChart itself.
+//
+// This relies on the atomicity of moving temporary directories into place on
+// the same filesystem via os.Rename. If a syscall.EEXIST error occurs during
+// renaming, it indicates that the cached chart already exists, which is an
+// expected scenario when this function is called concurrently.
 func cacheChart(ctx context.Context, path holos.InstancePath, chartDir string, chart Chart) error {
 	log := logger.FromContext(ctx)
 
@@ -156,11 +165,16 @@ func cacheChart(ctx context.Context, path holos.InstancePath, chartDir string, c
 		dst := filepath.Join(cachePath, item.Name())
 		log.DebugContext(ctx, "rename", "src", src, "dst", dst)
 		if err := os.Rename(src, dst); err != nil {
-			return errors.Wrap(fmt.Errorf("could not rename: %w", err))
+			var linkErr *os.LinkError
+			if errors.As(err, &linkErr) && errors.Is(linkErr.Err, syscall.EEXIST) {
+				log.DebugContext(ctx, "cache already exists", "chart", chart.Name, "chart_version", chart.Version, "path", cachePath)
+			} else {
+				return errors.Wrap(fmt.Errorf("could not rename: %w", err))
+			}
 		}
 	}
 
-	log.InfoContext(ctx, "cached", "chart", chart.Name, "version", chart.Version, "path", cachePath)
+	log.InfoContext(ctx, "cached", "chart", chart.Name, "chart_version", chart.Version, "path", cachePath)
 
 	return nil
 }

api/v1alpha1/platform.go

@@ -0,0 +1,32 @@
+package v1alpha1
+
+import "google.golang.org/protobuf/types/known/structpb"
+
+// Platform represents a platform to manage.  A Platform resource informs holos
+// which components to build.  The platform resource also acts as a container
+// for the platform model form values provided by the PlatformService.  The
+// primary use case is to collect the cluster names, cluster types, platform
+// model, and holos components to build into one resource.
+type Platform struct {
+	TypeMeta `json:",inline" yaml:",inline"`
+	Metadata ObjectMeta   `json:"metadata" yaml:"metadata"`
+	Spec     PlatformSpec `json:"spec" yaml:"spec"`
+}
+
+// PlatformSpec represents the platform build plan specification.
+type PlatformSpec struct {
+	// Model represents the platform model holos gets from from the
+	// holos.platform.v1alpha1.PlatformService.GetPlatform method and provides to
+	// CUE using a tag.
+	Model      structpb.Struct         `json:"model" yaml:"model"`
+	Components []PlatformSpecComponent `json:"components" yaml:"components"`
+}
+
+// PlatformSpecComponent represents a component to build or render with flags to
+// pass, for example the cluster name.
+type PlatformSpecComponent struct {
+	// Path is the path of the component relative to the platform root.
+	Path string `json:"path" yaml:"path"`
+	// Cluster is the cluster name to use when building the component.
+	Cluster string `json:"cluster" yaml:"cluster"`
+}

api/v1alpha1/result.go

@@ -17,6 +17,18 @@ type Result struct {
 	HolosComponent
 	// accumulatedOutput accumulates rendered api objects.
 	accumulatedOutput string
+	// DeployFiles keys represent file paths relative to the cluster deploy
+	// directory.  Map values represent the string encoded file contents.  Used to
+	// write the argocd Application, but may be used to render any file from CUE.
+	DeployFiles FileContentMap `json:"deployFiles,omitempty" yaml:"deployFiles,omitempty"`
+}
+
+// Continue returns true if Skip is true indicating the result is to be skipped over.
+func (r *Result) Continue() bool {
+	if r == nil {
+		return false
+	}
+	return r.Skip
 }
 
 func (r *Result) Name() string {
@@ -120,6 +132,21 @@ func (r *Result) kustomize(ctx context.Context) error {
 	return nil
 }
 
+func (r *Result) WriteDeployFiles(ctx context.Context, path string) error {
+	log := logger.FromContext(ctx)
+	if len(r.DeployFiles) == 0 {
+		return nil
+	}
+	for k, content := range r.DeployFiles {
+		path := filepath.Join(path, k)
+		if err := r.Save(ctx, path, content); err != nil {
+			return errors.Wrap(err)
+		}
+		log.InfoContext(ctx, "wrote deploy file", "path", path, "bytes", len(content))
+	}
+	return nil
+}
+
 // Save writes the content to the filesystem for git ops.
 func (r *Result) Save(ctx context.Context, path string, content string) error {
 	log := logger.FromContext(ctx)
@@ -128,7 +155,7 @@ func (r *Result) Save(ctx context.Context, path string, content string) error {
 		log.WarnContext(ctx, "could not mkdir", "path", dir, "err", err)
 		return errors.Wrap(err)
 	}
-	// Write the kube api objects
+	// Write the file content
 	if err := os.WriteFile(path, []byte(content), os.FileMode(0644)); err != nil {
 		log.WarnContext(ctx, "could not write", "path", path, "err", err)
 		return errors.Wrap(err)

api/v1alpha1/typemeta.go

@@ -8,3 +8,13 @@ type TypeMeta struct {
 func (tm *TypeMeta) GetKind() string {
 	return tm.Kind
 }
+
+func (tm *TypeMeta) GetAPIVersion() string {
+	return tm.APIVersion
+}
+
+// Discriminator is an interface to discriminate the kind api object.
+type Discriminator interface {
+	GetKind() string
+	GetAPIVersion() string
+}

buf.gen.yaml

@@ -18,7 +18,3 @@ plugins:
     out: internal/frontend/holos/src/app/gen
     opt:
       - target=ts
-  - plugin: connect-query
-    out: internal/frontend/holos/src/app/gen
-    opt:
-      - target=ts

cmd/holos/testdata/constraints.txt

@@ -2,6 +2,8 @@
 exec holos build ./foo/... --log-level debug
 stdout '^bf2bc7f9-9ba0-4f9e-9bd2-9a205627eb0b$'
 
+-- platform.config.json --
+{}
 -- cue.mod --
 package holos
 -- foo/constraints.cue --
@@ -20,6 +22,7 @@ spec: components: KubernetesObjectsList: [
 package holos
 
 _cluster: string @tag(cluster, string)
+_platform_config: string @tag(platform_config, string)
 
 #KubernetesObjects: {
 	apiVersion: "holos.run/v1alpha1"

cmd/holos/testdata/issue15_cue_errors.txt

@@ -3,12 +3,15 @@
 stderr 'apiObjectMap.foo.bar: cannot convert incomplete value'
 stderr '/component.cue:\d+:\d+$'
 
+-- platform.config.json --
+{}
 -- cue.mod --
 package holos
 -- component.cue --
 package holos
 
 _cluster: string @tag(cluster, string)
+_platform_config: string @tag(platform_config, string)
 
 apiVersion: "holos.run/v1alpha1"
 kind: "BuildPlan"

cmd/holos/testdata/issue25_apiobjects_cue.txt

@@ -3,6 +3,8 @@ exec holos build .
 stdout '^kind: SecretStore$'
 stdout '# Source: CUE apiObjects.SecretStore.default'
 
+-- platform.config.json --
+{}
 -- cue.mod --
 package holos
 -- component.cue --
@@ -13,6 +15,7 @@ kind: "BuildPlan"
 spec: components: KubernetesObjectsList: [{apiObjectMap: #APIObjects.apiObjectMap}]
 
 _cluster: string @tag(cluster, string)
+_platform_config: string @tag(platform_config, string)
 
 #SecretStore: {
     kind: string

cmd/holos/testdata/issue25_apiobjects_helm.txt

@@ -4,6 +4,8 @@ stdout '^kind: SecretStore$'
 stdout '# Source: CUE apiObjects.SecretStore.default'
 stderr 'skipping helm: no chart name specified'
 
+-- platform.config.json --
+{}
 -- cue.mod --
 package holos
 -- component.cue --
@@ -14,6 +16,7 @@ kind: "BuildPlan"
 spec: components: HelmChartList: [{apiObjectMap: #APIObjects.apiObjectMap}]
 
 _cluster: string @tag(cluster, string)
+_platform_config: string @tag(platform_config, string)
 
 #SecretStore: {
     kind: string

cmd/holos/testdata/issue25_show_object_names.txt

@@ -2,6 +2,8 @@
 ! exec holos build .
 stderr 'apiObjects.secretstore.default.foo: field not allowed'
 
+-- platform.config.json --
+{}
 -- cue.mod --
 package holos
 -- component.cue --
@@ -10,6 +12,7 @@ package holos
 apiVersion: "holos.run/v1alpha1"
 kind: "KubernetesObjects"
 cluster: string @tag(cluster, string)
+_platform_config: string @tag(platform_config, string)
 
 #SecretStore: {
     metadata: name: string

cmd/holos/testdata/issue33_helm_stderr.txt

@@ -2,6 +2,8 @@
 ! exec holos build .
 stderr 'Error: execution error at \(zitadel/templates/secret_zitadel-masterkey.yaml:2:4\): Either set .Values.zitadel.masterkey xor .Values.zitadel.masterkeySecretName'
 
+-- platform.config.json --
+{}
 -- cue.mod --
 package holos
 -- zitadel.cue --
@@ -12,6 +14,7 @@ kind: "BuildPlan"
 spec: components: HelmChartList: [_HelmChart]
 
 _cluster: string @tag(cluster, string)
+_platform_config: string @tag(platform_config, string)
 
 _HelmChart: {
   apiVersion: "holos.run/v1alpha1"

cmd/holos/testdata/issue42_kustomize_build_kind.txt

@@ -1,15 +1,18 @@
 # Kustomize is a supported holos component kind
-exec holos render --cluster-name=mycluster . --log-level=debug
+exec holos render component --cluster-name=mycluster . --log-level=debug
 
 # Want generated output
 cmp want.yaml deploy/clusters/mycluster/components/kstest/kstest.gen.yaml
 
+-- platform.config.json --
+{}
 -- cue.mod --
 package holos
 -- component.cue --
 package holos
 
 _cluster: string @tag(cluster, string)
+_platform_config: string @tag(platform_config, string)
 
 apiVersion: "holos.run/v1alpha1"
 kind: "BuildPlan"

cmd/holos/testdata/issue72_disallow_unknown_fields.txt

@@ -3,11 +3,14 @@
 ! exec holos build .
 stderr 'unknown field \\"TypoKubernetesObjectsList\\"'
 
+-- platform.config.json --
+{}
 -- cue.mod --
 package holos
 -- component.cue --
 package holos
 _cluster: string @tag(cluster, string)
+_platform_config: string @tag(platform_config, string)
 
 apiVersion: "holos.run/v1alpha1"
 kind: "BuildPlan"

cmd/holos/testdata/version.txt

@@ -1,5 +1,3 @@
 exec holos --version
 # want version with no v on stdout
 stdout -count=1 '^\d+\.\d+\.\d+$'
-# want nothing on stderr
-! stderr .

cue.mod/module.cue

@@ -1 +0,0 @@
-module: "github.com/holos-run/holos"

doc/md/api.md

@@ -0,0 +1,5 @@
+import DocCardList from '@theme/DocCardList';
+
+# API Reference
+
+<DocCardList />

doc/md/api/author.md

@@ -0,0 +1,5 @@
+import DocCardList from '@theme/DocCardList';
+
+# Author API
+
+<DocCardList />

doc/md/api/author/v1alpha3.md

@@ -0,0 +1,213 @@
+<!-- Code generated by gomarkdoc. DO NOT EDIT -->
+
+# v1alpha3
+
+```go
+import "github.com/holos-run/holos/api/author/v1alpha3"
+```
+
+Package v1alpha3 contains CUE definitions intended as convenience wrappers around the core data types defined in package core. The purpose of these wrappers is to make life easier for platform engineers by reducing boiler plate code and generating component build plans in a consistent manner.
+
+## Index
+
+- [type ArgoConfig](<#ArgoConfig>)
+- [type Cluster](<#Cluster>)
+- [type ComponentFields](<#ComponentFields>)
+- [type Fleet](<#Fleet>)
+- [type Helm](<#Helm>)
+- [type Kubernetes](<#Kubernetes>)
+- [type Kustomize](<#Kustomize>)
+- [type Platform](<#Platform>)
+- [type StandardFleets](<#StandardFleets>)
+
+
+<a name="ArgoConfig"></a>
+## type ArgoConfig {#ArgoConfig}
+
+ArgoConfig represents the ArgoCD GitOps configuration for a Component. Useful to define once at the root of the Platform configuration and reuse across all Components.
+
+```go
+type ArgoConfig struct {
+    // Enabled causes holos to render an ArgoCD Application resource for GitOps if true.
+    Enabled bool `cue:"true | *false"`
+    // ClusterName represents the cluster within the platform the Application
+    // resource is intended for.
+    ClusterName string
+    // DeployRoot represents the path from the git repository root to the `deploy`
+    // rendering output directory.  Used as a prefix for the
+    // Application.spec.source.path field.
+    DeployRoot string `cue:"string | *\".\""`
+    // RepoURL represents the value passed to the Application.spec.source.repoURL
+    // field.
+    RepoURL string
+    // TargetRevision represents the value passed to the
+    // Application.spec.source.targetRevision field.  Defaults to the branch named
+    // main.
+    TargetRevision string `cue:"string | *\"main\""`
+    // AppProject represents the ArgoCD Project to associate the Application with.
+    AppProject string `cue:"string | *\"default\""`
+}
+```
+
+<a name="Cluster"></a>
+## type Cluster {#Cluster}
+
+Cluster represents a cluster managed by the Platform.
+
+```go
+type Cluster struct {
+    // Name represents the cluster name, for example "east1", "west1", or
+    // "management".
+    Name string `json:"name"`
+    // Primary represents if the cluster is marked as the primary among a set of
+    // candidate clusters.  Useful for promotion of database leaders.
+    Primary bool `json:"primary" cue:"true | *false"`
+}
+```
+
+<a name="ComponentFields"></a>
+## type ComponentFields {#ComponentFields}
+
+Component represents the fields common the different kinds of component. All components have a name, support mixing in resources, and produce a BuildPlan.
+
+```go
+type ComponentFields struct {
+    // Name represents the Component name.
+    Name string
+    // Resources are kubernetes api objects to mix into the output.
+    Resources map[string]any
+    // ArgoConfig represents the ArgoCD GitOps configuration for this Component.
+    ArgoConfig ArgoConfig
+    // BuildPlan represents the derived BuildPlan for the Holos cli to render.
+    BuildPlan core.BuildPlan
+}
+```
+
+<a name="Fleet"></a>
+## type Fleet {#Fleet}
+
+Fleet represents a named collection of similarly configured Clusters. Useful to segregate workload clusters from their management cluster.
+
+```go
+type Fleet struct {
+    Name string `json:"name"`
+    // Clusters represents a mapping of Clusters by their name.
+    Clusters map[string]Cluster `json:"clusters" cue:"{[Name=_]: name: Name}"`
+}
+```
+
+<a name="Helm"></a>
+## type Helm {#Helm}
+
+Helm provides a BuildPlan via the Output field which contains one HelmChart from package core. Useful as a convenience wrapper to render a HelmChart with optional mix\-in resources and Kustomization post\-processing.
+
+```go
+type Helm struct {
+    ComponentFields `json:",inline"`
+
+    // Version represents the chart version.
+    Version string
+    // Namespace represents the helm namespace option when rendering the chart.
+    Namespace string
+
+    // Repo represents the chart repository
+    Repo struct {
+        Name string `json:"name"`
+        URL  string `json:"url"`
+    }
+
+    // Values represents data to marshal into a values.yaml for helm.
+    Values interface{} `cue:"{...}"`
+
+    // Chart represents the derived HelmChart for inclusion in the BuildPlan
+    // Output field value.  The default HelmChart field values are derived from
+    // other Helm field values and should be sufficient for most use cases.
+    Chart core.HelmChart
+
+    // EnableKustomizePostProcessor processes helm output with kustomize if true.
+    EnableKustomizePostProcessor bool `cue:"true | *false"`
+
+    // KustomizeFiles represents additional files to include in a Kustomization
+    // resources list.  Useful to patch helm output.  The implementation is a
+    // struct with filename keys and structs as values.  Holos encodes the struct
+    // value to yaml then writes the result to the filename key.  Component
+    // authors may then reference the filename in the kustomization.yaml resources
+    // or patches lists.
+    // Requires EnableKustomizePostProcessor: true.
+    KustomizeFiles map[string]any `cue:"{[string]: {...}}"`
+
+    // KustomizePatches represents patches to apply to the helm output.  Requires
+    // EnableKustomizePostProcessor: true.
+    KustomizePatches map[core.InternalLabel]any `cue:"{[string]: {...}}"`
+
+    // KustomizeResources represents additional resources files to include in the
+    // kustomize resources list.
+    KustomizeResources map[string]any `cue:"{[string]: {...}}"`
+}
+```
+
+<a name="Kubernetes"></a>
+## type Kubernetes {#Kubernetes}
+
+Kubernetes provides a BuildPlan via the Output field which contains inline API Objects provided directly from CUE.
+
+```go
+type Kubernetes struct {
+    ComponentFields `json:",inline"`
+    // Objects represents the kubernetes api objects for the Component.
+    Objects core.KubernetesObjects
+}
+```
+
+<a name="Kustomize"></a>
+## type Kustomize {#Kustomize}
+
+Kustomize provides a BuildPlan via the Output field which contains one KustomizeBuild from package core.
+
+```go
+type Kustomize struct {
+    ComponentFields `json:",inline"`
+    // Kustomization represents the kustomize build plan for holos to render.
+    Kustomization core.KustomizeBuild
+}
+```
+
+<a name="Platform"></a>
+## type Platform {#Platform}
+
+Platform is a convenience structure to produce a core Platform specification value in the Output field. Useful to collect components at the root of the Platform configuration tree as a struct, which are automatically converted into a list for the core Platform spec output.
+
+```go
+type Platform struct {
+    // Name represents the Platform name.
+    Name string `cue:"string | *\"holos\""`
+    // Components is a structured map of components to manage by their name.
+    Components map[string]core.PlatformSpecComponent
+    // Model represents the Platform model holos gets from from the
+    // PlatformService.GetPlatform rpc method and provides to CUE using a tag.
+    Model structpb.Struct `cue:"{...}"`
+    // Output represents the core Platform spec for the holos cli to iterate over
+    // and render each listed Component, injecting the Model.
+    Output core.Platform
+    // Domain represents the primary domain the Platform operates in.  This field
+    // is intended as a sensible default for component authors to reference and
+    // platform operators to define.
+    Domain string `cue:"string | *\"holos.localhost\""`
+}
+```
+
+<a name="StandardFleets"></a>
+## type StandardFleets {#StandardFleets}
+
+StandardFleets represents the standard set of Clusters in a Platform segmented into Fleets by their purpose. The management Fleet contains a single Cluster, for example a GKE autopilot cluster with no workloads deployed for reliability and cost efficiency. The workload Fleet contains all other Clusters which contain workloads and sync Secrets from the management cluster.
+
+```go
+type StandardFleets struct {
+    // Workload represents a Fleet of zero or more workload Clusters.
+    Workload Fleet `json:"workload" cue:"{name: \"workload\"}"`
+    // Management represents a Fleet with one Cluster named management.
+    Management Fleet `json:"management" cue:"{name: \"management\"}"`
+}
+```
+
+Generated by [gomarkdoc](<https://github.com/princjef/gomarkdoc>)

doc/md/api/core.md

@@ -0,0 +1,5 @@
+import DocCardList from '@theme/DocCardList';
+
+# Core API
+
+<DocCardList />

doc/md/api/core/v1alpha2.md

@@ -0,0 +1,403 @@
+<!-- Code generated by gomarkdoc. DO NOT EDIT -->
+
+# v1alpha2
+
+```go
+import "github.com/holos-run/holos/api/core/v1alpha2"
+```
+
+Package v1alpha2 contains the core API contract between the holos cli and CUE configuration code. Platform designers, operators, and software developers use this API to write configuration in CUE which \`holos\` loads. The overall shape of the API defines imperative actions \`holos\` should carry out to render the complete yaml that represents a Platform.
+
+[Platform](<#Platform>) defines the complete configuration of a platform. With the holos reference platform this takes the shape of one management cluster and at least two workload cluster. Each cluster has multiple [HolosComponent](<#HolosComponent>) resources applied to it.
+
+Each holos component path, e.g. \`components/namespaces\` produces exactly one [BuildPlan](<#BuildPlan>) which in turn contains a set of [HolosComponent](<#HolosComponent>) kinds.
+
+The primary kinds of [HolosComponent](<#HolosComponent>) are:
+
+1. [HelmChart](<#HelmChart>) to render config from a helm chart.
+2. [KustomizeBuild](<#KustomizeBuild>) to render config from [Kustomize](<#Kustomize>)
+3. [KubernetesObjects](<#KubernetesObjects>) to render [APIObjects](<#APIObjects>) defined directly in CUE configuration.
+
+Note that Holos operates as a data pipeline, so the output of a [HelmChart](<#HelmChart>) may be provided to [Kustomize](<#Kustomize>) for post\-processing.
+
+## Index
+
+- [Constants](<#constants>)
+- [type APIObject](<#APIObject>)
+- [type APIObjectMap](<#APIObjectMap>)
+- [type APIObjects](<#APIObjects>)
+- [type BuildPlan](<#BuildPlan>)
+- [type BuildPlanComponents](<#BuildPlanComponents>)
+- [type BuildPlanSpec](<#BuildPlanSpec>)
+- [type Chart](<#Chart>)
+- [type FileContent](<#FileContent>)
+- [type FileContentMap](<#FileContentMap>)
+- [type FilePath](<#FilePath>)
+- [type HelmChart](<#HelmChart>)
+- [type HolosComponent](<#HolosComponent>)
+- [type Kind](<#Kind>)
+- [type KubernetesObjects](<#KubernetesObjects>)
+- [type Kustomize](<#Kustomize>)
+- [type KustomizeBuild](<#KustomizeBuild>)
+- [type Label](<#Label>)
+- [type Metadata](<#Metadata>)
+- [type Platform](<#Platform>)
+- [type PlatformMetadata](<#PlatformMetadata>)
+- [type PlatformSpec](<#PlatformSpec>)
+- [type PlatformSpecComponent](<#PlatformSpecComponent>)
+- [type Repository](<#Repository>)
+
+
+## Constants
+
+<a name="APIVersion"></a>
+
+```go
+const (
+    APIVersion    = "v1alpha2"
+    BuildPlanKind = "BuildPlan"
+    HelmChartKind = "HelmChart"
+    // ChartDir is the directory name created in the holos component directory to cache a chart.
+    ChartDir = "vendor"
+    // ResourcesFile is the file name used to store component output when post-processing with kustomize.
+    ResourcesFile = "resources.yaml"
+)
+```
+
+<a name="KubernetesObjectsKind"></a>
+
+```go
+const KubernetesObjectsKind = "KubernetesObjects"
+```
+
+<a name="APIObject"></a>
+## type APIObject {#APIObject}
+
+APIObject represents the most basic generic form of a single kubernetes api object. Represented as a JSON object internally for compatibility between tools, for example loading from CUE.
+
+```go
+type APIObject structpb.Struct
+```
+
+<a name="APIObjectMap"></a>
+## type APIObjectMap {#APIObjectMap}
+
+APIObjectMap represents the marshalled yaml representation of kubernetes api objects. Do not produce an APIObjectMap directly, instead use [APIObjects](<#APIObjects>) to produce the marshalled yaml representation from CUE data, then provide the result to [HolosComponent](<#HolosComponent>).
+
+```go
+type APIObjectMap map[Kind]map[Label]string
+```
+
+<a name="APIObjects"></a>
+## type APIObjects {#APIObjects}
+
+APIObjects represents Kubernetes API objects defined directly from CUE code. Useful to mix in resources to any kind of [HolosComponent](<#HolosComponent>), for example adding an ExternalSecret resource to a [HelmChart](<#HelmChart>).
+
+[Kind](<#Kind>) must be the resource kind, e.g. Deployment or Service.
+
+[Label](<#Label>) is an arbitrary internal identifier to uniquely identify the resource within the context of a \`holos\` command. Holos will never write the intermediate label to rendered output.
+
+Refer to [HolosComponent](<#HolosComponent>) which accepts an [APIObjectMap](<#APIObjectMap>) field provided by [APIObjects](<#APIObjects>).
+
+```go
+type APIObjects struct {
+    APIObjects   map[Kind]map[Label]APIObject `json:"apiObjects"`
+    APIObjectMap APIObjectMap                 `json:"apiObjectMap"`
+}
+```
+
+<a name="BuildPlan"></a>
+## type BuildPlan {#BuildPlan}
+
+BuildPlan represents a build plan for the holos cli to execute. The purpose of a BuildPlan is to define one or more [HolosComponent](<#HolosComponent>) kinds. For example a [HelmChart](<#HelmChart>), [KustomizeBuild](<#KustomizeBuild>), or [KubernetesObjects](<#KubernetesObjects>).
+
+A BuildPlan usually has an additional empty [KubernetesObjects](<#KubernetesObjects>) for the purpose of using the [HolosComponent](<#HolosComponent>) DeployFiles field to deploy an ArgoCD or Flux gitops resource for the holos component.
+
+```go
+type BuildPlan struct {
+    Kind       string        `json:"kind" cue:"\"BuildPlan\""`
+    APIVersion string        `json:"apiVersion" cue:"string | *\"v1alpha2\""`
+    Spec       BuildPlanSpec `json:"spec"`
+}
+```
+
+<a name="BuildPlanComponents"></a>
+## type BuildPlanComponents {#BuildPlanComponents}
+
+
+
+```go
+type BuildPlanComponents struct {
+    Resources             map[Label]KubernetesObjects `json:"resources,omitempty"`
+    KubernetesObjectsList []KubernetesObjects         `json:"kubernetesObjectsList,omitempty"`
+    HelmChartList         []HelmChart                 `json:"helmChartList,omitempty"`
+    KustomizeBuildList    []KustomizeBuild            `json:"kustomizeBuildList,omitempty"`
+}
+```
+
+<a name="BuildPlanSpec"></a>
+## type BuildPlanSpec {#BuildPlanSpec}
+
+BuildPlanSpec represents the specification of the build plan.
+
+```go
+type BuildPlanSpec struct {
+    // Disabled causes the holos cli to take no action over the [BuildPlan].
+    Disabled bool `json:"disabled,omitempty"`
+    // Components represents multiple [HolosComponent] kinds to manage.
+    Components BuildPlanComponents `json:"components,omitempty"`
+}
+```
+
+<a name="Chart"></a>
+## type Chart {#Chart}
+
+Chart represents a helm chart.
+
+```go
+type Chart struct {
+    // Name represents the chart name.
+    Name string `json:"name"`
+    // Version represents the chart version.
+    Version string `json:"version"`
+    // Release represents the chart release when executing helm template.
+    Release string `json:"release"`
+    // Repository represents the repository to fetch the chart from.
+    Repository Repository `json:"repository,omitempty"`
+}
+```
+
+<a name="FileContent"></a>
+## type FileContent {#FileContent}
+
+FileContent represents file contents.
+
+```go
+type FileContent string
+```
+
+<a name="FileContentMap"></a>
+## type FileContentMap {#FileContentMap}
+
+FileContentMap represents a mapping of file paths to file contents. Paths are relative to the \`holos\` output "deploy" directory, and may contain sub\-directories.
+
+```go
+type FileContentMap map[FilePath]FileContent
+```
+
+<a name="FilePath"></a>
+## type FilePath {#FilePath}
+
+FilePath represents a file path.
+
+```go
+type FilePath string
+```
+
+<a name="HelmChart"></a>
+## type HelmChart {#HelmChart}
+
+HelmChart represents a holos component which wraps around an upstream helm chart. Holos orchestrates helm by providing values obtained from CUE, renders the output using \`helm template\`, then post\-processes the helm output yaml using the general functionality provided by [HolosComponent](<#HolosComponent>), for example [Kustomize](<#Kustomize>) post\-rendering and mixing in additional kubernetes api objects.
+
+```go
+type HelmChart struct {
+    HolosComponent `json:",inline"`
+    Kind           string `json:"kind" cue:"\"HelmChart\""`
+
+    // Chart represents a helm chart to manage.
+    Chart Chart `json:"chart"`
+    // ValuesContent represents the values.yaml file holos passes to the `helm
+    // template` command.
+    ValuesContent string `json:"valuesContent"`
+    // EnableHooks enables helm hooks when executing the `helm template` command.
+    EnableHooks bool `json:"enableHooks" cue:"bool | *false"`
+}
+```
+
+<a name="HolosComponent"></a>
+## type HolosComponent {#HolosComponent}
+
+HolosComponent defines the fields common to all holos component kinds. Every holos component kind should embed HolosComponent.
+
+```go
+type HolosComponent struct {
+    // Kind is a string value representing the resource this object represents.
+    Kind string `json:"kind"`
+    // APIVersion represents the versioned schema of this representation of an object.
+    APIVersion string `json:"apiVersion" cue:"string | *\"v1alpha2\""`
+    // Metadata represents data about the holos component such as the Name.
+    Metadata Metadata `json:"metadata"`
+
+    // APIObjectMap holds the marshalled representation of api objects.  Useful to
+    // mix in resources to each HolosComponent type, for example adding an
+    // ExternalSecret to a HelmChart HolosComponent.  Refer to [APIObjects].
+    APIObjectMap APIObjectMap `json:"apiObjectMap,omitempty"`
+
+    // DeployFiles represents file paths relative to the cluster deploy directory
+    // with the value representing the file content.  Intended for defining the
+    // ArgoCD Application resource or Flux Kustomization resource from within CUE,
+    // but may be used to render any file related to the build plan from CUE.
+    DeployFiles FileContentMap `json:"deployFiles,omitempty"`
+
+    // Kustomize represents a kubectl kustomize build post-processing step.
+    Kustomize `json:"kustomize,omitempty"`
+
+    // Skip causes holos to take no action regarding this component.
+    Skip bool `json:"skip" cue:"bool | *false"`
+}
+```
+
+<a name="Kind"></a>
+## type Kind {#Kind}
+
+Kind is a kubernetes api object kind. Defined as a type for clarity and type checking.
+
+```go
+type Kind string
+```
+
+<a name="KubernetesObjects"></a>
+## type KubernetesObjects {#KubernetesObjects}
+
+KubernetesObjects represents a [HolosComponent](<#HolosComponent>) composed of Kubernetes API objects provided directly from CUE using [APIObjects](<#APIObjects>).
+
+```go
+type KubernetesObjects struct {
+    HolosComponent `json:",inline"`
+    Kind           string `json:"kind" cue:"\"KubernetesObjects\""`
+}
+```
+
+<a name="Kustomize"></a>
+## type Kustomize {#Kustomize}
+
+Kustomize represents resources necessary to execute a kustomize build. Intended for at least two use cases:
+
+1. Process a [KustomizeBuild](<#KustomizeBuild>) [HolosComponent](<#HolosComponent>) which represents raw yaml file resources in a holos component directory.
+2. Post process a [HelmChart](<#HelmChart>) [HolosComponent](<#HolosComponent>) to inject istio, patch jobs, add custom labels, etc...
+
+```go
+type Kustomize struct {
+    // KustomizeFiles holds file contents for kustomize, e.g. patch files.
+    KustomizeFiles FileContentMap `json:"kustomizeFiles,omitempty"`
+    // ResourcesFile is the file name used for api objects in kustomization.yaml
+    ResourcesFile string `json:"resourcesFile,omitempty"`
+}
+```
+
+<a name="KustomizeBuild"></a>
+## type KustomizeBuild {#KustomizeBuild}
+
+KustomizeBuild represents a [HolosComponent](<#HolosComponent>) that renders plain yaml files in the holos component directory using \`kubectl kustomize build\`.
+
+```go
+type KustomizeBuild struct {
+    HolosComponent `json:",inline"`
+    Kind           string `json:"kind" cue:"\"KustomizeBuild\""`
+}
+```
+
+<a name="Label"></a>
+## type Label {#Label}
+
+Label is an arbitrary unique identifier internal to holos itself. The holos cli is expected to never write a Label value to rendered output files, therefore use a [Label](<#Label>) then the identifier must be unique and internal. Defined as a type for clarity and type checking.
+
+A Label is useful to convert a CUE struct to a list, for example producing a list of [APIObject](<#APIObject>) resources from an [APIObjectMap](<#APIObjectMap>). A CUE struct using Label keys is guaranteed to not lose data when rendering output because a Label is expected to never be written to the final output.
+
+```go
+type Label string
+```
+
+<a name="Metadata"></a>
+## type Metadata {#Metadata}
+
+Metadata represents data about the holos component such as the Name.
+
+```go
+type Metadata struct {
+    // Name represents the name of the holos component.
+    Name string `json:"name"`
+    // Namespace is the primary namespace of the holos component.  A holos
+    // component may manage resources in multiple namespaces, in this case
+    // consider setting the component namespace to default.
+    //
+    // This field is optional because not all resources require a namespace,
+    // particularly CRD's and DeployFiles functionality.
+    // +optional
+    Namespace string `json:"namespace,omitempty"`
+}
+```
+
+<a name="Platform"></a>
+## type Platform {#Platform}
+
+Platform represents a platform to manage. A Platform resource informs holos which components to build. The platform resource also acts as a container for the platform model form values provided by the PlatformService. The primary use case is to collect the cluster names, cluster types, platform model, and holos components to build into one resource.
+
+```go
+type Platform struct {
+    // Kind is a string value representing the resource this object represents.
+    Kind string `json:"kind" cue:"\"Platform\""`
+    // APIVersion represents the versioned schema of this representation of an object.
+    APIVersion string `json:"apiVersion" cue:"string | *\"v1alpha2\""`
+    // Metadata represents data about the object such as the Name.
+    Metadata PlatformMetadata `json:"metadata"`
+
+    // Spec represents the specification.
+    Spec PlatformSpec `json:"spec"`
+}
+```
+
+<a name="PlatformMetadata"></a>
+## type PlatformMetadata {#PlatformMetadata}
+
+
+
+```go
+type PlatformMetadata struct {
+    // Name represents the Platform name.
+    Name string `json:"name"`
+}
+```
+
+<a name="PlatformSpec"></a>
+## type PlatformSpec {#PlatformSpec}
+
+PlatformSpec represents the specification of a Platform. Think of a platform specification as a list of platform components to apply to a list of kubernetes clusters combined with the user\-specified Platform Model.
+
+```go
+type PlatformSpec struct {
+    // Model represents the platform model holos gets from from the
+    // PlatformService.GetPlatform rpc method and provides to CUE using a tag.
+    Model structpb.Struct `json:"model"`
+    // Components represents a list of holos components to manage.
+    Components []PlatformSpecComponent `json:"components"`
+}
+```
+
+<a name="PlatformSpecComponent"></a>
+## type PlatformSpecComponent {#PlatformSpecComponent}
+
+PlatformSpecComponent represents a holos component to build or render.
+
+```go
+type PlatformSpecComponent struct {
+    // Path is the path of the component relative to the platform root.
+    Path string `json:"path"`
+    // Cluster is the cluster name to provide when rendering the component.
+    Cluster string `json:"cluster"`
+}
+```
+
+<a name="Repository"></a>
+## type Repository {#Repository}
+
+Repository represents a helm chart repository.
+
+```go
+type Repository struct {
+    Name string `json:"name"`
+    URL  string `json:"url"`
+}
+```
+
+Generated by [gomarkdoc](<https://github.com/princjef/gomarkdoc>)

doc/md/api/core/v1alpha3.md

@@ -0,0 +1,403 @@
+<!-- Code generated by gomarkdoc. DO NOT EDIT -->
+
+# v1alpha3
+
+```go
+import "github.com/holos-run/holos/api/core/v1alpha3"
+```
+
+Package v1alpha3 contains the core API contract between the holos cli and CUE configuration code. Platform designers, operators, and software developers use this API to write configuration in CUE which \`holos\` loads. The overall shape of the API defines imperative actions \`holos\` should carry out to render the complete yaml that represents a Platform.
+
+[Platform](<#Platform>) defines the complete configuration of a platform. With the holos reference platform this takes the shape of one management cluster and at least two workload cluster. Each cluster has multiple [Component](<#Component>) resources applied to it.
+
+Each holos component path, e.g. \`components/namespaces\` produces exactly one [BuildPlan](<#BuildPlan>) which in turn contains a set of [Component](<#Component>) kinds.
+
+The primary kinds of [Component](<#Component>) are:
+
+1. [HelmChart](<#HelmChart>) to render config from a helm chart.
+2. [KustomizeBuild](<#KustomizeBuild>) to render config from [Kustomize](<#Kustomize>)
+3. [KubernetesObjects](<#KubernetesObjects>) to render [APIObjects](<#APIObjects>) defined directly in CUE configuration.
+
+Note that Holos operates as a data pipeline, so the output of a [HelmChart](<#HelmChart>) may be provided to [Kustomize](<#Kustomize>) for post\-processing.
+
+## Index
+
+- [Constants](<#constants>)
+- [type APIObject](<#APIObject>)
+- [type APIObjectMap](<#APIObjectMap>)
+- [type APIObjects](<#APIObjects>)
+- [type BuildPlan](<#BuildPlan>)
+- [type BuildPlanComponents](<#BuildPlanComponents>)
+- [type BuildPlanSpec](<#BuildPlanSpec>)
+- [type Chart](<#Chart>)
+- [type Component](<#Component>)
+- [type FileContent](<#FileContent>)
+- [type FileContentMap](<#FileContentMap>)
+- [type FilePath](<#FilePath>)
+- [type HelmChart](<#HelmChart>)
+- [type InternalLabel](<#InternalLabel>)
+- [type Kind](<#Kind>)
+- [type KubernetesObjects](<#KubernetesObjects>)
+- [type Kustomize](<#Kustomize>)
+- [type KustomizeBuild](<#KustomizeBuild>)
+- [type Metadata](<#Metadata>)
+- [type Platform](<#Platform>)
+- [type PlatformMetadata](<#PlatformMetadata>)
+- [type PlatformSpec](<#PlatformSpec>)
+- [type PlatformSpecComponent](<#PlatformSpecComponent>)
+- [type Repository](<#Repository>)
+
+
+## Constants
+
+<a name="APIVersion"></a>
+
+```go
+const (
+    APIVersion    = "v1alpha3"
+    BuildPlanKind = "BuildPlan"
+    HelmChartKind = "HelmChart"
+    // ChartDir is the directory name created in the holos component directory to cache a chart.
+    ChartDir = "vendor"
+    // ResourcesFile is the file name used to store component output when post-processing with kustomize.
+    ResourcesFile = "resources.yaml"
+)
+```
+
+<a name="KubernetesObjectsKind"></a>
+
+```go
+const KubernetesObjectsKind = "KubernetesObjects"
+```
+
+<a name="APIObject"></a>
+## type APIObject {#APIObject}
+
+APIObject represents the most basic generic form of a single kubernetes api object. Represented as a JSON object internally for compatibility between tools, for example loading from CUE.
+
+```go
+type APIObject structpb.Struct
+```
+
+<a name="APIObjectMap"></a>
+## type APIObjectMap {#APIObjectMap}
+
+APIObjectMap represents the marshalled yaml representation of kubernetes api objects. Do not produce an APIObjectMap directly, instead use [APIObjects](<#APIObjects>) to produce the marshalled yaml representation from CUE data, then provide the result to [Component](<#Component>).
+
+```go
+type APIObjectMap map[Kind]map[InternalLabel]string
+```
+
+<a name="APIObjects"></a>
+## type APIObjects {#APIObjects}
+
+APIObjects represents Kubernetes API objects defined directly from CUE code. Useful to mix in resources to any kind of [Component](<#Component>), for example adding an ExternalSecret resource to a [HelmChart](<#HelmChart>).
+
+[Kind](<#Kind>) must be the resource kind, e.g. Deployment or Service.
+
+[InternalLabel](<#InternalLabel>) is an arbitrary internal identifier to uniquely identify the resource within the context of a \`holos\` command. Holos will never write the intermediate label to rendered output.
+
+Refer to [Component](<#Component>) which accepts an [APIObjectMap](<#APIObjectMap>) field provided by [APIObjects](<#APIObjects>).
+
+```go
+type APIObjects struct {
+    APIObjects   map[Kind]map[InternalLabel]APIObject `json:"apiObjects"`
+    APIObjectMap APIObjectMap                         `json:"apiObjectMap"`
+}
+```
+
+<a name="BuildPlan"></a>
+## type BuildPlan {#BuildPlan}
+
+BuildPlan represents a build plan for the holos cli to execute. The purpose of a BuildPlan is to define one or more [Component](<#Component>) kinds. For example a [HelmChart](<#HelmChart>), [KustomizeBuild](<#KustomizeBuild>), or [KubernetesObjects](<#KubernetesObjects>).
+
+A BuildPlan usually has an additional empty [KubernetesObjects](<#KubernetesObjects>) for the purpose of using the [Component](<#Component>) DeployFiles field to deploy an ArgoCD or Flux gitops resource for the holos component.
+
+```go
+type BuildPlan struct {
+    Kind       string        `json:"kind" cue:"\"BuildPlan\""`
+    APIVersion string        `json:"apiVersion" cue:"string | *\"v1alpha3\""`
+    Spec       BuildPlanSpec `json:"spec"`
+}
+```
+
+<a name="BuildPlanComponents"></a>
+## type BuildPlanComponents {#BuildPlanComponents}
+
+
+
+```go
+type BuildPlanComponents struct {
+    Resources             map[InternalLabel]KubernetesObjects `json:"resources,omitempty"`
+    KubernetesObjectsList []KubernetesObjects                 `json:"kubernetesObjectsList,omitempty"`
+    HelmChartList         []HelmChart                         `json:"helmChartList,omitempty"`
+    KustomizeBuildList    []KustomizeBuild                    `json:"kustomizeBuildList,omitempty"`
+}
+```
+
+<a name="BuildPlanSpec"></a>
+## type BuildPlanSpec {#BuildPlanSpec}
+
+BuildPlanSpec represents the specification of the build plan.
+
+```go
+type BuildPlanSpec struct {
+    // Disabled causes the holos cli to take no action over the [BuildPlan].
+    Disabled bool `json:"disabled,omitempty"`
+    // Components represents multiple [HolosComponent] kinds to manage.
+    Components BuildPlanComponents `json:"components,omitempty"`
+}
+```
+
+<a name="Chart"></a>
+## type Chart {#Chart}
+
+Chart represents a helm chart.
+
+```go
+type Chart struct {
+    // Name represents the chart name.
+    Name string `json:"name"`
+    // Version represents the chart version.
+    Version string `json:"version"`
+    // Release represents the chart release when executing helm template.
+    Release string `json:"release"`
+    // Repository represents the repository to fetch the chart from.
+    Repository Repository `json:"repository,omitempty"`
+}
+```
+
+<a name="Component"></a>
+## type Component {#Component}
+
+Component defines the fields common to all holos component kinds. Every holos component kind should embed Component.
+
+```go
+type Component struct {
+    // Kind is a string value representing the resource this object represents.
+    Kind string `json:"kind"`
+    // APIVersion represents the versioned schema of this representation of an object.
+    APIVersion string `json:"apiVersion" cue:"\"v1alpha3\""`
+    // Metadata represents data about the holos component such as the Name.
+    Metadata Metadata `json:"metadata"`
+
+    // APIObjectMap holds the marshalled representation of api objects.  Useful to
+    // mix in resources to each Component type, for example adding an
+    // ExternalSecret to a [HelmChart] Component.  Refer to [APIObjects].
+    APIObjectMap APIObjectMap `json:"apiObjectMap,omitempty"`
+
+    // DeployFiles represents file paths relative to the cluster deploy directory
+    // with the value representing the file content.  Intended for defining the
+    // ArgoCD Application resource or Flux Kustomization resource from within CUE,
+    // but may be used to render any file related to the build plan from CUE.
+    DeployFiles FileContentMap `json:"deployFiles,omitempty"`
+
+    // Kustomize represents a kubectl kustomize build post-processing step.
+    Kustomize `json:"kustomize,omitempty"`
+
+    // Skip causes holos to take no action regarding this component.
+    Skip bool `json:"skip" cue:"bool | *false"`
+}
+```
+
+<a name="FileContent"></a>
+## type FileContent {#FileContent}
+
+FileContent represents file contents.
+
+```go
+type FileContent string
+```
+
+<a name="FileContentMap"></a>
+## type FileContentMap {#FileContentMap}
+
+FileContentMap represents a mapping of file paths to file contents.
+
+```go
+type FileContentMap map[FilePath]FileContent
+```
+
+<a name="FilePath"></a>
+## type FilePath {#FilePath}
+
+FilePath represents a file path.
+
+```go
+type FilePath string
+```
+
+<a name="HelmChart"></a>
+## type HelmChart {#HelmChart}
+
+HelmChart represents a holos component which wraps around an upstream helm chart. Holos orchestrates helm by providing values obtained from CUE, renders the output using \`helm template\`, then post\-processes the helm output yaml using the general functionality provided by [Component](<#Component>), for example [Kustomize](<#Kustomize>) post\-rendering and mixing in additional kubernetes api objects.
+
+```go
+type HelmChart struct {
+    Component `json:",inline"`
+    Kind      string `json:"kind" cue:"\"HelmChart\""`
+
+    // Chart represents a helm chart to manage.
+    Chart Chart `json:"chart"`
+    // ValuesContent represents the values.yaml file holos passes to the `helm
+    // template` command.
+    ValuesContent string `json:"valuesContent"`
+    // EnableHooks enables helm hooks when executing the `helm template` command.
+    EnableHooks bool `json:"enableHooks" cue:"bool | *false"`
+}
+```
+
+<a name="InternalLabel"></a>
+## type InternalLabel {#InternalLabel}
+
+InternalLabel is an arbitrary unique identifier internal to holos itself. The holos cli is expected to never write a InternalLabel value to rendered output files, therefore use a [InternalLabel](<#InternalLabel>) when the identifier must be unique and internal. Defined as a type for clarity and type checking.
+
+A InternalLabel is useful to convert a CUE struct to a list, for example producing a list of [APIObject](<#APIObject>) resources from an [APIObjectMap](<#APIObjectMap>). A CUE struct using InternalLabel keys is guaranteed to not lose data when rendering output because a InternalLabel is expected to never be written to the final output.
+
+```go
+type InternalLabel string
+```
+
+<a name="Kind"></a>
+## type Kind {#Kind}
+
+Kind is a kubernetes api object kind. Defined as a type for clarity and type checking.
+
+```go
+type Kind string
+```
+
+<a name="KubernetesObjects"></a>
+## type KubernetesObjects {#KubernetesObjects}
+
+KubernetesObjects represents a [Component](<#Component>) composed of Kubernetes API objects provided directly from CUE using [APIObjects](<#APIObjects>).
+
+```go
+type KubernetesObjects struct {
+    Component `json:",inline"`
+    Kind      string `json:"kind" cue:"\"KubernetesObjects\""`
+}
+```
+
+<a name="Kustomize"></a>
+## type Kustomize {#Kustomize}
+
+Kustomize represents resources necessary to execute a kustomize build. Intended for at least two use cases:
+
+1. Process a [KustomizeBuild](<#KustomizeBuild>) [Component](<#Component>) which represents raw yaml file resources in a holos component directory.
+2. Post process a [HelmChart](<#HelmChart>) [Component](<#Component>) to inject istio, patch jobs, add custom labels, etc...
+
+```go
+type Kustomize struct {
+    // KustomizeFiles holds file contents for kustomize, e.g. patch files.
+    KustomizeFiles FileContentMap `json:"kustomizeFiles,omitempty"`
+    // ResourcesFile is the file name used for api objects in kustomization.yaml
+    ResourcesFile string `json:"resourcesFile,omitempty"`
+}
+```
+
+<a name="KustomizeBuild"></a>
+## type KustomizeBuild {#KustomizeBuild}
+
+KustomizeBuild represents a [Component](<#Component>) that renders plain yaml files in the holos component directory using \`kubectl kustomize build\`.
+
+```go
+type KustomizeBuild struct {
+    Component `json:",inline"`
+    Kind      string `json:"kind" cue:"\"KustomizeBuild\""`
+}
+```
+
+<a name="Metadata"></a>
+## type Metadata {#Metadata}
+
+Metadata represents data about the object such as the Name.
+
+```go
+type Metadata struct {
+    // Name represents the name of the holos component.
+    Name string `json:"name"`
+    // Namespace is the primary namespace of the holos component.  A holos
+    // component may manage resources in multiple namespaces, in this case
+    // consider setting the component namespace to default.
+    //
+    // This field is optional because not all resources require a namespace,
+    // particularly CRDs and DeployFiles functionality.
+    // +optional
+    Namespace string `json:"namespace,omitempty"`
+}
+```
+
+<a name="Platform"></a>
+## type Platform {#Platform}
+
+Platform represents a platform to manage. A Platform resource informs holos which components to build. The platform resource also acts as a container for the platform model form values provided by the PlatformService. The primary use case is to collect the cluster names, cluster types, platform model, and holos components to build into one resource.
+
+```go
+type Platform struct {
+    // Kind is a string value representing the resource this object represents.
+    Kind string `json:"kind" cue:"\"Platform\""`
+    // APIVersion represents the versioned schema of this representation of an object.
+    APIVersion string `json:"apiVersion" cue:"string | *\"v1alpha3\""`
+    // Metadata represents data about the object such as the Name.
+    Metadata PlatformMetadata `json:"metadata"`
+
+    // Spec represents the specification.
+    Spec PlatformSpec `json:"spec"`
+}
+```
+
+<a name="PlatformMetadata"></a>
+## type PlatformMetadata {#PlatformMetadata}
+
+
+
+```go
+type PlatformMetadata struct {
+    // Name represents the Platform name.
+    Name string `json:"name"`
+}
+```
+
+<a name="PlatformSpec"></a>
+## type PlatformSpec {#PlatformSpec}
+
+PlatformSpec represents the specification of a Platform. Think of a platform specification as a list of platform components to apply to a list of kubernetes clusters combined with the user\-specified Platform Model.
+
+```go
+type PlatformSpec struct {
+    // Model represents the platform model holos gets from from the
+    // PlatformService.GetPlatform rpc method and provides to CUE using a tag.
+    Model structpb.Struct `json:"model" cue:"{...}"`
+    // Components represents a list of holos components to manage.
+    Components []PlatformSpecComponent `json:"components"`
+}
+```
+
+<a name="PlatformSpecComponent"></a>
+## type PlatformSpecComponent {#PlatformSpecComponent}
+
+PlatformSpecComponent represents a holos component to build or render.
+
+```go
+type PlatformSpecComponent struct {
+    // Path is the path of the component relative to the platform root.
+    Path string `json:"path"`
+    // Cluster is the cluster name to provide when rendering the component.
+    Cluster string `json:"cluster"`
+}
+```
+
+<a name="Repository"></a>
+## type Repository {#Repository}
+
+Repository represents a helm chart repository.
+
+```go
+type Repository struct {
+    Name string `json:"name"`
+    URL  string `json:"url"`
+}
+```
+
+Generated by [gomarkdoc](<https://github.com/princjef/gomarkdoc>)

doc/md/archive/guides/2024-09-15-quickstart.mdx

@@ -0,0 +1,724 @@
+---
+description: Try Holos with this quick start guide.
+slug: /archive/2024-09-15-quickstart
+sidebar_position: 100
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+import Admonition from '@theme/Admonition';
+
+# Quickstart
+
+In this guide, you'll experience how Holos makes the process of operating a
+Platform safer, easier, and more consistent. We'll use Holos to manage a
+vendor-provided Helm chart as a Component. Next, we'll mix in our own custom
+resources to manage the Component with GitOps. Finally, you'll see how Holos
+makes it safer and easier to maintain software over time by surfacing the exact
+changes that will be applied when upgrading the vendor's chart to a new version,
+before they are actually made.
+
+The [Concepts](/docs/concepts) page defines capitalized terms such as Platform
+and Component.
+
+## What you'll need {#requirements}
+
+You'll need the following tools installed to complete this guide.
+
+1. [holos](/docs/install) - to build the Platform.
+2. [helm](https://helm.sh/docs/intro/install/) - to render Holos Components that
+wrap upstream Helm charts.
+
+Optionally, if you'd like to apply the rendered manifests to a real Cluster,
+first complete the [Local Cluster Guide](/docs/guides/local-cluster).
+
+## Install Holos
+
+Install Holos with the following command or other methods listed on the
+[Installation](/docs/install/) page.
+
+```bash
+go install github.com/holos-run/holos/cmd/holos@latest
+```
+
+## Create a Git Repository
+
+Start by initializing an empty Git repository. Holos operates on local files
+stored in a Git repository.
+
+<Tabs groupId="init">
+  <TabItem value="command" label="Command">
+    ```bash
+    mkdir holos-quickstart
+    cd holos-quickstart
+    git init
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+    ```txt
+    Initialized empty Git repository in /holos-quickstart/.git/
+    ```
+  </TabItem>
+</Tabs>
+
+This guide assumes you will run commands from the root directory of the Git
+repository unless stated otherwise.
+
+## Generate the Platform {#Generate-Platform}
+
+Generate the Platform code in the repository root. A Platform refers to the
+entire set of software holistically integrated to provide a software development
+platform for your organization. In this guide, the Platform will include a
+single Component to demonstrate how the concepts fit together.
+
+```bash
+holos generate platform quickstart
+```
+
+Commit the generated platform config to the repository.
+
+<Tabs groupId="commit-platform">
+  <TabItem value="command" label="Command">
+    ```bash
+    git add .
+    git commit -m "holos generate platform quickstart - $(holos --version)"
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+    ```txt
+    [main (root-commit) 0b17b7f] holos generate platform quickstart
+     213 files changed, 72349 insertions(+)
+     ...
+    ```
+  </TabItem>
+</Tabs>
+
+## Generate a Component {#generate-component}
+
+The platform you generated is currently empty. Run the following command to
+generate the CUE code that defines a Helm Component.
+
+<Tabs groupId="gen-podinfo">
+  <TabItem value="command" label="Command">
+    ```bash
+    holos generate component podinfo --component-version 6.6.1
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+    ```txt
+    generated component
+    ```
+  </TabItem>
+</Tabs>
+
+The --component-version 6.6.1 flag intentionally installs an older release.
+You'll see how Holos assists with software upgrades later in this guide.
+
+The generate component command creates two files: a leaf file,
+`components/podinfo/podinfo.gen.cue`, and a root file, `podinfo.gen.cue`. Holos
+leverages the fact that [order is
+irrelevant](https://cuelang.org/docs/tour/basics/order-irrelevance/) in CUE to
+register the component with the Platform by adding a file to the root of the Git
+repository. The second file defines the component in the leaf component
+directory.
+
+<Tabs groupId="podinfo-files">
+  <TabItem value="components/podinfo/podinfo.gen.cue" label="Leaf">
+    `components/podinfo/podinfo.gen.cue`
+    ```cue showLineNumbers
+    package holos
+
+    // Produce a helm chart build plan.
+    (#Helm & Chart).Output
+
+    let Chart = {
+      Name:      "podinfo"
+      Version:   "6.6.1"
+      Namespace: "default"
+
+      Repo: name: "podinfo"
+      Repo: url:  "https://stefanprodan.github.io/podinfo"
+
+      Values: {}
+    }
+    ```
+  </TabItem>
+  <TabItem value="podinfo.gen.cue" label="Root">
+    `podinfo.gen.cue`
+    ```cue showLineNumbers
+    package holos
+
+    // Manage podinfo on workload clusters only
+    for Cluster in #Fleets.workload.clusters {
+      #Platform: Components: "\(Cluster.name)/podinfo": {
+        path:    "components/podinfo"
+        cluster: Cluster.name
+      }
+    }
+    ```
+  </TabItem>
+</Tabs>
+
+In this example, we provide the minimal information needed to manage the Helm
+chart: the name, version, Kubernetes namespace for deployment, and the chart
+repository location.
+
+This chart deploys cleanly without any values provided, but we include an empty
+Values struct to show how Holos improves consistency and safety in Helm by
+leveraging the strong type-checking in CUE. You can safely pass shared values,
+such as the organization’s domain name, to all Components across all clusters in
+the Platform by defining them at the root of the configuration.
+
+Commit the generated component config to the repository.
+
+<Tabs groupId="commit-component">
+  <TabItem value="command" label="Command">
+    ```bash
+    git add .
+    git commit -m "holos generate component podinfo - $(holos --version)"
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+    ```txt
+    [main cc0e90c] holos generate component podinfo
+     2 files changed, 24 insertions(+)
+     create mode 100644 components/podinfo/podinfo.gen.cue
+     create mode 100644 podinfo.gen.cue
+    ```
+  </TabItem>
+</Tabs>
+
+## Render the Component
+
+You can render individual components without adding them to a Platform, which is
+helpful when developing a new component.
+
+<Tabs groupId="render-podinfo">
+  <TabItem value="command" label="Command">
+    ```bash
+    holos render component ./components/podinfo --cluster-name=default
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+    ```txt
+    cached
+    rendered podinfo
+    ```
+  </TabItem>
+</Tabs>
+
+First, the command caches the Helm chart locally to speed up subsequent
+renderings. Then, the command runs Helm to produce the output and writes it into
+the deploy directory.
+
+<Tabs groupId="tree-podinfo">
+  <TabItem value="command" label="Command">
+    ```bash
+    tree deploy
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+    ```txt
+    deploy
+    └── clusters
+        └── default
+            └── components
+                └── podinfo
+                    └── podinfo.gen.yaml
+
+    5 directories, 1 file
+    ```
+  </TabItem>
+</Tabs>
+
+The component deploys to one cluster named `default`. In practice, the same
+component is often deployed to multiple clusters, such as `east` and `west` to
+provide redundancy and increase availability.
+
+:::tip
+This example is equivalent to running `helm template` on the chart and saving
+the output to a file. Holos simplifies this task, making it safer and more
+consistent when managing many charts.
+:::
+
+## Mix in an ArgoCD Application
+
+We've seen how Holos works with Helm, but we haven't yet explored how Holos
+makes it easier to consistently and safely manage all of the software in a
+Platform.
+
+Holos allows you to easily mix in resources that differentiate your Platform.
+We'll use this feature to mix in an ArgoCD [Application][application] to manage
+the podinfo Component with GitOps. We'll define this configuration in a way that
+can be automatically and consistently reused across all future Components added
+to the Platform.
+
+Create a new file named `argocd.cue` in the root of your Git repository with the
+following contents:
+
+<Tabs groupId="argocd-config">
+  <TabItem value="command" label="argocd.cue">
+    ```cue showLineNumbers
+    package holos
+
+    #ArgoConfig: {
+      Enabled: true
+      RepoURL: "https://github.com/holos-run/holos-quickstart-guide"
+    }
+    ```
+  </TabItem>
+</Tabs>
+
+:::tip
+If you plan to apply the rendered output to a real cluster, change the
+`example.com` RepoURL to the URL of the Git repository you created in this
+guide. You don't need to change the example if you're just exploring Holos by
+inspecting the rendered output without applying it to a live cluster.
+:::
+
+With this file in place, render the component again.
+
+<Tabs groupId="render-podinfo-argocd">
+  <TabItem value="command" label="Command">
+    ```bash
+    holos render component ./components/podinfo --cluster-name=default
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+    ```txt
+    wrote deploy file
+    rendered gitops/podinfo
+    rendered podinfo
+    ```
+  </TabItem>
+</Tabs>
+
+Holos uses the locally cached chart to improve performance and reliability. It
+then renders the Helm template output along with an ArgoCD Application resource
+for GitOps.
+
+:::tip
+By defining the ArgoCD configuration at the root, we again take advantage of the
+fact that [order is
+irrelevant](https://cuelang.org/docs/tour/basics/order-irrelevance/) in CUE.
+:::
+
+Defining the configuration at the root ensures all future leaf Components take
+the ArgoCD configuration and render an Application manifest for GitOps
+management.
+
+<Tabs groupId="tree-podinfo-argocd">
+  <TabItem value="command" label="Command">
+    ```bash
+    tree deploy
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+    ```txt
+    deploy
+    └── clusters
+        └── default
+            ├── components
+            │   └── podinfo
+            │       └── podinfo.gen.yaml
+            └── gitops
+                └── podinfo.application.gen.yaml
+
+    6 directories, 2 files
+    ```
+  </TabItem>
+</Tabs>
+
+Notice the new `podinfo.application.gen.yaml` file created by enabling ArgoCD in
+the Helm component. The Application resource in the file looks like this:
+
+<Tabs groupId="podinfo-application">
+  <TabItem value="file" label="podinfo.application.gen.yaml">
+    ```yaml showLineNumbers
+    apiVersion: argoproj.io/v1alpha1
+    kind: Application
+    metadata:
+      name: podinfo
+      namespace: argocd
+    spec:
+      destination:
+        server: https://kubernetes.default.svc
+      project: default
+      source:
+        path: ./deploy/clusters/default/components/podinfo
+        repoURL: https://example.com/holos-quickstart.git
+        targetRevision: main
+    ```
+  </TabItem>
+</Tabs>
+
+:::tip
+Holos generates a similar Application resource for every additional Component
+added to your Platform.
+:::
+
+Finally, add and commit the results to your Platform's Git repository.
+
+<Tabs groupId="commit-argo">
+  <TabItem value="command" label="Command">
+    ```bash
+    git add .
+    git commit -m "holos render component ./components/podinfo --cluster-name=default"
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+    ```txt
+    [main f95cef1] holos render component ./components/podinfo --cluster-name=default
+     3 files changed, 134 insertions(+)
+     create mode 100644 argocd.cue
+     create mode 100644 deploy/clusters/default/components/podinfo/podinfo.gen.yaml
+     create mode 100644 deploy/clusters/default/gitops/podinfo.application.gen.yaml
+    ```
+  </TabItem>
+</Tabs>
+
+In this section, we learned how Holos simplifies mixing resources into
+Components, like an ArgoCD Application. Holos ensures consistency by managing an
+Application resource for every Component added to the Platform through the
+configuration you define in `argocd.cue` at the root of the repository.
+
+## Define Workload Clusters {#workload-clusters}
+
+We've generated a Component to manage podinfo and integrated it with our
+Platform, but rendering the Platform doesn't render podinfo. Podinfo isn't
+rendered because we haven't assigned any Clusters to the workload Fleet.
+
+Define two new clusters, `east` and `west`, and assign them to the workload
+Fleet. Create a new file named `clusters.cue` in the root of your Git repository
+with the following contents:
+
+<Tabs groupId="clusters">
+  <TabItem value="clusters.cue" label="clusters.cue">
+    ```cue showLineNumbers
+    package holos
+
+    // Define two workload clusters for disaster recovery.
+    #Fleets: workload: clusters: {
+      // In CUE _ indicates values are defined elsewhere.
+      east: _
+      west: _
+    }
+    ```
+  </TabItem>
+</Tabs>
+
+This example shows how Holos simplifies configuring multiple clusters with
+similar configuration by grouping them into a Fleet.
+
+:::tip
+Fleets help segment a group of Clusters into one leader and multiple followers
+by designating one cluster as the primary. Holos makes it safer, easier, and
+more consistent to reconfigure which cluster is the primary. The primary can be
+set to automatically restore persistent data from backups, while non-primary
+clusters can be configured to automatically replicate from the primary.
+
+Automatic database backup, restore, and streaming replication is an advanced
+topic enabled by Cloud Native PG and CUE. Check back for a guide on this and
+other Day 2 operations topics.
+:::
+
+## Render the Platform {#render-platform}
+
+Render the Platform to render the podinfo Component for each of the workload
+clusters.
+
+<Tabs groupId="render-platform">
+  <TabItem value="command" label="Command">
+    ```bash
+    holos render platform ./platform
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+    ```txt
+    rendered components/podinfo for cluster west in 99.480792ms
+    rendered components/podinfo for cluster east in 99.882667ms
+    ```
+  </TabItem>
+</Tabs>
+
+The render platform command iterates over every Cluster in the Fleet and renders
+each Component assigned to the Fleet. Notice the two additional subdirectories
+created under the deploy directory, one for each cluster: `east` and `west`.
+
+<Tabs groupId="tree-platform">
+  <TabItem value="command" label="Command">
+    ```bash
+    tree deploy
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+    ```txt
+    deploy
+    └── clusters
+        ├── default
+        │   ├── components
+        │   │   └── podinfo
+        │   │       └── podinfo.gen.yaml
+        │   └── gitops
+        │       └── podinfo.application.gen.yaml
+        # highlight-next-line
+        ├── east
+        │   ├── components
+        │   │   └── podinfo
+        │   │       └── podinfo.gen.yaml
+        │   └── gitops
+        │       └── podinfo.application.gen.yaml
+        # highlight-next-line
+        └── west
+            ├── components
+            │   └── podinfo
+            │       └── podinfo.gen.yaml
+            └── gitops
+                └── podinfo.application.gen.yaml
+
+    14 directories, 6 files
+    ```
+  </TabItem>
+</Tabs>
+
+Holos ensures consistency and safety by defining the ArgoCD Application once,
+with strong type checking, at the configuration root.
+
+New Application resources are automatically generated for the `east` and `west`
+workload Clusters.
+
+<Tabs groupId="applications">
+  <TabItem value="east" label="east">
+  `deploy/clusters/east/gitops/podinfo.application.gen.yaml`
+```yaml showLineNumbers
+apiVersion: argoproj.io/v1alpha1
+kind: Application
+metadata:
+  name: podinfo
+  namespace: argocd
+spec:
+  destination:
+    server: https://kubernetes.default.svc
+  project: default
+  source:
+    # highlight-next-line
+    path: ./deploy/clusters/east/components/podinfo
+    repoURL: https://example.com/holos-quickstart.git
+    targetRevision: main
+```
+  </TabItem>
+  <TabItem value="west" label="west">
+  `deploy/clusters/west/gitops/podinfo.application.gen.yaml`
+```yaml showLineNumbers
+apiVersion: argoproj.io/v1alpha1
+kind: Application
+metadata:
+  name: podinfo
+  namespace: argocd
+spec:
+  destination:
+    server: https://kubernetes.default.svc
+  project: default
+  source:
+    # highlight-next-line
+    path: ./deploy/clusters/west/components/podinfo
+    repoURL: https://example.com/holos-quickstart.git
+    targetRevision: main
+```
+  </TabItem>
+  <TabItem value="default" label="default">
+  `deploy/clusters/default/gitops/podinfo.application.gen.yaml`
+```yaml showLineNumbers
+apiVersion: argoproj.io/v1alpha1
+kind: Application
+metadata:
+  name: podinfo
+  namespace: argocd
+spec:
+  destination:
+    server: https://kubernetes.default.svc
+  project: default
+  source:
+    # highlight-next-line
+    path: ./deploy/clusters/default/components/podinfo
+    repoURL: https://example.com/holos-quickstart.git
+    targetRevision: main
+```
+  </TabItem>
+</Tabs>
+
+Add and commit the rendered Platform and workload Clusters.
+
+<Tabs groupId="commit-render-platform">
+  <TabItem value="command" label="Command">
+    ```bash
+    git add .
+    git commit -m "holos render platform ./platform - $(holos --version)"
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+    ```txt
+    [main 5aebcf5] holos render platform ./platform - 0.93.2
+     5 files changed, 263 insertions(+)
+     create mode 100644 clusters.cue
+     create mode 100644 deploy/clusters/east/components/podinfo/podinfo.gen.yaml
+     create mode 100644 deploy/clusters/east/gitops/podinfo.application.gen.yaml
+     create mode 100644 deploy/clusters/west/components/podinfo/podinfo.gen.yaml
+     create mode 100644 deploy/clusters/west/gitops/podinfo.application.gen.yaml
+    ```
+  </TabItem>
+</Tabs>
+
+## Upgrade a Helm Chart
+
+Holos is designed to ease the burden of Day 2 operations. With Holos, upgrading
+software, integrating new software, and making safe platform-wide configuration
+changes become easier.
+
+Let's upgrade the podinfo Component to see how this works in practice. First,
+update the Component version field to the latest upstream Helm chart version.
+
+<Tabs groupId="gen-podinfo">
+  <TabItem value="command" label="Command">
+    ```bash
+    holos generate component podinfo --component-version 6.6.2
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+    ```txt
+    generated component
+    ```
+  </TabItem>
+</Tabs>
+
+Remove the cached chart version.
+
+<Tabs groupId="gen-podinfo">
+  <TabItem value="command" label="Command">
+    ```bash
+    rm -rf components/podinfo/vendor
+    ```
+  </TabItem>
+</Tabs>
+
+Now re-render the Platform.
+
+<Tabs groupId="render-platform2">
+  <TabItem value="command" label="Command">
+    ```bash
+    holos render platform ./platform
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+    ```txt
+    rendered components/podinfo for cluster east in 327.10475ms
+    rendered components/podinfo for cluster west in 327.796541ms
+    ```
+  </TabItem>
+</Tabs>
+
+Notice we're still using the upstream chart without modifying it. The Holos
+component wraps around the chart to mix in additional resources and integrate
+the component with the broader Platform.
+
+## Visualize the Changes
+
+Holos makes it easier to see exactly what changes are made and which resources
+will be applied to the API server. By design, Holos operates on local files,
+leaving the task of applying them to ecosystem tools like `kubectl` and ArgoCD.
+This allows platform operators to inspect changes during code review, or before
+committing the change at all.
+
+For example, using `git diff`, we see that the only functional change when
+upgrading this Helm chart is the deployment of a new container image tag to each
+cluster.  Additionally, we can roll out this change gradually by applying it to
+the east cluster first, then to the west cluster, limiting the potential blast
+radius of a problematic change.
+
+<Tabs groupId="git-diff">
+  <TabItem value="command" label="Command">
+    ```bash
+    git diff deploy/clusters/east
+    ```
+  </TabItem>
+  <TabItem value="output" label="Output">
+```diff showLineNumbers
+diff --git a/deploy/clusters/east/components/podinfo/podinfo.gen.yaml b/deploy/clusters/east/components/podinfo/podinfo.gen.yaml
+index 7cc3332..8c1647d 100644
+--- a/deploy/clusters/east/components/podinfo/podinfo.gen.yaml
++++ b/deploy/clusters/east/components/podinfo/podinfo.gen.yaml
+@@ -5,9 +5,9 @@ kind: Service
+ metadata:
+   name: podinfo
+   labels:
+-    helm.sh/chart: podinfo-6.6.1
++    helm.sh/chart: podinfo-6.6.2
+     app.kubernetes.io/name: podinfo
+-    app.kubernetes.io/version: "6.6.1"
++    app.kubernetes.io/version: "6.6.2"
+     app.kubernetes.io/managed-by: Helm
+ spec:
+   type: ClusterIP
+@@ -29,9 +29,9 @@ kind: Deployment
+ metadata:
+   name: podinfo
+   labels:
+-    helm.sh/chart: podinfo-6.6.1
++    helm.sh/chart: podinfo-6.6.2
+     app.kubernetes.io/name: podinfo
+-    app.kubernetes.io/version: "6.6.1"
++    app.kubernetes.io/version: "6.6.2"
+     app.kubernetes.io/managed-by: Helm
+ spec:
+   replicas: 1
+@@ -53,7 +53,7 @@ spec:
+       terminationGracePeriodSeconds: 30
+       containers:
+         - name: podinfo
+         # highlight-next-line
+-          image: "ghcr.io/stefanprodan/podinfo:6.6.1"
+         # highlight-next-line
++          image: "ghcr.io/stefanprodan/podinfo:6.6.2"
+           imagePullPolicy: IfNotPresent
+           command:
+             - ./podinfo
+```
+  </TabItem>
+</Tabs>
+
+:::tip
+Holos is designed to surface the _fully rendered_ manifests intended for the
+Kubernetes API server, making it easier to see and reason about platform-wide
+configuration changes.
+:::
+
+## Recap {#recap}
+
+In this quickstart guide, we learned how Holos makes it easier, safer, and more
+consistent to manage a Platform composed of multiple Clusters and upstream Helm
+charts.
+
+We covered how to:
+
+1. Generate a Git repository for the Platform config.
+2. Wrap the unmodified upstream podinfo Helm chart into a Component.
+3. Render an individual Component.
+4. Mix-in your Platform's unique resources to all Components.  For example, ArgoCD Application resources.
+5. Define multiple similar, but not identical, workload clusters.
+6. Render the manifests for the entire Platform with the `holos render platform` command.
+7. Upgrade a Helm chart to the latest version as an important Day 2 task.
+8. Visualize and surface the details of planned changes Platform wide.
+
+## Dive Deeper
+
+If you'd like to dive deeper, check out the [Schema API][schema] and [Core
+API][core] reference docs. The main difference between the schema and core
+packages is that the schema is used by users to write refined CUE, while the
+core package is what the schema produces for `holos` to execute. Users rarely
+need to interact with the Core API when on the happy path, but can use the core
+package as an escape hatch when the happy path doesn't go where you want.
+
+
+[application]: https://argo-cd.readthedocs.io/en/stable/user-guide/application-specification/
+[schema]: /docs/api/author/v1alpha3/
+[core]: /docs/api/core/v1alpha3/

doc/md/archive/guides/2024-09-17-manage-a-project.mdx

@@ -0,0 +1,106 @@
+---
+description: Self service platform resource management for project teams.
+slug: /archive/guides/2024-09-17-manage-a-project
+sidebar_position: 250
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+import Admonition from '@theme/Admonition';
+
+# Manage a Project
+
+In this guide we'll explore how Holos easily, safely, and consistently manages
+platform resources for teams to develop the projects they're working on.
+
+Intended Audience: Platform Engineers and Software Engineers.
+
+Goal is to demonstrate how the platform team can consistently, easily, and
+safely provide platform resources to software engineers.
+
+Assumption is software engineers have a container they want to deploy onto the
+platform and make accessible.  We'll use httpbin as a stand-in for the dev
+team's container.
+
+Project is roughly equivalent to Dev Team for the purpose of this guide, but in
+practice multiple teams work on a given project over the lifetime of the
+project, so we structure the files into projects instead of teams.
+
+## What you'll need {#requirements}
+
+You'll need the following tools installed to complete this guide.
+
+1. [holos](/docs/install) - to build the Platform.
+2. [helm](https://helm.sh/docs/intro/install/) - to render Helm Components.
+3. [kubectl](https://kubernetes.io/docs/tasks/tools/) - to render Kustomize Components.
+
+If you'd like to apply the manifests we render in this guide complete the
+following optional, but recommended, steps.
+
+a. Complete the [Local Cluster] guide to set up a local cluster to work with.
+b. You'll need a GitHub account to fork the repository associated with this
+guide.
+
+## Fork the Guide Repository
+
+<Tabs groupId="fork">
+  <TabItem value="command" label="Command">
+```bash
+```
+  </TabItem>
+  <TabItem value="output" label="Output">
+```txt showLineNumbers
+```
+  </TabItem>
+</Tabs>
+
+This guide assumes you will run commands from the root directory of this
+repository unless stated otherwise.
+
+[Quickstart]: /docs/quickstart
+[Local Cluster]: /docs/guides/local-cluster
+
+## Render the Platform
+
+So we can build the basic platform.  Don't dwell on the platform bits.
+
+## Apply the Manifests
+
+Deploy ArgoCD, but not any of the Application resources.
+
+## Browse to ArgoCD
+
+Note there is nothing here yet.
+
+## Switch to your Fork
+
+Note all of the Applications change consistently.
+
+## Apply the Applications
+
+Note how ArgoCD takes over management, no longer need to k apply.
+
+## Create a Project
+
+Project is a conceptual, not technical, thing in Holos.  Mainly about how components are laid out in the filesystem tree.
+
+We use a schematic built into holos as an example, the platform team could use the same or provide a similar template and instructions for development teams to self-serve.
+
+## Render the Platform
+
+Notice:
+
+1. Project is registered with the platform at the root.
+2. HTTPRoute and Namespace resources are added close to the root in `projects`
+3. Deployment and Service resources are added at the leaf in `projects/httpbin/backend`
+
+## Update the image tag
+
+Add a basic schematic to demonstrate this.  May need to add two new flags for image url and image tag to the generate subcommand, but should just be two new fields on the struct.
+
+## Dive Deeper
+
+Set the stage for constraints.  Ideas: Limit what resources can be added,
+namespaces can be operated in, enforce labels, etc...
+
+Simple, consistent, easy constraints.

doc/md/archive/guides/argocd/index.mdx

@@ -0,0 +1,6 @@
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# ArgoCD
+
+Coming soon.

doc/md/archive/guides/backstage/index.md

@@ -0,0 +1,3 @@
+# Backstage
+
+Coming soon.

doc/md/archive/guides/observability/index.md

@@ -0,0 +1,3 @@
+# Observability
+
+Coming soon.

doc/md/archive/guides/overview.md

@@ -0,0 +1,17 @@
+# Overview
+
+<!-- https://kubernetes.io/docs/contribute/style/diagram-guide/ -->
+
+This tutorial covers the following process of getting started with Holos.
+
+```mermaid
+graph LR
+    A[1. Install <br>holos] -->
+    B[2. Register <br>account] -->
+    C[3. Generate <br>platform] -->
+    D[4. Render <br>platform] -->
+    E[5. Apply <br>config]
+ 
+    classDef box fill:#fff,stroke:#000,stroke-width:1px,color:#000;
+    class A,B,C,D,E box
+```

doc/md/archive/guides/register.md

@@ -0,0 +1,62 @@
+# Registration
+
+Holos leverages a simple web app to collect and store platform attributes with a web form.  Register an account with the web app to create and retrieve the platform model.
+
+```
+holos register user
+```
+
+:::tip
+
+Holos allows you to customize all of the sections and fields of your platform model.
+
+:::
+
+
+## Generate your Platform
+
+Generate your platform configuration from the holos reference platform embedded in the `holos` executable.  Platform configuration is stored in a git repository.
+
+```bash
+mkdir holos-infra
+cd holos-infra
+holos generate platform holos
+```
+
+The generate command writes many files organized by platform component into the current directory
+
+TODO: Put a table here describing key elements?
+
+:::tip
+
+Take a peek at `holos generate platform --help` to see other platforms embedded in the holos executable.
+
+:::
+
+## Push the Platform Form
+
+```
+holos push platform form .
+```
+
+## Fill in the form
+
+TODO
+
+## Pull the Platform Model
+
+Once the platform model is saved, pull it into the holos-infra repository:
+
+```
+holos pull platform model .
+```
+
+## Render the Platform
+
+With the platform model and the platform spec, you're ready to render the complete platform configuration:
+
+```
+holos render platform ./platform
+```
+
+## Summary

doc/md/archive/guides/try-holos/index.mdx

@@ -0,0 +1,687 @@
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+import Admonition from '@theme/Admonition';
+
+# Try Holos Locally
+
+This guide walks through the process of building and managing a software
+development platform with Holos.  The k3d platform built in this guide is a
+slimmed down version of the larger, more holistic, Holos reference platform.
+
+Holos is different from existing tools in a few important ways.
+
+ 1. Holos provides a **unified configuration model** purpose built to improve on
+ unmodified Helm charts, Kustomize bases, or anything else that produces
+ structured configuration data.
+ 2. Holos all but **eliminates the need to template yaml**, a common source of
+ frustration and errors in production.
+ 3. Holos platforms are **composable** and have breadth.  The toolchain and
+ techniques scale down to one machine and up to multiple clusters across
+ multiple regions.
+ 4. The unified configuration model is well suited to a **Zero Trust security
+ model**.  Platform wide policy configuration is easier to manage with Holos.
+
+---
+
+This guide assumes commands are run locally.  Capitalized terms have specific
+definitions described in the [Glossary](/docs/glossary).
+
+## What you'll need {#Requirements}
+
+You'll need the following tools installed to complete this guide.
+
+1. [holos](/docs/install) - to build the platform.
+2. [helm](https://helm.sh/docs/intro/install/) - to render Holos components that wrap upstream Helm charts.
+3. [k3d](https://k3d.io/#installation) - to provide a k8s api server.
+4. [OrbStack](https://docs.orbstack.dev/install) or [Docker](https://docs.docker.com/get-docker/) - to use k3d.
+5. [kubectl](https://kubernetes.io/docs/tasks/tools/) - to interact with the k8s api server.
+6. [mkcert](https://github.com/FiloSottile/mkcert?tab=readme-ov-file#installation) - to make trusted TLS certificates.
+7. [jq](https://jqlang.github.io/jq/download/) - to fiddle with JSON output.
+
+:::note
+
+Registering an account **is recommended** to try out proper authentication and
+authorization in Holos, but you can complete this guide without signing up.
+
+:::
+
+## Goal {#Goal}
+
+By the end of this guide you'll have built the foundation of a software
+development platform.  The foundation provides Zero Trust security by
+holistically integrating off-the-shelf open source software.
+
+  1. Istio is configured to authenticate and authorize requests using an OIDC
+  ID-Token issued by ZITADEL before requests reach backend services.
+  2. The platform provides single sign-on and role based access control for all
+  services running on the platform.
+
+This guide strives to keep things neat and tidy.  All of the resources are
+located in one k3d cluster and one local Git repository.  If you want to clean
+up at any point, do so with:
+
+```bash
+k3d cluster delete workload
+rm -rf holos-k3d
+```
+
+## Sign In or Out {#Sign-In}
+
+Holos provides integrated authentication and authorization which we'll use in
+this guide to protect a service.  We recommend registering an account to see
+this in action.  Registration also enables you to explore the customizable web
+form that simplifies complex configuration.
+
+If you opt-out, the platform will be configured to use a fake identity in place
+of real id tokens.
+
+<Tabs groupId="registration">
+  <TabItem value="registered" label="Sign In">
+    ```bash
+    holos register user
+    ```
+  </TabItem>
+  <TabItem value="unregistered" label="Opt Out">
+    ```bash
+    holos logout
+    ```
+  </TabItem>
+</Tabs>
+
+## Create the Platform {#Create-Platform}
+
+A server-side platform resource in Holos stores the web form used to simplify
+platform wide configuration.
+
+First, initialize an empty Git repository:
+
+```bash
+mkdir holos-k3d
+cd holos-k3d
+git init
+```
+
+<Tabs groupId="registration">
+  <TabItem value="registered" label="Signed In">
+    Use `holos` to make the rpc call to create the server-side platform
+    resource.
+
+    ```bash
+    holos create platform --name k3d --display-name "Try Holos Locally"
+    ```
+  </TabItem>
+  <TabItem value="unregistered" label="Signed Out">
+    Create a blank `platform.metadata.json` file so subsequent holos commands
+    skip rpc calls.
+
+    ```bash
+    touch platform.metadata.json
+    ```
+  </TabItem>
+</Tabs>
+
+### Generate the Platform {#Generate-Platform}
+
+Generate the platform code in the repository root.
+
+```bash
+holos generate platform k3d
+```
+
+Commit the generated platform config to the repository.
+
+```bash
+git add .
+git commit -m "holos generate platform k3d - $(holos --version)"
+```
+
+### Push the Platform Form
+
+Each Holos platform has a Platform Form used to submit top level, platform-wide
+configuration values.  The purpose of the form is to validate configuration
+values and simplify complicated configurations and integrations.
+
+<Tabs groupId="registration">
+  <TabItem value="registered" label="Signed In">
+    Push the Platform Form to publish it.  Browse to the printed URL to view the
+    form.
+
+    ```bash
+    holos push platform form .
+    ```
+  </TabItem>
+  <TabItem value="unregistered" label="Signed Out">
+    You will update the Platform Model locally in a later step so there's
+    nothing to do in this step.  Only signed-in users can push a Platform Form
+    to the Holos web server.
+
+    ```bash
+    # holos push platform form .
+    ```
+  </TabItem>
+</Tabs>
+
+The Platform Form is defined locally in `forms/platform/platform-form.cue`.
+
+On the web it looks like:
+![Platform Form Default Values](./form-pushed.png)
+
+### Update the Platform Model {#Platform-Model}
+
+Holos needs initial, top level configuration values to render the platform.  The
+Platform Model is the term we use for these values.  In this section you will
+configure role based access control by way of updating the Platform Model.
+
+In the k3d platform you're building now, role based access control is
+implemented by asserting against the oidc id token subject.  Update the form
+with the `sub` claim value from your id token.  This will ensure only you have
+access to platform services.
+
+<Tabs groupId="registration">
+  <TabItem value="registered" label="Signed In">
+    Copy and paste the `sub` value into your Platform Form's Subject field.
+
+    ```bash
+    holos login --print-claims --log-level=error | jq -r .sub
+    ```
+
+    After pasting the `sub` value, click Submit on the form.
+  </TabItem>
+  <TabItem value="unregistered" label="Signed Out">
+    You don't have an id token when you're signed out, so there's nothing for
+    you to do in this step.
+
+    ```bash
+    # holos login --print-claims --log-level=error | jq -r .sub
+    ```
+
+    The platform will be configured to assert against the User-Agent header
+    instead.
+  </TabItem>
+</Tabs>
+
+### Pull the Platform Model {#Pull-the-Platform-Model}
+
+The Platform Model needs to be pulled into the local Git repository after the
+form has been submitted. Next, we'll run `holos render` which operates
+exclusively on local files.
+
+Holos stores the Platform Model in the `platform.config.json` file. Holos
+provides this file as input to CUE when rendering the platform.  This file is
+intended to be added to version control.
+
+<Tabs groupId="registration">
+  <TabItem value="registered" label="Signed In">
+    Pull the updated Platform Model into the local repository.
+
+    ```bash
+    holos pull platform model .
+    git add platform.config.json
+    git commit -m "Add platform model"
+    ```
+
+  </TabItem>
+  <TabItem value="unregistered" label="Signed Out">
+    The holos generate platform k3d command created an initial Platform Model in
+    `platform.config.json`.  As a result there's nothing to do in this step.
+
+    ```bash
+    # holos pull platform model .
+    # git add platform.config.json
+    # git commit -m "Add platform model"
+    ```
+  </TabItem>
+</Tabs>
+
+## Render the Platform {#Render-the-Platform}
+
+Holos has everything necessary to render the platform once the
+`platform.config.json` file and the code from `holos generate` are in the
+current directory.
+
+Rendering a platform is the process of iterating over each platform component
+and rendering it into plain yaml. Holos does not apply the resulting manifests.
+Other tools like kubectl, ArgoCD, or Flux are responsible for applying the
+manifests.
+
+```bash
+holos render platform ./platform
+```
+
+The render command writes the manifest files to the `deploy/` directory.  Commit
+the files so they can be applied via GitOps later.
+
+```bash
+git add deploy
+git commit -m "holos render platform ./platform"
+```
+
+:::info[Don't blink, this is where Holos builds the platform]
+
+It usually takes no more than a few seconds.
+
+Rendering the holos reference platform currently results in about 500K lines of
+yaml.  In contrast, roughly 80K lines are produced by this slimmed down k3d
+platform.
+
+We mention this because the scale doesn't matter as much as it does with other
+tools.  Manage millions of lines of configuration with Holos the same way this
+guide manages thousands.  This is made possible by the unique way CUE unifies
+all configuration into one single model.
+
+:::
+
+## Configure DNS {#DNS}
+
+Configure your machine to resolve `*.holos.localhost` to your loopback
+interface.  This is necessary for requests to reach the workload cluster.
+
+<Tabs>
+  <TabItem value="macos" label="macOS" default>
+  Cache sudo credentials.
+
+  Admin access is necessary to setup a local dnsmasq instance and configure
+  macOS's DNS resolver.
+
+  ```bash
+  sudo -v
+  ```
+
+  Resolve *.holos.localhost DNS queries to 127.0.0.1.
+
+  ```bash
+  bash ./scripts/local-dns
+  ```
+
+  </TabItem>
+  <TabItem value="linux" label="Linux">
+    [NSS-myhostname](http://man7.org/linux/man-pages/man8/nss-myhostname.8.html)
+    ships with many Linux distributions and should resolve *.localhost
+    automatically to 127.0.0.1.
+
+    Otherwise it is installable with:
+
+    ```bash
+    sudo apt install libnss-myhostname
+    ```
+  </TabItem>
+  <TabItem value="windows" label="Windows">
+    Ensure the loopback interface has at least the following names in `C:\windows\system32\drivers\etc\hosts`
+
+    ```
+    127.0.0.1 httpbin.holos.localhost app.holos.localhost
+    ```
+  </TabItem>
+</Tabs>
+
+
+## Create the Cluster {#Create-Cluster}
+
+The Workload Cluster is where your applications and services will be deployed.
+In production this is usually an EKS, GKE, or AKS cluster.
+
+:::tip
+
+Holos supports all compliant Kubernetes clusters. Holos was developed and tested
+on GKE, EKS, Talos, k3s, and Kubeadm clusters.
+
+:::
+
+<Tabs>
+  <TabItem value="evaluate" label="Try Holos" default>
+  Use this command when exploring Holos.
+
+  ```bash
+  k3d cluster create workload \
+    --port "443:443@loadbalancer" \
+    --k3s-arg "--disable=traefik@server:0"
+  ```
+
+  </TabItem>
+  <TabItem value="develop" label="Develop Holos">
+  Use this command when developing Holos.
+
+  ```bash
+  k3d registry create registry.holos.localhost --port 5100
+  ```
+
+  ```bash
+  k3d cluster create workload \
+    --registry-use k3d-registry.holos.localhost:5100 \
+    --port "443:443@loadbalancer" \
+    --k3s-arg "--disable=traefik@server:0"
+  ```
+
+  </TabItem>
+</Tabs>
+
+Traefik is disabled because Istio provides the same functionality.
+
+## Apply the Platform Components {#Apply-Platform-Components}
+
+Use `kubectl` to apply each platform component.  In production, it's common to
+fully automate this process with ArgoCD, but we use `kubectl` to the same
+effect.
+
+### Local CA {#Local-CA}
+
+Holos platforms use cert manager to issue tls certificates.  The browser and
+tools we're using need to trust these certificates to work together.
+
+Admin access is necessary for `mkcert` to manage the certificate into your trust
+stores.
+
+```bash
+sudo -v
+```
+
+Manage the local CA and copy the CA key to the workload cluster so that cert
+manager can manage trusted certificates.
+
+```bash
+bash ./scripts/local-ca
+```
+
+:::warning
+
+Take care to run the local-ca script each time you create the workload cluster
+so that Certificates are issued correctly.
+
+:::
+
+
+### Service Mesh
+
+The platform service mesh provides an ingress gateway and connectivity useful
+for observability, reliability, and security.
+
+#### Namespaces
+
+With Holos, components are automatically added to the namespaces component,
+useful for centrally managed policies.
+
+```bash
+kubectl apply --server-side=true -f ./deploy/clusters/workload/components/namespaces
+```
+
+#### Custom Resource Definitions
+
+```bash
+kubectl apply --server-side=true -f ./deploy/clusters/workload/components/gateway-api
+kubectl apply --server-side=true -f ./deploy/clusters/workload/components/istio-base
+```
+
+#### Cert Manager {#cert-manager}
+
+Apply the cert-manager controller.
+
+```bash
+kubectl apply --server-side=true -f ./deploy/clusters/workload/components/cert-manager
+```
+
+Apply the ClusterIssuer which issues Certificate resources using the local
+certificate authority.
+
+```bash
+kubectl -n cert-manager wait pod -l app.kubernetes.io/component=webhook --for=condition=Ready
+kubectl apply --server-side=true -f deploy/clusters/workload/components/local-ca
+kubectl apply --server-side=true -f deploy/clusters/workload/components/certificates
+kubectl -n istio-gateways wait certificate httpbin.holos.localhost --for=condition=Ready
+```
+
+:::warning
+
+The certificate will time out before becoming ready if the [local-ca](#Local-CA)
+script was not run after the cluster was created.
+
+:::
+
+#### Istio {#Istio}
+
+Istio implements the Service Mesh.
+
+```bash
+kubectl apply --server-side=true -f ./deploy/clusters/workload/components/istio-cni
+kubectl apply --server-side=true -f ./deploy/clusters/workload/components/istiod
+kubectl apply --server-side=true -f ./deploy/clusters/workload/components/gateway
+```
+
+Verify the Gateway is programmed and the listeners have been accepted:
+
+```bash
+kubectl -n istio-gateways wait gateway default --for=condition=Accepted
+```
+
+#### httpbin {#httpbin}
+
+httpbin is a simple backend service useful for end-to-end testing.
+
+```bash
+kubectl apply --server-side=true -f deploy/clusters/workload/components/httpbin-backend
+kubectl apply --server-side=true -f deploy/clusters/workload/components/httpbin-routes
+kubectl -n holos-system wait pod -l app.kubernetes.io/instance=httpbin --for=condition=Ready
+```
+
+:::info
+
+Browse to [https://httpbin.holos.localhost/](https://httpbin.holos.localhost/)
+to verify end to end connectivity.  You should see the httpbin index page.
+
+:::
+
+### Authenticating Proxy
+
+The auth proxy is responsible for authenticating browser requests, handling the
+oidc authentication flow, and providing a signed id token to the rest of the
+services in the mesh.
+
+#### Cookie Secret
+
+The auth proxy stores session information in an encrypted cookie.  Generate a
+random cookie encryption Secret and apply.
+
+```bash
+LC_ALL=C tr -dc A-Za-z0-9 </dev/urandom \
+  | head -c 32 \
+  | kubectl create secret generic "authproxy" \
+    --from-file=cookiesecret=/dev/stdin \
+    --dry-run=client -o yaml \
+  | kubectl apply -n istio-gateways -f-
+```
+
+#### Deployment
+
+The auth proxy Deployment receives requests from web browsers and responds with
+an authentication decision.
+
+```bash
+kubectl apply --server-side=true -f deploy/clusters/workload/components/authproxy
+kubectl apply --server-side=true -f deploy/clusters/workload/components/authroutes
+```
+
+<Tabs groupId="registration">
+  <TabItem value="registered" label="Signed In">
+    <Admonition type="info">
+    Verify authentication is working by browsing to
+    [https://httpbin.holos.localhost/holos/authproxy](https://httpbin.holos.localhost/holos/authproxy).
+
+    We want a simple `Authenticated` response.
+
+      <Admonition type="tip">
+      You may need to refresh the page a few times while the platform configures
+      itself.
+      </Admonition>
+    </Admonition>
+
+    Istio will respond with `no healthy upstream` until the pod becomes ready.
+    Wait for the pod to become ready with:
+
+    ```bash
+    kubectl -n holos-system wait pod -l app.kubernetes.io/instance=httpbin --for=condition=Ready
+    ```
+
+    Once authenticated, visit
+    [https://httpbin.holos.localhost/holos/authproxy/userinfo](https://httpbin.holos.localhost/holos/authproxy/userinfo)
+    which returns a subset of claims from your id token.
+
+    <Admonition type="warning">
+      If you get `Unauthorized` instead of a json response body, make sure you
+      [authenticated](https://httpbin.holos.localhost/holos/authproxy) first.
+    </Admonition>
+
+    ```json
+    {
+      "user": "275552236589843464",
+      "email": "demo@holos.run",
+      "preferredUsername": "demo"
+    }
+    ```
+  </TabItem>
+  <TabItem value="unregistered" label="Signed Out">
+    The auth proxy will always try to sign you in when you are signed out, so
+    there isn't much to do here.  Please do take a moment to glance at the
+    Signed In tab to see how this would work if you were signed in.
+
+    The `k3d` platform relies on `https://login.holos.run` to issue id tokens.
+    Authorization has been configured against fake request headers instead of
+    the real `x-oidc-id-token` header.
+  </TabItem>
+</Tabs>
+
+### Authorization Policy
+
+Configure authorization policies using attributes of the authenticated request.
+Authorization policies route web requests through the auth proxy and then
+validate all requests against the `x-oidc-id-token` header.
+
+```bash
+kubectl apply --server-side=true -f deploy/clusters/workload/components/authpolicy
+```
+
+Istio make take a few seconds to program the Gateway with the
+AuthorizationPolicy resources.
+
+## Try out Zero Trust
+
+A basic Zero Trust security model is now in place.  The platform authenticates
+and authorizes requests before they reach the backend service.
+
+### Browser
+
+<Tabs groupId="registration">
+  <TabItem value="registered" label="Signed In">
+    The platform has been configured to authorize requests with a `x-oidc-id-token` header.
+
+    1. Verify authentication is working by browsing to [https://httpbin.holos.localhost/dump/request](https://httpbin.holos.localhost/dump/request).
+        - Refresh the page a few times.
+        - The `httpbin` backend pods should echo back the `x-oidc-id-token`
+        header injected by the auth proxy.
+    2. Note the `x-oidc-id-token` header is not sent by your browser but is
+    received by the backend service.
+        - This design reduces the risk of exposing id tokens in the browser.
+        - Browser request size remains constant as more claims are added to id
+        tokens.
+        - Reliability improves because id tokens often overflow request header
+        buffers when they pass through middle boxes across the internet.
+  </TabItem>
+  <TabItem value="unregistered" label="Signed Out">
+    The platform has been configured to authorize requests with a `User-Agent: anonymous` header.
+
+    1. Open an incognito window (Cmd+Shift+N) to verify the platform is
+    enforcing the authorization policy.
+    2. Browse to
+    [https://httpbin.holos.localhost/dump/request](https://httpbin.holos.localhost/dump/request)
+    you should be redirected to the sign in page by the auth proxy.
+        - You **do not** need to register or sign in.
+        - This step verifies the platform is redirecting unauthenticated
+        requests to the identity provider.
+        - Navigate back or close and re-open an incognito window.
+    3. Set your `User-Agent` header to `anonymous` using your browser developer tools.
+        - For Chrome the process is described
+        [here](https://developer.chrome.com/docs/devtools/device-mode/override-user-agent#override_the_user_agent_string).
+        - The purpose is to simulate an authenticated request.
+    4. Browse to
+    [https://httpbin.holos.localhost/dump/request](https://httpbin.holos.localhost/dump/request).
+        - The platform should allow the request through to the backend pod.
+        - `httpbin` should echo back your request which should contain `User-Agent: anonymous`.
+  </TabItem>
+</Tabs>
+
+### Command Line
+
+Verify unauthenticated requests are blocked by default outside the browser.
+
+```bash
+curl -I https://httpbin.holos.localhost/dump/request
+```
+
+You should receive a `HTTP/2 302` response that redirects to `location:
+https://login.holos.run` to start the oauth login flow.
+
+Next, verify authenticated requests are allowed.
+
+<Tabs groupId="registration">
+  <TabItem value="registered" label="Signed In">
+    The platform is configured to authenticate the id token present in the
+    `x-oidc-id-token` header.
+
+    💡 It also works with `grpcurl`.
+
+    ```bash
+    curl -H x-oidc-id-token:$(holos token) https://httpbin.holos.localhost/dump/request
+    ```
+  </TabItem>
+  <TabItem value="unregistered" label="Signed Out">
+    The platform is configured to authorize any request with `User-Agent:
+    anonymous` in place of validating the oidc id token.
+
+    💡 Take a moment to click the Signed In tab, I don't want you to miss how
+    cool `$(holos token)` is.
+
+    ```bash
+    curl -A anonymous https://httpbin.holos.localhost/dump/request
+    ```
+  </TabItem>
+</Tabs>
+
+You should receive a response showing the request headers the backend received.
+
+:::tip
+
+Note how the platform secures both web browser and command line api access to
+the backend httpbin service.  httpbin itself has no authentication or
+authorization functionality.
+
+:::
+
+## Summary
+
+Thank you for taking the time to try out Holos.  In this guide, you built the
+foundation of a software development platform that:
+
+ 1. Provides a unified configuration model with CUE that
+    - Supports unmodified Helm Charts, Kustomize Kustomizations, plain YAML.
+    - Provides a web form to pass top level parameters.
+ 2. Reduces errors by eliminating the need to template unstructured text.
+ 3. Is composable and scales down to a local machine.
+ 4. Provides an way to safely configure broad authentication and authorization
+ policy.
+
+## Next Steps
+
+Dive deeper with the following resources that build on the foundation you have now.
+
+ 1. Explore the [Rendering Process](/docs/concepts#rendering) in Holos.
+ 2. Dive deeper into the [Platform Manifests](./platform-manifests) rendered in this guide.
+ 3. Deploy [ArgoCD](../argocd) onto the foundation you built.
+ 4. Deploy [Backstage](../backstage) as a portal to the integrated platform components.
+
+## Clean-Up
+
+If you'd like to clean up the resources you created in this guide, remove them
+with:
+
+```bash
+k3d cluster delete workload
+rm -rf holos-k3d
+```

doc/md/archive/guides/try-holos/platform-manifests.md

@@ -0,0 +1,137 @@
+# Platform Manifests
+
+This document provides an example of how Holos uses CUE and Helm to unify and
+render the platform configuration.  It refers to the manifests rendered in the
+Try Holos Locally guide.
+
+Take a moment to review the manifests `holos` rendered to build the platform.
+
+### ArgoCD Application
+
+Note the Git URL in the Platform Model is used to derive the ArgoCD
+`Application` resource for all of the platform components.
+
+```yaml
+# deploy/clusters/workload/gitops/namespaces.application.gen.yaml
+apiVersion: argoproj.io/v1alpha1
+kind: Application
+metadata:
+  name: namespaces
+  namespace: argocd
+spec:
+  destination:
+    server: https://kubernetes.default.svc
+  project: default
+  source:
+    # highlight-next-line
+    path: /deploy/clusters/workload/components/namespaces
+    # highlight-next-line
+    repoURL: https://github.com/holos-run/holos-k3d.git
+    # highlight-next-line
+    targetRevision: HEAD
+```
+
+One ArgoCD `Application` resource is produced for each Holos component by
+default.  The CUE definition which produces the rendered output is defined in
+`buildplan.cue` around line 222.
+
+:::tip
+
+Note how CUE does not use error-prone text templates, the language is well
+specified and typed which reduces errors when unifying the configuration with
+the Platform Model in the following `#Argo` definition.
+
+:::
+
+```cue
+// buildplan.cue
+
+// #Argo represents an argocd Application resource for each component, written
+// using the #HolosComponent.deployFiles field.
+#Argo: {
+	ComponentName: string
+
+	Application: app.#Application & {
+		metadata: name:      ComponentName
+		metadata: namespace: "argocd"
+		spec: {
+			destination: server: "https://kubernetes.default.svc"
+			project: "default"
+			source: {
+        // highlight-next-line
+				path:           "\(_Platform.Model.argocd.deployRoot)/deploy/clusters/\(_ClusterName)/components/\(ComponentName)"
+        // highlight-next-line
+				repoURL:        _Platform.Model.argocd.repoURL
+        // highlight-next-line
+				targetRevision: _Platform.Model.argocd.targetRevision
+			}
+		}
+	}
+
+	// deployFiles represents the output files to write along side the component.
+	deployFiles: "clusters/\(_ClusterName)/gitops/\(ComponentName).application.gen.yaml": yaml.Marshal(Application)
+}
+```
+
+### Helm Chart
+
+The `cert-manger` component renders using the upstream Helm chart.  The build
+plan that defines the helm chart to use along with the values to provide looks
+like the following.
+
+:::tip
+
+Holos fully supports your existing Helm charts.  Consider leveraging `holos` as
+an alternative to umbrella charts.
+
+:::
+
+```cue
+// components/cert-manager/cert-manager.cue
+package holos
+
+// Produce a helm chart build plan.
+(#Helm & Chart).Output
+
+let Chart = {
+	Name:      "cert-manager"
+	Version:   "1.14.5"
+	Namespace: "cert-manager"
+
+	Repo: name: "jetstack"
+	Repo: url:  "https://charts.jetstack.io"
+
+  // highlight-next-line
+	Values: {
+		installCRDs: true
+		startupapicheck: enabled: false
+		// Must not use kube-system on gke autopilot.  GKE Warden blocks access.
+    // highlight-next-line
+		global: leaderElection: namespace: Namespace
+
+		// https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-resource-requests#min-max-requests
+		resources: requests: {
+			cpu:                 "250m"
+			memory:              "512Mi"
+			"ephemeral-storage": "100Mi"
+		}
+    // highlight-next-line
+		webhook: resources:        Values.resources
+    // highlight-next-line
+		cainjector: resources:     Values.resources
+    // highlight-next-line
+		startupapicheck: resource: Values.resources
+
+		// https://cloud.google.com/kubernetes-engine/docs/how-to/autopilot-spot-pods
+		nodeSelector: {
+			"kubernetes.io/os": "linux"
+			if _ClusterName == "management" {
+				"cloud.google.com/gke-spot": "true"
+			}
+		}
+		webhook: nodeSelector:         Values.nodeSelector
+		cainjector: nodeSelector:      Values.nodeSelector
+		startupapicheck: nodeSelector: Values.nodeSelector
+	}
+}
+```

doc/md/archive/local-development.md

@@ -0,0 +1,28 @@
+# Local Development
+
+This document captures notes on locally developing Holos.
+
+Follow the steps in [Try Holos Locally](../guides/try-holos), but take care
+to select `Develop` tabs when creating the k3d cluster so you have a local
+registry to push to.
+
+## Apply Resources
+
+Work will be done in the `dev-holos` namespace.
+
+Apply the infrastructure, which should persist when tilt is started / stopped.
+
+```bash
+kubectl apply --server-side=true -f ./hack/tilt/k8s/dev-holos-infra
+```
+
+This creates the PostgresCluster, service account, etc...
+
+## Start tilt
+
+Tilt will build the go executable, build the container, then push it to the
+local repository associated with k3d.
+
+```bash
+./hack/tilt/bin/tilt up
+```

doc/md/backstory.md

@@ -0,0 +1,3 @@
+# Backstory
+
+Holos is a tool intended to lighten the burden of managing Kubernetes resources.  In 2020 we set out to develop a holistic platform composed from open source cloud native components.  We quickly became frustrated with how each of the major components packaged and distributed their software in a different way.  Many projects choose to distribute their software with Helm charts, while others provide plain yaml files and Kustomize bases.  The popular Kube Prometheus Stack project provides Jsonnet to render and update Kubernetes yaml manifests.

doc/md/cli.md

@@ -0,0 +1,3 @@
+# CLI
+
+Use the `holos` command line interface (CLI) to render individual platform components, entire platforms, and push/pull the platform model.

doc/md/glossary.md

@@ -0,0 +1,88 @@
+# Glossary
+
+This page describes the terms used within the context of Holos.
+
+## Platform
+
+In Holos, a Platform is a comprehensive environment configured using the
+Kubernetes resource model. It extends beyond traditional Kubernetes
+functionality by integrating cloud resources through Crossplane, allowing for a
+unified management approach across both Kubernetes and cloud infrastructure. A
+Platform typically consists of one Management Cluster, which handles control and
+secret management, and one or more Workload Clusters, where application
+workloads are deployed and run. This architecture enables a consistent and
+scalable approach to managing diverse resources and services within the
+cloud-native ecosystem.
+
+## Management Cluster
+
+In the context of Holos, a Management Cluster is a special Kubernetes cluster
+that hosts Kubernetes controllers.  For example, cert-manager, Cluster api, and
+Crossplane.  A management cluster manages a single platform.  The primary
+function of this cluster is to securely store and manage secrets, ensuring the
+secure handling of sensitive information such as credentials, API keys, and
+other confidential data. The Management Cluster serves as a centralized and
+secure control plane for the platform, facilitating the orchestration and
+management of other components.
+
+## Workload Cluster
+
+In Holos, a Workload Cluster is a Kubernetes cluster designed to host and run
+application workloads. Unlike the Management Cluster, which focuses on control
+and secret management, Workload Clusters are dedicated to executing the actual
+applications and services. These clusters can vary in size and configuration
+based on the specific needs of the applications they support. Workload Clusters
+leverage Kubernetes' orchestration capabilities to manage the deployment,
+scaling, and operation of containerized applications, providing a flexible and
+scalable environment for running production workloads within the platform.
+
+## Platform Form
+
+In Holos, a Platform Form is a customizable web form defined by JSON data. Each
+platform within Holos has a unique Platform Form, which serves as an interface
+for configuring and managing the platform's settings and resources. Platform
+engineers can customize the Platform Form by modifying the underlying CUE
+(Configuration Unified Engine) code, allowing for tailored configurations that
+meet specific requirements. This flexibility enables platform engineers to
+create a user-friendly and specific interface for managing the platform's
+components and operations.
+
+## Platform Model
+
+In Holos, the Platform Model represents the collection of values submitted
+through the Platform Form. It encapsulates the specific configuration details
+and settings defined by the platform engineers, serving as the blueprint for the
+platform's setup and operation. The Platform Model is essential for translating
+the customized options and parameters from the Platform Form into actionable
+configurations within the Holos ecosystem, ensuring that the platform operates
+according to the specified requirements and guidelines.
+
+## Secret Store
+
+In Holos, a SecretStore is a repository for securely storing and managing
+sensitive data such as passwords, API keys, and other confidential information.
+It is compatible with any secret store supported by the External Secrets
+Operator. By default, the management cluster serves as the SecretStore to
+minimize dependencies and simplify the architecture. This setup ensures that
+secrets are managed in a secure and centralized manner, aligning with the
+overall security framework of the platform.
+
+## Service Mesh
+
+In Holos, a Service Mesh is a dedicated infrastructure layer for managing,
+observing, and securing service-to-service communications within a microservices
+architecture. It typically includes features such as load balancing, traffic
+routing, service discovery, and security policies like mutual TLS and access
+control. The Service Mesh abstracts these functionalities away from the
+application code, providing a centralized control plane for managing the
+interactions between microservices. This facilitates better observability,
+resilience, and security in complex, distributed environments.
+
+## Zero Trust
+
+In the context of Holos and broader security practices, Zero Trust is a security
+model that assumes no implicit trust is granted to any user, system, or
+component inside or outside the network. Instead, every request for access is
+treated as potentially malicious, and verification is required at every stage.
+This model enforces strict identity verification, continuous monitoring, and
+least-privilege access policies.

doc/md/guides.md

@@ -0,0 +1,24 @@
+import DocCardList from '@theme/DocCardList';
+
+# Guides
+
+## Start with the [Quickstart] guide
+
+The guides are organized as a progression.  We'll use Holos to manage a
+fictional bank's platform, the Bank of Holos in each of the guides.  In doing so
+we'll take the time to explain the foundational concepts of Holos.
+
+1. [Quickstart] covers the foundational concepts of Holos.
+2. [Deploy a Service] explains how to deploy a containerized service using an
+existing Helm chart.  This guide then explains how to deploy a similar service
+safely and consistently with CUE instead of Helm.
+3. [Change a Service] covers the day two task of making configuration changes to
+deployed services safely and consistently.
+
+---
+
+<DocCardList />
+
+[Quickstart]: /docs/quickstart/
+[Deploy a Service]: /docs/guides/deploy-a-service/
+[Change a Service]: /docs/guides/change-a-service/

doc/md/guides/change-a-service.mdx

@@ -0,0 +1,11 @@
+---
+description: Change a service on your platform.
+slug: /guides/change-a-service
+sidebar_position: 300
+---
+
+# Change a Service
+
+:::warning
+Under construction.
+:::

doc/md/guides/deploy-a-service.mdx

@@ -0,0 +1,11 @@
+---
+description: Deploy a service on your platform.
+slug: /guides/deploy-a-service
+sidebar_position: 200
+---
+
+# Deploy a Service
+
+:::warning
+Under construction.
+:::

doc/md/guides/local-cluster.mdx

@@ -0,0 +1,277 @@
+---
+description: Build a local Cluster to use with these guides.
+slug: /guides/local-cluster
+sidebar_position: 999
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+import Admonition from '@theme/Admonition';
+
+# Local Cluster
+
+In this guide we'll set up a local k3d cluster to apply and explore the
+configuration described in our other guides.  After completing this guide you'll
+have a standard Kubernetes API server with proper DNS and TLS certificates.
+You'll be able to easily reset the cluster to a known good state to iterate on
+your own Platform.
+
+The [Concepts](/docs/concepts) page defines capitalized terms such as Platform
+and Component.
+
+## Reset the Cluster
+
+If you've already followed this guide, reset the cluster by running the
+following commands.  Skip this section if you're creating a cluster for the
+first time.
+
+First, delete the cluster.
+
+<Tabs groupId="k3d-cluster-delete">
+  <TabItem value="command" label="Command">
+```bash
+k3d cluster delete workload
+```
+  </TabItem>
+  <TabItem value="output" label="Output">
+```txt showLineNumbers
+INFO[0000] Deleting cluster 'workload'
+INFO[0000] Deleting cluster network 'k3d-workload'
+INFO[0000] Deleting 1 attached volumes...
+INFO[0000] Removing cluster details from default kubeconfig...
+INFO[0000] Removing standalone kubeconfig file (if there is one)...
+INFO[0000] Successfully deleted cluster workload!
+```
+  </TabItem>
+</Tabs>
+
+Then create the cluster again.
+
+<Tabs groupId="k3d-cluster-create">
+  <TabItem value="command" label="Command">
+```bash
+k3d cluster create workload \
+  --registry-use k3d-registry.holos.localhost:5100 \
+  --port "443:443@loadbalancer" \
+  --k3s-arg "--disable=traefik@server:0"
+```
+  </TabItem>
+  <TabItem value="output" label="Output">
+```txt showLineNumbers
+INFO[0000] portmapping '443:443' targets the loadbalancer: defaulting to [servers:*:proxy agents:*:proxy]
+INFO[0000] Prep: Network
+INFO[0000] Created network 'k3d-workload'
+INFO[0000] Created image volume k3d-workload-images
+INFO[0000] Starting new tools node...
+INFO[0000] Starting node 'k3d-workload-tools'
+INFO[0001] Creating node 'k3d-workload-server-0'
+INFO[0001] Creating LoadBalancer 'k3d-workload-serverlb'
+INFO[0001] Using the k3d-tools node to gather environment information
+INFO[0001] HostIP: using network gateway 172.17.0.1 address
+INFO[0001] Starting cluster 'workload'
+INFO[0001] Starting servers...
+INFO[0001] Starting node 'k3d-workload-server-0'
+INFO[0003] All agents already running.
+INFO[0003] Starting helpers...
+INFO[0003] Starting node 'k3d-workload-serverlb'
+INFO[0009] Injecting records for hostAliases (incl. host.k3d.internal) and for 3 network members into CoreDNS configmap...
+INFO[0012] Cluster 'workload' created successfully!
+INFO[0012] You can now use it like this:
+kubectl cluster-info
+```
+  </TabItem>
+</Tabs>
+
+Finally, add your trusted certificate authority.
+
+<Tabs groupId="apply-local-ca">
+  <TabItem value="command" label="Command">
+```bash
+kubectl apply --server-side=true -f "$(mkcert -CAROOT)/namespace.yaml"
+kubectl apply --server-side=true -n cert-manager -f "$(mkcert -CAROOT)/local-ca.yaml"
+```
+  </TabItem>
+  <TabItem value="output" label="Output">
+```txt showLineNumbers
+namespace/cert-manager serverside-applied
+secret/local-ca serverside-applied
+```
+  </TabItem>
+</Tabs>
+
+You're back to the same state as the first time you completed this guide.
+
+## What you'll need {#requirements}
+
+You'll need the following tools installed to complete this guide.
+
+1. [holos](/docs/install) - to build the platform.
+2. [helm](https://helm.sh/docs/intro/install/) - to render Holos components that wrap upstream Helm charts.
+3. [k3d](https://k3d.io/#installation) - to provide a k8s api server.
+4. [OrbStack](https://docs.orbstack.dev/install) or [Docker](https://docs.docker.com/get-docker/) - to use k3d.
+5. [kubectl](https://kubernetes.io/docs/tasks/tools/) - to interact with the k8s api server.
+6. [mkcert](https://github.com/FiloSottile/mkcert?tab=readme-ov-file#installation) - to make trusted TLS certificates.
+7. [jq](https://jqlang.github.io/jq/download/) - to fiddle with JSON output.
+
+## Configure DNS {#configure-dns}
+
+Configure your machine to resolve `*.holos.localhost` to your loopback
+interface.  This is necessary for requests to reach the workload cluster.  Save
+this script to a file and execute it.
+
+```bash showLineNumbers
+#! /bin/bash
+#
+
+set -euo pipefail
+
+tmpdir="$(mktemp -d)"
+finish() {
+  [[ -d "$tmpdir" ]] && rm -rf "$tmpdir"
+}
+trap finish EXIT
+cd "$tmpdir"
+
+brew install dnsmasq
+
+cat <<EOF >"$(brew --prefix)/etc/dnsmasq.d/holos.localhost.conf"
+# Refer to https://holos.run/docs/tutorial/local/k3d/
+address=/holos.localhost/127.0.0.1
+EOF
+
+if [[ -r /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist ]]; then
+  echo "dnsmasq already configured"
+else
+  sudo cp "$(brew list dnsmasq | grep 'dnsmasq.plist$')" \
+    /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist
+  sudo launchctl unload /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist
+  sudo launchctl load /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist
+  dscacheutil -flushcache
+  echo "dnsmasq configured"
+fi
+
+sudo mkdir -p /etc/resolver
+sudo tee /etc/resolver/holos.localhost <<EOF
+domain holos.localhost
+nameserver 127.0.0.1
+EOF
+sudo killall -HUP mDNSResponder
+
+echo "all done."
+```
+
+## Create the Cluster {#create-the-cluster}
+
+The Workload Cluster is where your applications and services will be deployed.
+In production this is usually an EKS, GKE, or AKS cluster.
+
+:::tip
+
+Holos supports all compliant Kubernetes clusters. Holos was developed and tested
+on GKE, EKS, Talos, k3s, and Kubeadm clusters.
+
+:::
+
+Create a local registry to speed up image builds and pulls.
+
+```bash
+k3d registry create registry.holos.localhost --port 5100
+```
+
+Create the workload cluster configured to use the local registry.
+
+```bash
+k3d cluster create workload \
+  --registry-use k3d-registry.holos.localhost:5100 \
+  --port "443:443@loadbalancer" \
+  --k3s-arg "--disable=traefik@server:0"
+```
+
+Traefik is disabled because Istio provides the same functionality.
+
+## Setup Root CA {#setup-root-ca}
+
+Platforms most often use cert-manager to issue tls certificates.  The browser
+and tools we're using need to trust these certificates to work together.
+Generate a local, trusted root certificate authority with the following script.
+
+Admin access is necessary for `mkcert` to manage the certificate into your trust
+stores.
+
+```bash
+sudo -v
+```
+
+Manage the local CA and copy the CA key to the workload cluster so that cert
+manager can manage trusted certificates.
+
+Save this script to a file and execute it to configure a trusted certificate
+authority.
+
+```bash showLineNumbers
+#! /bin/bash
+#
+
+set -euo pipefail
+
+mkcert --install
+
+tmpdir="$(mktemp -d)"
+finish() {
+  [[ -d "$tmpdir" ]] && rm -rf "$tmpdir"
+}
+trap finish EXIT
+cd "$tmpdir"
+
+# Create the local CA Secret with ca.crt, tls.crt, tls.key
+
+mkdir local-ca
+cd local-ca
+CAROOT="$(mkcert -CAROOT)"
+cp -p "${CAROOT}/rootCA.pem" ca.crt
+cp -p "${CAROOT}/rootCA.pem" tls.crt
+cp -p "${CAROOT}/rootCA-key.pem" tls.key
+kubectl create secret generic --from-file=.  --dry-run=client -o yaml local-ca > ../local-ca.yaml
+echo 'type: kubernetes.io/tls' >> ../local-ca.yaml
+
+cd ..
+
+cat <<EOF > namespace.yaml
+apiVersion: v1
+kind: Namespace
+metadata:
+  labels:
+    kubernetes.io/metadata.name: cert-manager
+  name: cert-manager
+spec:
+  finalizers:
+  - kubernetes
+EOF
+kubectl apply --server-side=true -f namespace.yaml
+kubectl apply -n cert-manager --server-side=true -f local-ca.yaml
+
+# Save the Secret to easily reset the cluster later.
+install -m 0644 namespace.yaml "${CAROOT}/namespace.yaml"
+install -m 0600 local-ca.yaml "${CAROOT}/local-ca.yaml"
+```
+
+:::warning
+
+Take care to run the local-ca script each time you create the workload cluster
+so that Certificates are issued correctly.
+
+:::
+
+## Clean Up {#clean-up}
+
+If you'd like to clean up the resources you created in this guide, remove them
+with:
+
+```bash
+k3d cluster delete workload
+```
+
+## Next Steps
+
+Now that you have a real cluster, apply and explore the manifests Holos renders
+in the [Quickstart](/docs/quickstart) guide.

doc/md/guides/quickstart.mdx

@@ -0,0 +1,765 @@
+---
+description: Try Holos with this quick start guide.
+slug: /quickstart
+sidebar_position: 100
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+import Admonition from '@theme/Admonition';
+
+# Quickstart
+
+Welcome to the Holos Quickstart guide.  Holos is an open source tool to manage
+software development platforms safely, easily, and consistently.  We'll use
+Holos to manage a fictional bank's platform, the Bank of Holos.  In doing so
+we'll take the time to explain the foundational concepts of Holos.
+
+ 1. **Platform** - Holos breaks a Platform down into Components owned by teams.
+ 2. **Component** - Components are CUE wrappers around unmodified upstream
+ vendor Helm Charts, Kustomize Bases, or plain Kubernetes manifests.
+ 3. **CUE** - We write CUE to configure the platform.  We'll cover the basics of
+ CUE syntax and why Holos uses CUE.
+ 4. **Tree Unification** - CUE files are organized into a unified filesystem
+ tree.  We'll cover how unification makes it easier and safer for multiple teams
+ to change the platform.
+
+The Bank of Holos provides a good example of how Holos is designed to make it
+easier for multiple teams to deliver services on a platform.  These teams are:
+
+- **Platform**
+- **Software development**
+- **Security**
+- **Quality Assurance**
+
+Here's a screenshot of the retail banking application we'll build and deploy on
+our platform.  We'll keep each of these teams in mind as we work through the
+guides.  Each of our guides focuses on different aspects of delivering the Bank
+of Holos.
+
+![Bank of Holos](./img/bank-home.png)
+
+## What you'll need {#requirements}
+
+This guide is intended to be informative without needing to run the commands.
+If you'd like to render the platform and apply the manifests to a real Cluster,
+complete the [Local Cluster Guide](/docs/guides/local-cluster) before this
+guide.
+
+You'll need the following tools installed to run the commands in this guide.
+
+1. [holos](/docs/install) - to build the Platform.
+2. [helm](https://helm.sh/docs/intro/install/) - to render Holos Components that
+wrap Helm charts.
+3. [kubectl](https://kubernetes.io/docs/tasks/tools/) - to render Holos
+Components that render with Kustomize.
+
+## Install Holos
+
+Start by installing the `holos` command line tool with the following command.
+If you don't have Go, refer to [Installation](/docs/install/) to download the
+executable.
+
+<Tabs groupId="go-install">
+  <TabItem value="command" label="Command">
+```bash
+go install github.com/holos-run/holos/cmd/holos@latest
+```
+  </TabItem>
+  <TabItem value="output" label="Output">
+```txt
+go: downloading github.com/holos-run/holos v0.95.1
+```
+  </TabItem>
+</Tabs>
+
+:::tip
+Nearly all day-to-day platform management tasks use the `holos` command line
+tool to render plain Kubernetes manifests.
+:::
+
+## Fork the Git Repository
+
+Building a software development platform from scratch takes time so we've
+published an example for our guides.  [Fork the Bank of
+Holos](https://github.com/holos-run/bank-of-holos/fork) to get started.
+
+Clone the repository to your local machine.
+
+<Tabs groupId="git-clone">
+  <TabItem value="command" label="Command">
+```bash
+# Change YourName
+git clone https://github.com/YourName/bank-of-holos
+cd bank-of-holos
+```
+  </TabItem>
+  <TabItem value="output" label="Output">
+```txt
+Cloning into 'bank-of-holos'...
+remote: Enumerating objects: 1177, done.
+remote: Counting objects: 100% (1177/1177), done.
+remote: Compressing objects: 100% (558/558), done.
+remote: Total 1177 (delta 394), reused 1084 (delta 303), pack-reused 0 (from 0)
+Receiving objects: 100% (1177/1177), 2.89 MiB | 6.07 MiB/s, done.
+Resolving deltas: 100% (394/394), done.
+```
+  </TabItem>
+</Tabs>
+
+Run the rest of the commands in this guide from the root of the repository.
+
+## Configure ArgoCD {#configure-argocd}
+
+The Bank of Holos platform is organized as a collection of software components.
+Each component represents a piece of software provided by an upstream vendor,
+for example ArgoCD, or software developed in-house.  Components are also used to
+glue together, or integrate, other components into the platform.
+
+We'll start by changing the platform to point to our fork.  We need to do this
+so we'll be able to see changes in ArgoCD as we make changes with GitOps.
+
+<Tabs groupId="argocd-config">
+  <TabItem value="command" label="projects/argocd-config.cue">
+```cue showLineNumbers
+package holos
+
+#ArgoConfig: {
+  Enabled: true
+  // highlight-next-line
+  RepoURL: "https://github.com/holos-run/bank-of-holos"
+}
+
+```
+  </TabItem>
+</Tabs>
+
+Change the RepoURL to the URL of your fork.  For example:
+
+<Tabs groupId="F3BF73E3-3A70-40AF-9D4D-7134AF0A1763">
+  <TabItem value="command" label="projects/argocd-config.cue">
+```diff showLineNumbers
+diff --git a/projects/argocd-config.cue b/projects/argocd-config.cue
+index 5264f48..0214e99 100644
+--- a/projects/argocd-config.cue
++++ b/projects/argocd-config.cue
+@@ -2,5 +2,5 @@ package holos
+
+ #ArgoConfig: {
+        Enabled: true
+-       RepoURL: "https://github.com/holos-run/bank-of-holos"
++       RepoURL: "https://github.com/jeffmccune/bank-of-holos"
+ }
+```
+  </TabItem>
+</Tabs>
+
+We need to render the platform manifests after we make changes.
+
+## Render the Platform
+
+Platform rendering is is the process of looping over all the components in the
+platform and rendering each one into plain kubernetes manifest files.  Holos is
+designed to write plain manifest files which can be applied to Kubernetes, but
+stops short of applying them so it's easier for team members to review and
+understand changes before they're made.
+
+<Tabs groupId="219C5B3D-1369-45F9-B010-64A87EF71190">
+  <TabItem value="command" label="Command">
+```bash
+holos render platform ./platform
+```
+  </TabItem>
+  <TabItem value="output" label="Output">
+```txt
+rendered bank-accounts-db for cluster workload in 142.661334ms
+rendered bank-ledger-db for cluster workload in 144.041417ms
+rendered bank-userservice for cluster workload in 157.828709ms
+rendered bank-ledger-writer for cluster workload in 161.138292ms
+rendered bank-backend-config for cluster workload in 168.923459ms
+rendered bank-balance-reader for cluster workload in 171.877875ms
+rendered bank-secrets for cluster workload in 207.958792ms
+rendered gateway for cluster workload in 123.572583ms
+rendered bank-contacts for cluster workload in 144.466291ms
+rendered bank-transaction-history for cluster workload in 151.520041ms
+rendered httproutes for cluster workload in 139.590834ms
+rendered bank-frontend for cluster workload in 309.679834ms
+rendered app-projects for cluster workload in 107.136083ms
+rendered ztunnel for cluster workload in 160.679791ms
+rendered cni for cluster workload in 238.937625ms
+rendered cert-manager for cluster workload in 178.610834ms
+rendered istiod for cluster workload in 340.953208ms
+rendered argocd for cluster workload in 286.277ms
+rendered local-ca for cluster workload in 98.720208ms
+rendered external-secrets for cluster workload in 141.459708ms
+rendered base for cluster workload in 454.356667ms
+rendered namespaces for cluster workload in 115.401709ms
+rendered gateway-api for cluster workload in 203.5625ms
+rendered external-secrets-crds for cluster workload in 525.180209ms
+rendered crds for cluster workload in 888.406167ms
+rendered platform in 1.182857542s
+```
+  </TabItem>
+</Tabs>
+
+Rendering the platform to plain manifest files allows us to see the changes
+clearly.  We can see this one line change affected dozens ArgoCD Application
+resources across the platform.
+
+<Tabs groupId="266D26D4-31FC-45D1-88EF-EAD23BBBDCDD">
+  <TabItem value="command" label="Command">
+```bash
+git status
+```
+  </TabItem>
+  <TabItem value="output" label="Output">
+```txt
+On branch main
+Your branch is up to date with 'origin/main'.
+
+Changes not staged for commit:
+  (use "git add <file>..." to update what will be committed)
+  (use "git restore <file>..." to discard changes in working directory)
+        modified:   deploy/clusters/workload/gitops/app-projects.application.gen.yaml
+        modified:   deploy/clusters/workload/gitops/argocd-crds.application.gen.yaml
+        modified:   deploy/clusters/workload/gitops/argocd.application.gen.yaml
+        modified:   deploy/clusters/workload/gitops/bank-accounts-db.application.gen.yaml
+        modified:   deploy/clusters/workload/gitops/bank-backend-config.application.gen.yaml
+        modified:   deploy/clusters/workload/gitops/bank-balance-reader.application.gen.yaml
+        modified:   deploy/clusters/workload/gitops/bank-contacts.application.gen.yaml
+        modified:   deploy/clusters/workload/gitops/bank-frontend.application.gen.yaml
+        modified:   deploy/clusters/workload/gitops/bank-ledger-db.application.gen.yaml
+        modified:   deploy/clusters/workload/gitops/bank-ledger-writer.application.gen.yaml
+        modified:   deploy/clusters/workload/gitops/bank-secrets.application.gen.yaml
+        modified:   deploy/clusters/workload/gitops/bank-transaction-history.application.gen.yaml
+        modified:   deploy/clusters/workload/gitops/bank-userservice.application.gen.yaml
+        modified:   deploy/clusters/workload/gitops/cert-manager.application.gen.yaml
+        modified:   deploy/clusters/workload/gitops/external-secrets-crds.application.gen.yaml
+        modified:   deploy/clusters/workload/gitops/external-secrets.application.gen.yaml
+        modified:   deploy/clusters/workload/gitops/gateway-api.application.gen.yaml
+        modified:   deploy/clusters/workload/gitops/httproutes.application.gen.yaml
+        modified:   deploy/clusters/workload/gitops/istio-base.application.gen.yaml
+        modified:   deploy/clusters/workload/gitops/istio-cni.application.gen.yaml
+        modified:   deploy/clusters/workload/gitops/istio-gateway.application.gen.yaml
+        modified:   deploy/clusters/workload/gitops/istio-ztunnel.application.gen.yaml
+        modified:   deploy/clusters/workload/gitops/istiod.application.gen.yaml
+        modified:   deploy/clusters/workload/gitops/local-ca.application.gen.yaml
+        modified:   deploy/clusters/workload/gitops/namespaces.application.gen.yaml
+        modified:   projects/argocd-config.cue
+
+no changes added to commit (use "git add" and/or "git commit -a")
+```
+  </TabItem>
+</Tabs>
+
+Take a look at the Application resource for the bank-frontend component to see
+the changed `spec.source.repoURL` field.
+
+<Tabs groupId="665E5402-FB42-4975-B654-3922EE73EE07">
+  <TabItem value="command" label="Command">
+```bash
+git diff deploy/clusters/workload/gitops/bank-frontend.application.gen.yaml
+```
+  </TabItem>
+  <TabItem value="output" label="Output">
+```diff showLineNumbers
+diff --git a/deploy/clusters/workload/gitops/bank-frontend.application.gen.yaml b/deploy/clusters/workload/gitops/bank-frontend.application.gen.yaml
+index d8ede55..aed4338 100644
+--- a/deploy/clusters/workload/gitops/bank-frontend.application.gen.yaml
++++ b/deploy/clusters/workload/gitops/bank-frontend.application.gen.yaml
+@@ -9,5 +9,5 @@ spec:
+   project: bank-frontend
+   source:
+     path: ./deploy/clusters/workload/components/bank-frontend
+-    repoURL: https://github.com/holos-run/bank-of-holos
++    repoURL: https://github.com/jeffmccune/bank-of-holos
+     targetRevision: main
+```
+  </TabItem>
+</Tabs>
+
+We'll add, commit, and push this change to our fork then take a little time to
+explain what happened when we made the change and rendered the platform.
+
+<Tabs groupId="BD6A968F-FFDF-486B-8EC0-BA8B39C19303">
+  <TabItem value="command" label="Command">
+```bash
+git add .
+git commit -m 'quickstart: change argocd repo url to our fork'
+git push origin
+```
+  </TabItem>
+  <TabItem value="output" label="Output">
+```txt
+[main f2f8bc2] quickstart: change argocd repo url to our fork
+ 26 files changed, 26 insertions(+), 26 deletions(-)
+Enumerating objects: 41, done.
+Counting objects: 100% (41/41), done.
+Delta compression using up to 14 threads
+Compressing objects: 100% (31/31), done.
+Writing objects: 100% (33/33), 2.95 KiB | 2.95 MiB/s, done.
+Total 33 (delta 28), reused 0 (delta 0), pack-reused 0
+remote: Resolving deltas: 100% (28/28), completed with 4 local objects.
+To github.com:jeffmccune/bank-of-holos.git
+   c2951ec..f2f8bc2  main -> main
+```
+  </TabItem>
+</Tabs>
+
+## Platform Rendering Explained
+
+So what happens when we run `holos render platform`?  We saw `holos` write plain
+manifest files, let's dive into how and why we implemented platform rendering
+like this.
+
+### Why do we render the platform? {#why-render-the-platform}
+
+We built Holos to make the process of managing a platform safer, easier, and
+more consistent.  Before Holos we used Helm, Kustomize, and scripts to glue
+together all of the software that goes into a platform.  Then we coaxed the
+output of each tool into something that works with GitOps.  This approach has a
+number of shortcomings.  We wanted to see the manifests before ArgoCD or Flux
+applied them, so we wrote a lot of difficult to maintain scripts to get the
+template output into something useful.  We tried avoiding the scripts by having
+ArgoCD handle the Helm charts directly, but we could no longer see the changes
+clearly during code review.
+
+The platform rendering process allows us to have it both ways.  We avoid the
+unsafe text templates and glue scripts by using CUE.  We're able to review the
+exact changes that _will be_ applied during code review because holos renders
+the whole platform to plain manifest files.
+
+Finally, because we usually make each change by rendering the whole platform,
+we're able to see and consider how a single-line change, like the one we just
+made, affects the whole platform.  Before we made Holos we were frustrated with
+how difficult it was to get this zoomed-out, broad perspective of each change we
+made.
+
+### How does platform rendering work? {#how-platform-rendering-works}
+
+Holos is declarative. CUE provides resources that declare what `holos` needs to
+do.  The output of `holos` is always the same for the same inputs, so `holos` is
+also idempotent.
+
+When we run `holos render platform`, CUE builds the Platform specification
+(spec).  This is a fancy way of saying a list of software to manage on each
+cluster in the platform.  The CUE files in the `platform` directory provide the
+platform spec to `holos`.
+
+Let's open up two of these CUE files to see how this works.  Ignore the other
+files for now, they behave the same as these two.
+
+<Tabs groupId="6F01F2F7-C101-4212-A844-0E370B836B54">
+  <TabItem value="argocd" label="platform/argocd.cue">
+```cue showLineNumbers
+package holos
+
+// Manage the component on every cluster in the platform
+for Fleet in #Fleets {
+  for Cluster in Fleet.clusters {
+    // highlight-next-line
+    #Platform: Components: "\(Cluster.name)/argocd-crds": {
+      path:    "projects/platform/components/argocd/crds"
+      cluster: Cluster.name
+    }
+    // highlight-next-line
+    #Platform: Components: "\(Cluster.name)/argocd": {
+      path:    "projects/platform/components/argocd/argocd"
+      cluster: Cluster.name
+    }
+  }
+}
+```
+  </TabItem>
+  <TabItem value="external-secrets" label="platform/external-secrets.cue">
+```cue showLineNumbers
+package holos
+
+// Manage the component on every cluster in the platform
+for Fleet in #Fleets {
+  for Cluster in Fleet.clusters {
+    // highlight-next-line
+    #Platform: Components: "\(Cluster.name)/external-secrets-crds": {
+      path:    "projects/platform/components/external-secrets-crds"
+      cluster: Cluster.name
+    }
+    // highlight-next-line
+    #Platform: Components: "\(Cluster.name)/external-secrets": {
+      path:    "projects/platform/components/external-secrets"
+      cluster: Cluster.name
+    }
+  }
+}
+```
+  </TabItem>
+</Tabs>
+
+There's quite a few new concepts to unpack in these two CUE files.
+
+1. A Fleet is just a collection of clusters that share a similar, but not
+identical configuration.  Most platforms have a management fleet with one
+cluster to manage the platform, and a workload fleet for clusters that host the
+services we deploy onto the platform.
+2. A Cluster is a Kubernetes cluster.  Each component is rendered to plain
+manifests for a cluster.
+
+:::important
+On lines 6 and 10 we see a Component being assigned to the Platform.  We also
+start to dive into the syntax of CUE, which we need to understand a little
+before going further.
+:::
+
+> In its simplest form, CUE looks a lot like JSON. This is because CUE is a
+superset of JSON.  Or, put differently: all valid JSON is CUE.
+>
+> 1. C-style comments are allowed
+> 2. field names without special characters don't need to be quoted
+> 3. commas after a field are optional (and are usually omitted)
+> 4. commas after the final element of a list are allowed
+> 5. **the outermost curly braces in a CUE file are optional**
+>
+> JSON objects are called structs in CUE. JSON arrays are called lists, Object
+members are called fields, which link their name, or label, to a value.
+
+There are two important things to know about CUE to understand these two files.
+First, the curly braces have been omitted which is item 5 on the list above.
+Second, CUE is all about _unification_.  These files could have been written
+like this:
+
+<Tabs groupId="59FFCCB6-A584-42ED-AC37-1C2BDCF5A523">
+  <TabItem value="argocd" label="platform/argocd.cue">
+```cue showLineNumbers
+package holos
+
+// Manage the component on every cluster in the platform
+for Fleet in #Fleets {
+  for Cluster in Fleet.clusters {
+    #Platform: {
+      // highlight-next-line
+      // Define #Platform.Components
+      // highlight-next-line
+      Components: {
+        "\(Cluster.name)/argocd-crds": {
+          path:    "projects/platform/components/argocd/crds"
+          cluster: Cluster.name
+        }
+      }
+
+      // highlight-next-line
+      // Define #Platform.Components again!? Error?
+      // highlight-next-line
+      Components: {
+        "\(Cluster.name)/argocd": {
+          path:    "projects/platform/components/argocd/argocd"
+          cluster: Cluster.name
+        }
+      }
+    }
+  }
+}
+```
+  </TabItem>
+  <TabItem value="external-secrets" label="platform/external-secrets.cue">
+```cue showLineNumbers
+package holos
+
+// Manage the component on every cluster in the platform
+for Fleet in #Fleets {
+  for Cluster in Fleet.clusters {
+    #Platform: {
+      // highlight-next-line
+      // Define #Platform.Components
+      // highlight-next-line
+      Components: {
+        "\(Cluster.name)/external-secrets-crds": {
+          path:    "projects/platform/components/external-secrets-crds"
+          cluster: Cluster.name
+        }
+      }
+
+      // highlight-next-line
+      // Define #Platform.Components again!? Error?
+      // highlight-next-line
+      Components: {
+        "\(Cluster.name)/external-secrets": {
+          path:    "projects/platform/components/external-secrets"
+          cluster: Cluster.name
+        }
+      }
+    }
+  }
+}
+```
+  </TabItem>
+</Tabs>
+
+:::important
+Unlike most other languages, it is common to declare the same field in multiple
+places.  CUE **unifies** the value of the field.  We can think of CUE as a
+Configuration Unification Engine.
+:::
+
+Now that we know curly braces can be omitted and values are unified, we can
+understand how the rest of the CUE files in the platform directory behave.
+
+:::tip
+Each CUE file in the platform directory adds components to the
+`#Platform.Components` struct.
+:::
+
+The final file in the directory is responsible for producing the Platform spec.
+It looks like this.
+
+<Tabs groupId="166F0925-9405-4571-A0AB-C7E2107876FD">
+  <TabItem value="command" label="platform/platform.gen.cue">
+```cue showLineNumbers
+package holos
+
+#Platform.Output
+```
+  </TabItem>
+</Tabs>
+
+This file provides the value of the `#Platform.Output` field, the platform spec,
+to `holos`.
+
+Let's take a look at that Output value:
+
+<Tabs groupId="475C92AC-C6DA-4FB9-859C-722921277CFC">
+  <TabItem value="command" label="Command">
+```bash
+cue export --out yaml ./platform
+```
+  </TabItem>
+  <TabItem value="output" label="Output">
+```yaml showLineNumbers
+kind: Platform
+apiVersion: v1alpha3
+metadata:
+  name: guide
+spec:
+  model: {}
+  components: # This is a trimmed list for readability.
+    - path: projects/bank-of-holos/security/components/bank-secrets
+      cluster: workload
+    - path: projects/bank-of-holos/frontend/components/bank-frontend
+      cluster: workload
+    - path: projects/platform/components/argocd/crds
+      cluster: workload
+    - path: projects/platform/components/argocd/argocd
+      cluster: workload
+    - path: projects/platform/components/external-secrets-crds
+      cluster: workload
+    - path: projects/platform/components/external-secrets
+      cluster: workload
+```
+  </TabItem>
+</Tabs>
+
+:::tip
+You don't normally need to execute `cue`, CUE is built into `holos`.  We use it
+here to gain insight.
+:::
+
+We see the platform spec is essentially a list of components, each assigned to a
+cluster.
+
+:::important
+Notice CUE unifies `Components` from multiple files into one list.
+
+We'll see this unification behavior again and again.  Unification is the
+defining characteristic of CUE that makes it a unique, powerful, and _safe_
+configuration language.
+:::
+
+Holos takes this list of components and builds each one by executing:
+
+```bash
+holos render component --cluster-name="example" "path/to/the/component"
+```
+
+We can think of platform rendering as rendering a list of components, passing
+the cluster name each time.  Rendering each component writes the fully rendered
+manifest for that component to the `deploy/` directory, organized by cluster for
+GitOps.
+
+## Render a Component
+
+Rendering a component works much the same way as rendering a platform. `holos`
+uses CUE to produce a specification, then processes it.  The specification of a
+component is called a BuildPlan.  A BuildPlan is a list of zero or more
+kubernetes resources, Helm charts, Kustomize bases, and additional files to
+write into the `deploy/` directory.
+
+Let's take a look at the cert-manager component.  Notice the
+`platform/cert-manager.cue` file has the field `path:
+"projects/platform/components/cert-manager"`.  This path indicates where to
+start working with the cert-manager component.
+
+<Tabs groupId="129DD743-0FE3-44C0-ACA4-6569C98BA40E">
+  <TabItem value="cert-manager" label="projects/platform/components/cert-manager/cert-manager.cue">
+```cue showLineNumbers
+package holos
+
+// Produce a helm chart build plan.
+// highlight-next-line
+(#Helm & Chart).BuildPlan
+
+// highlight-next-line
+let Chart = {
+  Name:      "cert-manager"
+  // #CertManager is defined in projects/cert-manager.cue
+  // highlight-next-line
+  Version:   #CertManager.Version
+  // highlight-next-line
+  Namespace: #CertManager.Namespace
+
+  Repo: name: "jetstack"
+  Repo: url:  "https://charts.jetstack.io"
+
+  // CUE offers type checking and validation of Helm values.
+  // highlight-next-line
+  Values: installCRDs: true
+  // highlight-next-line
+  Values: startupapicheck: enabled: false
+}
+```
+  </TabItem>
+  <TabItem value="root" label="projects/cert-manager.cue">
+```cue showLineNumbers
+package holos
+
+// Platform wide configuration
+#CertManager: {
+  // highlight-next-line
+  Version:   "1.15.3"
+  // highlight-next-line
+  Namespace: "cert-manager"
+}
+
+// Register the namespace
+// The underscore indicates the value is defined elsewhere in CUE.
+#Namespaces: (#CertManager.Namespace): _
+```
+  </TabItem>
+</Tabs>
+
+This file introduces a few new concepts.
+
+1. Line 4 indicates this component produces a BuildPlan that wraps a Helm Chart.
+2. On line 6 `let` binds a name to an expression for the current scope.  The
+current file in this case.
+3. Notice Chart is referenced on line 4 before it's bound on line 6.  **Order is
+irrelevant in CUE**.  Complex changes are simpler and easier when we don't have
+to think about order.
+4. The chart version and namespace are defined in a different file closer to the
+root, `projects/cert-manager.cue`
+5. We define Helm values in CUE to take advantage of strong type checking and
+manage multiple Helm charts consistently with platform wide values.
+
+Let's take a look at the BuildPlan this CUE configuration defines.
+
+<Tabs groupId="B54D5791-4E5B-4148-A368-62D9BE80760C">
+  <TabItem value="command" label="Command">
+```bash
+cue export --out yaml ./projects/platform/components/cert-manager
+```
+  </TabItem>
+  <TabItem value="output" label="Output">
+```yaml showLineNumbers
+kind: BuildPlan
+apiVersion: v1alpha3
+spec:
+  components:
+    resources:
+      gitops/cert-manager:
+        kind: KubernetesObjects
+        apiVersion: v1alpha3
+        metadata:
+          name: gitops/cert-manager
+          namespace: cert-manager
+        deployFiles:
+          clusters/no-name/gitops/cert-manager.application.gen.yaml: |
+            apiVersion: argoproj.io/v1alpha1
+            kind: Application
+            metadata:
+              name: cert-manager
+              namespace: argocd
+            spec:
+              destination:
+                server: https://kubernetes.default.svc
+              project: platform
+              source:
+                path: ./deploy/clusters/no-name/components/cert-manager
+                repoURL: https://github.com/jeffmccune/bank-of-holos
+                targetRevision: main
+        skip: false
+    helmChartList:
+      - kind: HelmChart
+        apiVersion: v1alpha3
+        chart:
+          name: cert-manager
+          version: 1.15.3
+          release: cert-manager
+          repository:
+            name: jetstack
+            url: https://charts.jetstack.io
+        valuesContent: |
+          installCRDs: true
+          startupapicheck:
+            enabled: false
+        enableHooks: false
+        metadata:
+          name: cert-manager
+          namespace: cert-manager
+        apiObjectMap: {}
+        skip: false
+```
+  </TabItem>
+</Tabs>
+
+:::important
+Again, you don't normally need to execute `cue`, it's built into `holos`.  We
+use it here to show how Holos works with Helm.
+:::
+
+Looking at the BuildPlan, we see `holos` will render the Helm chart into the
+deploy directory along with an ArgoCD Application resource in the `gitops/`
+directory.
+
+:::tip
+The BuildPlan API is flexible enough to write any file into the `deploy/`
+directory.  Holos uses this flexibility to support both Flux and ArgoCD.
+:::
+
+When we run `cue export`, we get back a Core API BuildPlan.  The BuildPlan is
+produced by the `#Helm` definition on line 4 which is part of the Author API.
+The Core API is the contract between CUE and `holos`.  As such, it's not as
+friendly as the Author API.  The Author API is the contract component authors
+and platform engineers use to configure and manage the platform.  The Author API
+is meant for people, the Core API is meant for machines.  This explains why we
+see quite a few fields in the exported BuildPlan we didn't cover in this guide.
+Day to day we don't need to be concerned with those fields because the Author
+API handles them for us.
+
+:::tip
+Our intent is to provide an ergonomic way to manage the platform with the Author
+API.
+:::
+
+When the Author API doesn't offer a path forward, authors may use the Core API
+directly from CUE.  We can think of the Core API as an escape hatch for the
+Author API.  We'll see some examples of this in action in the more advanced
+guides.
+
+## Next Steps
+
+Thank you for finishing the Quickstart guide.  Dive deeper with the next guide
+on how to [Deploy a Service] which explains how to take one of your existing
+Helm charts or Deployments and manage it with Holos.
+
+[application]: https://argo-cd.readthedocs.io/en/stable/user-guide/application-specification/
+[schema]: /docs/api/schema/v1alpha3/
+[core]: /docs/api/core/v1alpha3/
+[Deploy a Service]: /docs/guides/deploy-a-service/
+[Manage a Project]: /docs/guides/manage-a-project/

doc/md/intro.md

@@ -0,0 +1,64 @@
+# Introduction
+
+⚡️ Holos will help you build your **software development platform in no time.**
+
+💸 Building a software development platform is **time consuming and expensive**.  Spend more time building features for your customers and less time managing your development platform.
+
+💥 Already have a platform?  Add new features and services to your platform easily with Holos.
+
+🧐 Holos is a platform builder. It builds a hollistic software development platform composed of best-of-breed cloud native open source projects.  Holos is also a tool to make it easier to manage cloud infrastructure by providing a typed alternative to yaml templates.
+
+## Features
+
+Holos was built to solve two main problems:
+
+ 1. Building a platform usually takes 3 engineers 6-9 months of effort.  Holos provides a reference platform that enables you to deploy and customize your platform in a fraction of the time.
+ 2. Configuration changes often cause outages.  Existing tools like Helm make it difficult to understand the impact a configuration change will have.  Holos provides a unique, unified configuration model powered by CUE that makes it safer and easier to roll out configuration changes.
+
+A core principle of Holos is that organizations gain value from owning the the platform they build on.  Avoid vendor lock-in, future price hikes, and expensive licensing changes by building on a solid foundation of open source, cloud native computing foundation backed projects.
+
+The following features are built into the Holos reference platform.
+
+:::tip
+
+Don't see your preferred technology in the stack?  Holos is designed to enable you to swap out components of the platform tech stack.
+
+:::
+
+- **Continuous Delivery**
+  - Holos builds a GitOps workflow for each application running in the platform.
+  - Developers push changes which are automatically deployed.
+  - Powered by [ArgoCD](https://argo-cd.readthedocs.io/en/stable/)
+- **Identity and Access Management** (IAM)
+  - Holos builds a standard OIDC identity provider for you.
+  - Integrates with your exisitng IAM and SSO system, or works independently.
+  - Powerful customer identity and access management features.
+  - Role based access control.
+  - Powered by [ZITADEL](https://zitadel.com/)
+- **Zero Trust**
+  - Authenticate and Authorize users at the platform layer instead of or in addition to the application layer.
+  - Integrated with observability to measure and alert about problems before customers complain.
+  - Powered by [Istio](https://istio.io/)
+- **Observability**
+  - Holos collects performance and availability metrics automatically, without requiring application changes.
+  - Optional, deeper integration into the application layer.
+  - Distributed Tracing
+  - Logging
+  - Powered by Prometheus, Grafana, Loki, and OpenTelemetry.
+- **Data Platform**
+  - Integrated management of PostgreSQL
+  - Automatic backups
+  - Automatic restore from backup
+  - Quickly fail over across multiple regions
+- **Multi-Region**
+  - Holos is designed to operate in multiple regions and multiple clouds.
+  - Keep customer data in the region that makes the most sense for your business.
+  - Easily cut over from one region to another for redundancy and business continuity.
+
+## Development Status
+
+Holos is being actively developed by [Open Infrastructure Services](https://openinfrastructure.co).  Release can be found [here](https://github.com/holos-run/holos/releases).
+
+## Adoption
+
+Organizations who have officially adopted Holos can be found [here](https://github.com/holos-run/holos/blob/main/ADOPTERS.md).

doc/md/introduction.md

@@ -0,0 +1,20 @@
+---
+description: Holos Documentation
+slug: /
+---
+
+# Introduction
+
+Welcome to Holos.  Holos is an open source tool to manage software development
+platforms safely, easily, and consistently.
+
+Our documentation is organized into [Guides] and the [API Reference].
+
+:::tip
+Please start with the [Quickstart] guide to learn who Holos is for, what
+problems it solves, and if it can solve problems you have.
+:::
+
+[Guides]: /docs/guides/
+[API Reference]: /docs/api/
+[Quickstart]: /docs/quickstart/

doc/md/reference-platform/architecture.md

@@ -0,0 +1,3 @@
+# Architecture
+
+Coming soon.

doc/md/runbooks/argocd.md

@@ -0,0 +1,14 @@
+# ArgoCD
+
+Create the deploy key secret in the management cluster.
+
+```bash
+tmp="$(mktemp -d)"
+(cd $tmp && ssh-keygen -t ed25519 -f sshPrivateKey -m pem -C argocd -N '')
+echo git@github.com:holos-run/holos-infra.git > "${tmp}/url"
+holos create secret -n argocd --append-hash=false creds-holos-infra --from-file $tmp
+rm -rf "$tmp"
+```
+
+When syncing the secret, the ExternalSecret needs to set the label
+`argocd.argoproj.io/secret-type: repo-creds`.

doc/md/runbooks/deploy.md

@@ -0,0 +1,31 @@
+# Deployment
+
+This document describes how deployment from `main` is configured.
+
+1. Refer to the publish workflow.
+2. Uses a SSH deploy key to:
+3. Clone the holos-infra repo.
+4. Write the image tag to saas/userdata/components/dev-holos-app/images.json
+5. Run holos render platform ./platform
+6. Commit and push the results.
+7. ArgoCD takes over the rollout.
+
+## Credentials
+
+TODO: Lock this down more, the deploy key has too much access to the infra
+repository.
+
+```bash
+mkdir -p tmp
+cd tmp
+ssh-keygen -t ed25519 -f holos-infra.key -m pem -C holos-run/holos -N ''
+gh secret set DEPLOY_SSH_PRIVATE_KEY < holos-infra.key
+gh api --method POST \
+  -H "Accept: application/vnd.github+json" \
+  /repos/holos-run/holos-infra/keys \
+  -f title='holos-run/holos deploy key' \
+  -f key="$(cat holos-infra.key.pub)" \
+  -F read_only=false
+cd ..
+rm -rf tmp
+```

doc/md/runbooks/login/backups.md

@@ -0,0 +1,10 @@
+# ZITADEL Backups
+
+Refer to [Schedule backups](https://cloudnative-pg.io/documentation/1.23/backup/#scheduled-backups)
+
+By default ZITADEL is backed up daily to S3.  When restoring into a new cluster
+of the same name, increment the revision variable to create a new blank folder
+for the new cluster WAL.  The cluster will not initialize unless the WAL
+directory is empty.
+
+The cluster will recovery from the previous rev.

doc/md/runbooks/login/failover.md

@@ -0,0 +1,3 @@
+## Overview
+
+TODO: This runbook needs to be updated to reflect the switch from PGO to CNPG.