Install SRW

Where it runs

One box, or a cluster you already have?

A single Linux machine becomes a cluster with k3s. An existing cluster brings its own ingress controller and storage, and the values adapt to what it has.

k3s ships Traefik and node-local storage. The runbook starts with the two commands that install it.

Setup

Trying it out, or running it for real?

Evaluation keeps every credential in one values file. Production keeps them in Secrets you own and lets you swap any bundled service for one you already run.

Domain and TLS

Where will people reach it?

Every hostname is derived from the base domain. TLS comes from cert-manager; install.sh installs it when the cluster does not have it.

Base domain

ACME account e-mail HTTP-01 validation: port 80 must reach the ingress from the internet.

Services

Bundled, or bring your own?

The evaluation setup bundles everything. Switch to Production to bring your own Postgres, identity provider, git server or cloud storage.

Extras

Optional. The first three ship with the chart; the Dashboard is a separate install that install.sh does for you.

Neo4j knowledge graph. Project knowledge base. Community edition unless you bring an Enterprise license. pgAdmin. Database admin UI at pgadmin.<domain>, the SRW databases pre-registered. Login generated into the Secret. Dozzle. Live container logs at dozzle.<domain>. No login of its own, so keep that hostname on your VPN. Kubernetes Dashboard. A web view of pods, logs and events for anyone new to Kubernetes. Reached by port-forward with a token, never a public hostname.

Models and capacity

Which model providers, how many workers?

Pick the providers you hold keys for; each becomes a line to fill in. Keys can also be added after install under Admin → Providers, including local OpenAI-compatible endpoints. Web search works out of the box through the bundled SearXNG.

Tavily key for hosted web search, extract and crawl. Optional.

Max concurrent workers Agent pods that may run at once. Each needs roughly 1 vCPU and 1 GiB.

VM workspaces

How big is a VM, and how does the platform reach it?

Each VM boots from a golden image cloned onto its own root disk. install.sh installs KubeVirt and CDI matching your Kubernetes version; the runbook lists the hardware checks.

Root disk storage class Root disk size vCPU per VM Memory per VM Max VMs at once

SSH public key the platform uses to reach each VM ssh-keygen -t ed25519 -f srw-vm -N "" — paste srw-vm.pub here; the private half goes into srw-secrets.yaml.

Pin VMs to labelled nodes. Required on a multi-node cluster with node-local storage (local-path): a root disk can only be mounted on the node that created it.

chevron_rightAdvanced — chart version, registry credential, secret values

Chart version (optional) Pin a version like 0.0.24, or leave empty.

Pull images with a registry credential. The images are public; tick this for a private mirror or a rate-limited network. install.sh then reads GHCR_USER and GHCR_TOKEN.

Your cluster, your values, one runbook.