Skip to main content
r5d.chat publishes two images per release to GHCR. Both are tagged with the release version and latest. Always deploy an explicit version in production.

The control-plane image

A small multi-stage build. Dependencies install first, the application is typechecked and built, and the runtime stage keeps only the build output, migrations, and production dependencies. It runs as the unprivileged bun user and listens on port 3000. The chart runs the same image as an init container with bun run db:migrate to apply database migrations before the application starts. Migrations take a PostgreSQL advisory lock, so parallel rollouts cannot race.

The workspace image

The workspace is deliberately batteries-included: it is the general-purpose environment where user work happens, and a missing tool means a failed task.
Bun and bunx, Node.js with npm/npx, Python 3 with pip/venv/pytest, C/C++ build tools, CMake, pkg-config, Git and Git LFS, GitHub CLI, shellcheck, ripgrep, jq, yq, tmux, and common editors and archive utilities.
NumPy, pandas, SciPy, Matplotlib, Seaborn, Pillow, BeautifulSoup, lxml, requests, SQLite, PostgreSQL and Redis clients, and Graphviz.
FFmpeg and ffprobe, ImageMagick, libvips, ExifTool, MediaInfo, gifsicle, WebP, pngquant, optipng, jpegoptim, librsvg, Tesseract OCR, and broad Noto and DejaVu font coverage including CJK and emoji.
LibreOffice headless, Pandoc, Poppler, qpdf, Ghostscript, antiword, unrtf, Recoll and Xapian for ranked full-text search, and the Python python-docx, openpyxl, and python-pptx libraries.
The image also bundles agent skills at /opt/r5dchat/skills for producing documents, spreadsheets, slides, and PDFs.
Java, Go, Rust, browser automation, TeX, geospatial tooling, and GPU runtimes are intentionally excluded to keep the image manageable. Agents can install them on demand, or you can build a variant image.

Persistence inside a workspace

Only /home/r5d is on the persistent volume. Packages an agent installs into system paths at runtime disappear when the pod scales to zero. Add broadly useful tools to the image instead of relying on ad-hoc installs.

Build the images yourself

Both Dockerfiles build from the repository root.
Smoke-test the workspace image before rolling it out:

Publish to your own registry

If you maintain a fork or need images in a private registry, build and push with an immutable tag, then point the chart at them:

Rolling out a new workspace image

Existing workspace Deployments need an explicit image update.