Install Chat

Give Chat its own database and a role that owns it, separate from the gateway's database. The role doesn't need to be a superuser, but pgvector must be installed on the server and the extension created in Chat's database by a superuser:

CREATE ROLE obleth_chat LOGIN PASSWORD '…' NOSUPERUSER NOCREATEDB NOCREATEROLE;
CREATE DATABASE obleth_chat OWNER obleth_chat;
\connect obleth_chat
CREATE EXTENSION IF NOT EXISTS vector;

Chat runs its migrations at startup.

With CloudNativePG, have the operator create the extension when it creates the database:

bootstrap:
  initdb:
    database: obleth_chat
    owner: obleth_chat
    postInitApplicationSQL:
      - CREATE EXTENSION IF NOT EXISTS vector

The operator's <cluster>-app Secret has a ready-made connection string under the key uri. Use it as OBLETH_CHAT_DATABASE_URL; the host in it (<cluster>-rw.<namespace>) resolves from Chat's namespace.

deploy/compose.connected.yaml runs Chat with PostgreSQL 17 and pgvector. Set these in .env:

• OBLETH_CHAT_POSTGRES_ADMIN_PASSWORD and OBLETH_CHAT_POSTGRES_PASSWORD, 64 hex characters each.
• OBLETH_CHAT_BOOTSTRAP_PASSWORD, at least 12 characters.
• OBLETH_CHAT_ORIGIN and OBLETH_CHAT_GATEWAY_URL.
• OBLETH_CHAT_GATEWAY_SIGNING_KEY_FILE, the absolute path of an RSA key (Connect the gateway shows how to make one). The container runs as UID 10001 and must be able to read it.

docker compose --env-file .env -f deploy/compose.connected.yaml up -d

The database's init script runs only on an empty volume, so changing a password in .env later doesn't change the database role's password.

Set the origins in deploy/k8s.yaml's ConfigMap, then create the namespace and two Secrets before applying it, because the Deployment needs them to start:

kubectl create namespace obleth-chat
kubectl -n obleth-chat create secret generic obleth-chat-env \
  --from-literal=OBLETH_CHAT_DATABASE_URL='postgresql://…' \
  --from-literal=OBLETH_CHAT_BOOTSTRAP_PASSWORD='…'
kubectl -n obleth-chat create secret generic obleth-chat-gateway-signing-key \
  --from-file=gateway_signing_key=obleth-chat-signing.pem
kubectl apply -f deploy/k8s.yaml

The manifest has the Deployment, Service and PodDisruptionBudget, a ServiceAccount and Role so Chat can start workspace pods in its namespace, and NetworkPolicies that fence those pods in. The namespace enforces Pod Security restricted, so keep the database elsewhere unless it meets that. deploy/k8s-postgres.yaml is the PostgreSQL that setup.sh runs; its header lists what it needs. Pin the images by digest in production.

Requires Rust stable and a database as above. Node.js 20.12 or later is optional, for the startup wrapper that reads .env.

cp .env.example .env
# Set OBLETH_CHAT_DATABASE_URL, OBLETH_CHAT_ORIGIN and
# OBLETH_CHAT_BOOTSTRAP_PASSWORD (at least 12 characters).
npm run start:api
# http://localhost:8085

Without the wrapper, export the same variables and run cargo run --release or target/release/obleth-chat. The binary itself doesn't read .env.

Each release publishes ghcr.io/thediymaker/obleth-chat/chat:vX.Y.Z for amd64 and arm64; see the releases. deploy/Dockerfile.api is a multi-stage build: it compiles the release binary, then copies it with the web app into a slim runtime image that runs unprivileged as UID 10001 with a read-only root filesystem. The image includes poppler-utils and unzip for Knowledge text extraction.

Chat checks the HTTPS servers it calls (the gateway, your OIDC provider, the Knowledge bucket, GitHub) against the public root certificates built into it, not the operating system's store. Adding a certificate to the image or the host doesn't change that, so these servers need certificates from a public certificate authority. Plain HTTP to a gateway inside your network is fine. Kubernetes cluster connections are the exception: each one carries its cluster's own CA.