§08 · Deploy & operate

Manual install · manifests & Helm

Raw manifests under GitOps instead of the installer: the platform deploy.yaml, the Helm chart, the CRD bundle, and the edits the stock files need.

exo-install is the fastest path, but if you run everything through Argo CD, Flux, or a reviewed kustomize tree, you want the raw manifests. They're the same ones the installer embeds, derived from the operator manifests under exo/exo-install/manifests/ and the repo-root deploy.yaml.

When to go manual

  • You manage cluster state declaratively and don't want a binary mutating it.
  • You need to diff and review every change to RBAC or the platform Secret.
  • You install the operator via Helm as part of a larger release.

Render & apply

The operator and platform sources are templated (namespace, image, managed mode, secrets, service type), so use exo-install render to materialise a concrete copy. Apply in order: crds/ operator/platform/.

terminal· bash
exo-install render crds | kubectl apply -f -
exo-install render operator | kubectl apply -f -
exo-install render platform | kubectl apply -f -

Platform · deploy.yaml

The repo root ships a standalone deploy.yaml for the control plane (Namespace, Secret exo-secrets, ConfigMap exo-config, Service plus Deployment exo-app on port 9092, 2 replicas with a rolling update). Two edits make it production-usable:

exo-secrets · stringData· yaml
1stringData:
2 EXO_JWT_SECRET: "<openssl rand -base64 48>"
3 EXO_ENCRYPTION_KEY: "<openssl rand -hex 16>"
4 EXO_DATABASE_DSN: "host=db user=exo dbname=exo sslmode=require"
5 EXO_CLAUDE_API_KEY: ""
terminal· bash
kubectl apply -f deploy.yaml
kubectl -n exo rollout status deploy/exo-app

Operator · Helm chart

The exo chart covers all three components: operator, platform, and an optional in-cluster Postgres. CRDs sit in the chart's native crds/ directory, applied on helm install and never touched on upgrade or uninstall.

terminal· bash
helm repo add exo https://exo.assets.adaptive.live/charts
helm install exo exo/exo \
--set platform.enabled=false --set postgres.enabled=false \
--set operator.managed=true \
--set operator.baseURL=https://exo.example.com
values.yaml (operator knobs)· yaml
1imagePullSecrets: []
2operator:
3 namespace:
4 name: autonomic-system
5 create: true
6 image:
7 repository: docker.io/adaptivelive/autonomic-manager
8 tag: ""
9 pullPolicy: IfNotPresent
10 replicas: 1
11 args:
12 - --leader-elect
13 managed: false
14 baseURL: https://exo.adaptive.live
15 authTokenSecret:
16 name: autonomic-auth
17 key: token
18 webhook:
19 enabled: true
20 failurePolicy: Fail
21crds:
22 install: true

Provide the secrets. The chart creates the exo-secrets Secret from the values you pass: the 32-byte AES-256 EXO_ENCRYPTION_KEY and the JWT signing secret. Generate them inline so they are not hard-coded:

terminal· bash
helm repo add exo https://exo.assets.adaptive.live/charts
helm repo update
helm install exo exo/exo --namespace exo --create-namespace \
--set platform.image.tag=v0.3.1 \
--set platform.encryptionKey=$(openssl rand -hex 16) \
--set platform.jwt.secret=$(openssl rand -base64 48)

CRDs

If you manage CRDs out-of-band, the definitions live at helm/exo/crds/*.yaml (the same set the installer embeds under exo/exo-install/manifests/crds/). Apply them directly and skip exo-install crds. See CRD overview.