Skip to main content
ChatCLI can be packaged as a Docker container and deployed on Kubernetes using the official Helm chart. This page covers all deployment scenarios.

Official Images (GHCR)

Official Docker images are automatically published to the GitHub Container Registry with each release:

ChatCLI Server

Latest version: 1.172.0
ghcr.io/diillson/chatcli:1.172.0

Kubernetes Operator

Latest version: 1.172.0
ghcr.io/diillson/chatcli-operator:1.172.0
The images support multi-arch (linux/amd64 and linux/arm64).

Docker

Building the Image (Local)

The Dockerfile uses a multi-stage build to produce a minimal image (~20MB):
  • Build stage: golang:1.25-alpine compiles the binary
  • Runtime stage: alpine:3.21 with non-root user and built-in health check

Building the Operator Image (Local)

The operator Dockerfile uses:
  • Build stage: golang:1.25 with multi-arch support (TARGETARCH)
  • Runtime stage: gcr.io/distroless/static:nonroot (maximum security, no shell)

Running with Docker

Docker Compose

The project includes a docker-compose.yml ready for development:
1

Set the variables

2

Start the container

3

Connect from your terminal

Docker Compose configures:
  • Port 50051 exposed
  • Persistent volumes for sessions and plugins
  • Automatic restart (unless-stopped)
  • All LLM variables via environment
  • Security hardening: read-only filesystem, no-new-privileges, CPU/memory limits, tmpfs for /tmp

docker-compose.yml File

The container runs with a read-only filesystem and no-new-privileges by default. The /tmp directory uses an in-memory tmpfs (limited to 100MB). The named volumes (chatcli-sessions, chatcli-plugins) are the only writable mount points. See the security documentation for details.

Kubernetes (Helm)

ChatCLI Helm charts are available as OCI artifacts on GHCR โ€” no need to clone the repository.

Prerequisites

  • Kubernetes cluster (kind, minikube, EKS, GKE, AKS, etc.)
  • Helm 3.8+ installed (OCI support)
  • kubectl configured for the cluster

Basic Installation

Installation with Security (Helm)

For deployments with full security, including rate limiting, JWT authentication, and secure agent mode:

Installation with K8s Watcher (Single-Target)

Installation with Multi-Target + Prometheus

To monitor multiple deployments with Prometheus metrics, use a values.yaml:
The chart automatically:
  • Creates a ServiceAccount with RBAC for the watcher to read pods, events, and logs
  • Auto-detects multi-namespace: if targets are in different namespaces, uses ClusterRole instead of Role
  • Generates a ConfigMap <name>-watch-config with the multi-target YAML
  • Mounts the config as a volume and passes --watch-config to the container
  • Properly passes --token, --model, and --mcp-config flags to the server
  • Uses native gRPC health probes (liveness, readiness, and startup) instead of pidof
  • Includes all 17 operator CRDs in the crds/ directory

Helm Chart Values

Server

TLS

LLM

Secrets (API Keys)

GitHub Copilot

For authentication, use secrets.githubCopilotToken with a token obtained via /auth login github-copilot, or set GITHUB_COPILOT_TOKEN as an environment variable.

Ollama

K8s Watcher

Fields for each target (watcher.targets[].):

Provider Fallback

MCP (Model Context Protocol)

Bootstrap and Memory

Skill Registry

When enabled, the values are passed as CHATCLI_REGISTRY_* environment variables in the ConfigMap. The ChatCLI container automatically creates ~/.chatcli/registries.yaml with the default registries (chatcli, clawhub). Use /skill search and /skill install to manage skills via registries.

Persistence

Security

When readOnlyRootFilesystem is true, the chart automatically mounts a tmpfs at /tmp and an emptyDir at /home/chatcli/.chatcli (200Mi) for runtime data. The HOME=/home/chatcli variable is set automatically. To monitor multiple namespaces, enable rbac.clusterWide: true. See the security documentation for details. Note: The ConfigMap and Secret referenced via envFrom are marked as optional: true, allowing you to create the Instance/Deployment before the dependent resources. The operator watches Secrets automatically and triggers rolling updates when they are created or updated.

Autoscaling (HPA)

When autoscaling.enabled is true, replicaCount is ignored and the HPA controls the number of replicas automatically.

Pod Disruption Budget

The PDB ensures high availability during node upgrades, drains, and cluster maintenance.

Network Policy

NetworkPolicy restricts network traffic at the pod level. Requires a CNI with NetworkPolicy support (Calico, Cilium, etc.).

Networking

gRPC and multiple replicas: gRPC uses persistent HTTP/2 connections that pin to a single pod. For replicaCount > 1, enable service.headless: true to activate round-robin load balancing via DNS. The client already has built-in keepalive and round-robin support. Ingress gRPC: When Ingress is enabled with className: nginx, the chart automatically adds the nginx.ingress.kubernetes.io/backend-protocol: "GRPC" annotation to route gRPC traffic correctly.

Using an Existing Secret

If you already have a Secret with the API keys:
The Secret must contain the expected keys:

Accessing the Server

Ingress (with TLS)

Upgrade and Rollback


Security Configuration

The Helm chart supports advanced security configuration for production environments:
In Kubernetes, bindAddress is automatically detected as 0.0.0.0 via the KUBERNETES_SERVICE_HOST environment variable. No manual configuration is needed.
In production, always configure security.jwtSecretRef to enable JWT authentication. Without it, the server accepts unauthenticated connections.

Full Example: Production

Single-Target (Legacy)

When targets are in different namespaces (e.g., production and batch), the chart automatically creates a ClusterRole instead of a namespace-scoped Role.

Next Steps

Server

Configure the gRPC server

Remote Connection

Connect to the server

K8s Watcher

Monitor Kubernetes