Skip to content

Kubernetes

The public installer targets Docker Compose because it gives the shortest path to a first boot. Kubernetes uses the same image and registry credentials, but you create the registry secret yourself.

Create an image pull secret

kubectl create secret docker-registry walter-registry \
  --docker-server=ghcr.io \
  --docker-username=<provided-username> \
  --docker-password=<provided-token>

Reference the Walter image

apiVersion: apps/v1
kind: Deployment
metadata:
  name: walter
spec:
  replicas: 1
  selector:
    matchLabels:
      app: walter
  template:
    metadata:
      labels:
        app: walter
    spec:
      imagePullSecrets:
        - name: walter-registry
      containers:
        - name: walter
          image: ghcr.io/matchylabs/walter:0.1.0
          env:
            - name: PHX_HOST
              value: walter.example.com
            - name: PHX_SERVER
              value: "true"

Database and migrations

Walter still needs:

  • PostgreSQL with the vector, uuid-ossp, and citext extensions
  • a one-off migration step before the app is restarted on a new image
  • persistent storage for Walter state if you want generated bootstrap secrets to survive pod replacement

The Docker Compose bundle in this repo wraps migrations in a setup service. For Kubernetes, your equivalent is usually a Job or Helm hook that runs before the main deployment is rolled forward.

If you are evaluating Walter on-prem for the first time, start with Docker Compose and move to Kubernetes after you have validated your registry access, license workflow, and LLM configuration.