- Remove patch_tts_tool.py (orphaned)
- Remove run-multi-gateways.sh (replaced by s6 native profile supervision)
- Remove start-hermes.sh (overengineered — the image does this natively)
- compose.yml: command: gateway run, drop HERMES_PROFILES env var
- Dockerfile: revert start-hermes.sh COPY addition
Per-profile gateways are now managed by s6-overlay natively:
profiles with desired_state=running in gateway_state.json are
auto-started by the s6 reconciler on boot.
- New start-hermes.sh: multi-profile launcher that works with s6-overlay's
main-program model (replaces bash->tini->entrypoint.sh chain)
- Dockerfile: COPY start-hermes.sh into /usr/local/bin/ alongside
run-multi-gateways.sh (which is now unused but kept for reference)
- compose.yml: remove entrypoint override, CMD now points at
/usr/local/bin/start-hermes.sh via the image default ENTRYPOINT
Fixes the SIGTERM crash loop caused by S6_CMD_ARG0 being unset when the
deprecated entrypoint.sh shim bypassed s6-overlay's /init.
The custom ENTRYPOINT chained bash -> tini -g -> deprecated entrypoint.sh,
bypassing s6-overlay's /init entirely. This left S6_CMD_ARG0 unset and the
orphan -g flag crashed rc.init with '-g: not found' -> SIGTERM -> restart loop.
Fix:
- Remove the ENTRYPOINT override so the image default is used:
ENTRYPOINT ['/init', '/opt/hermes/docker/main-wrapper.sh']
- Change CMD to point at /opt/data/start-hermes.sh, a new launcher
that starts per-profile gateways in background then the default
gateway in foreground (via s6-overlay's main-program model).
The old /usr/local/bin/run-multi-gateways.sh is no longer called.
- rebased custom commits on upstream v0.16.0
- 125 upstream commits since fork base (e490d91)
- includes dashboard, fleet, dark mode, deps consolidation
- our TS fixes preserved on top
- Install gosu in hermes image so run-multi-gateways.sh can drop
privileges when USER hermes is set at the end of the Dockerfile.
- Add openssh-client + ssh-keyscan to the openconcho-builder stage
so SSH host key verification passes during the first Gitea clone.
b9596 (Dec 2024) has known slot deadlock on first request causing
container freeze. b9890 includes:
- Slot selection consolidation (#24755)
- HIP fast-math support (#23862)
- Hundreds of stability and memory fixes
Compatible with ROCm 6.1 + gfx906 (same build flags).
The Dockerfile was switching to USER root for the final chown but never
switched back to USER hermes. This caused ALL container processes to run
as root (uid 0) instead of the hermes user (uid 10000).
The entrypoint's gosu privilege drop only caught the main exec chain,
leaving backgrounded subprocesses (dashboard PTY sessions, workers with
start_new_session=True) running as root — creating files owned by root
in ExoKortex and breaking Syncthing sync.
Adding USER hermes at the end ensures the container runs unprivileged
and ALL child processes inherit uid 10000 from the start.
- Rename ollama service to ollama-cpu (CPU-only for bge-m3 embeddings)
- Fix llama-cpp-hermes indented under networks instead of as top-level service
- Update hermes OLLAMA_HOST to point to ollama-cpu
Part of PR #54 GPU/ROCm refactor
- Update Dockerfile to clone from code.lazyworkhorse.net/Hermes/honcho.git
(uses build arg HONCHO_REPO, can be overridden at build time)
- Add config.toml volume mount from HoardingCow persistent path
- Use named volume honcho_data instead of host bind mount
- Declare honcho_data as external volume in top-level volumes section
- Honcho (FastAPI) et OpenConcho (React SPA) dans un seul Dockerfile multi-stage
- nginx proxy /v3/ /v2/ /health /openapi.json vers Honcho sur localhost:8000
- Supprime le service openconcho séparé et le dossier orphelin
- Routeur Traefik unique à honcho.lazyworkhorse.net (port 80 — nginx)
- Plus besoin d'exposer Honcho séparément (API accessible via nginx proxy)
- Add OpenViking service (knowledge graph) using official GHCR image
- Add Honcho stack (user modeling): API + PostgreSQL pgvector + Redis
- Add Holographic config to Hermes (local SQLite, no server needed)
- Hermes: install httpx for OpenViking client
- Hermes: auto-generate config.yaml + honcho.json on first boot
- All data 100% local, zero cloud dependencies
Line 1521 in gateway/config.py: if api_server_enabled or api_server_key:
The compose.yml sets API_SERVER_KEY=hermes_local_key, which was enough
to enable the API server even with API_SERVER_ENABLED=false.
Shell prefix didn't work with nohup+gosu chain - Docker compose
env var API_SERVER_ENABLED=true leaked through. Using 'env'
command guarantees the override is in the child process env.
- Use /opt/hermes/.venv/bin/hermes (full path) — not on PATH
before entrypoint.sh sources the venv
- Wrap with gosu hermes to avoid root guard in gateway run
- Add error check if hermes binary doesn't exist
Without this, is empty and entrypoint.sh runs bare 'hermes'
which defaults to interactive chat mode. With a non-TTY stdin
this exits immediately with prompt_toolkit's 'Input is not a
terminal' warning, causing a container restart loop.
The profile gateways (run-multi-gateways.sh) were unaffected
because the script passes 'gateway run' explicitly.
Without this, is empty and entrypoint.sh runs bare 'hermes'
which defaults to interactive chat mode. With a non-TTY stdin
this exits immediately with prompt_toolkit's 'Input is not a
terminal' warning, causing a container restart loop.
The profile gateways (run-multi-gateways.sh) were unaffected
because the script passes 'gateway run' explicitly.
- Add libolm-dev system dep (required by mautrix[encryption])
- Add mautrix[encryption] + openai pip packages to build
- These were previously installed inline at container startup and
persisted via the fragile venv volume mount (now removed)
- Add libolm-dev system dep (required by mautrix[encryption])
- Add mautrix[encryption] + openai pip packages to build
- These were previously installed inline at container startup and
persisted via the fragile venv volume mount (now removed)
The volume mount at /mnt/HoardingCow_docker_data/Hermes/venv overrides the
container's built .venv with an empty or stale host directory, causing
entrypoint.sh line 62 to fail on 'source .venv/bin/activate' (set -e).
The Docker image already builds a complete venv — no need to persist it.
The volume mount /mnt/HoardingCow_docker_data/Hermes/venv overrides the
container's built-in .venv with whatever is on the host. On a fresh start
or after a clean build, an empty/missing venv directory causes entrypoint.sh
line 62 (source .venv/bin/activate) to fail with set -e.
The Docker image already builds a complete venv — persisting it on the host
is unnecessary and fragile.
- Add run-multi-gateways.sh to /opt/data/hermes-tools/ that reads
HERMES_PROFILES env var and spawns one gateway per profile
- Update entrypoint to call the script before the main entrypoint
- Set HERMES_PROFILES=ashley,claire,finn,matt,paul (was default)
Closes PR #47 (feat/multi-profile-gateways). Builds on 548e15d's cleaner
env-var-driven approach — compose.yml stays declarative, logic in script.
The chown -R hermes:hermes was running as non-root user 'hermes'
since USER hermes was set earlier. The new upstream base image
(v0.12.0+) has tools/ owned by root, so the chown fails.
Previous base image happened to have tools/ owned by hermes,
making the chown a silent no-op.
- Replace rsync with cp -a (rsync unavailable in latest upstream base image)
- Remove npm run build step (fork's package.json has no build script)
- Remove himalaya-ro.sh from build context (deployed via install.sh)
- Add hermes to ai_net network for Traefik access
- Add Traefik labels routing hermes.lazyworkhorse.net to dashboard port 9119
update-alternatives --set fails because the base image only registers
iptables-legacy as an alternative. The iptables-nft binary (/usr/sbin/iptables-nft)
exists but isn't in the alternatives database. Direct ln -sf bypasses this.
In Alpine 3.18+, the 'iptables' package IS the nftables variant.
iptables-nft is not a separate package. The binary is already in
the base image — only need to flip update-alternatives.
- Switch FROM weejewel/wg-easy:latest (4yr old, Alpine 3.11) to
ghcr.io/wg-easy/wg-easy:latest (actively maintained, Alpine krypton)
- Use update-alternatives instead of raw ln -sf to flip iptables
from legacy to nftables backend
- Fix compose build context: ./vpn -> . (Dockerfile was at same level)
The weejewel/wg-easy image lacked iptables-nft package in Alpine 3.11.
The new official image has it available, we just flip the alternatives.
The old ln -sf approach was fragile across Alpine versions.
- Switch Dockerfile to clone from gortium/hermes-agent (Gitea fork)
- Add SSH agent forwarding for private repo clone at build time
- Set CHROME_EXECUTABLE for Playwright Chromium
- Remove patch_tts_tool.py (Piper patch now in fork source)
- Enable Gitea Actions in versioncontrol compose
- Use --preset 'ROCm 6' for HIP build step (enables enable_language(HIP))
- Remove /opt/rocm from PATH for CPU build to prevent check_language(HIP)
- Add CMAKE_PREFIX_PATH=/opt/rocm so find_package(hip) finds hip-config.cmake
- cmake --install --component HIP now works correctly with OLLAMA_RUNNER_DIR=rocm
gfx940/gfx1010/gfx1030/gfx1100 cause C++ narrowing errors in ollama's
mma.cuh with hipcc. Since we only have MI50 (gfx906) cards, compile
for gfx906 only. Reduces build time and avoids upstream code bugs.
CPU backends compiled with GCC (fixes AVX intrinsic errors from hipcc).
HIP backend compiled with hipcc (legacy mode skips enable_language(HIP)).
Go binary built with GCC for CGo linking.
This avoids both CMAKE_HIP_COMPILER rejection and CXX=hipcc CPU failures.
The old Dockerfile used the deprecated llama.cpp/ subdirectory approach
which doesn't exist in ollama v0.23.2. Now using the official CMake
presets (ROCm 6 preset) with AMDGPU_TARGETS including gfx906:xnack-.
- Add ollama/Dockerfile that builds ollama from source with AMDGPU_TARGETS=gfx906
- Uses ROCm 6.1 (rocm/dev-ubuntu-22.04:6.1.2-complete) for MI50 support
- Builds llama.cpp runner with HIPBLAS for gfx906 architecture
- Updates compose.yml to build from this Dockerfile instead of pulling ollama/ollama:latest
The migration from debian:stable-slim to nousresearch/hermes-agent:latest
dropped several packages that were previously installed. This restores:
- poppler-utils, imagemagick (PDF/image processing)
- texlive-latex-base, latex-extra, fonts-recommended, xetex, science
- qemu-user-static, binfmt-support (cross-compilation)
- emacs-nox (text editing)
These were added in PRs 3/5, 4/5, 5/5 and earlier commits of the
compose repo. The official image already has git, curl, ffmpeg,
python3, gcc, openssh, ripgrep, tini, docker-cli, etc.
- Patch now matches the current tts_tool.py (newer version ships in
nousresearch/hermes-agent:latest with different Edge fallback text)
- Adds dedicated elif provider == 'piper' block before else:
- Replaces else: fallback to use Piper instead of Edge
- Patches ALL copies (venv site-packages + /opt/hermes/tools/)
- Removes Edge TTS entirely as default/provider
The nousresearch/hermes-agent:latest image creates its venv
as root. Running 'uv pip install' as USER hermes fails with
Permission denied on the site-packages directory.
Fix: keep USER root while modifying the venv, then switch
back to USER hermes for runtime.
The nousresearch/hermes-agent:latest base image already has a
venv with hermes-agent installed at /opt/hermes/.venv/.
Running 'uv venv' on top of it either fails or wipes the
existing install.
Fix: activate the existing venv first, then pip install into it.
Starting from debian:stable-slim required re-installing everything
(Hermes source, Node.js, Playwright, etc.) which was redundant
and fragile. The official nousresearch/hermes-agent image already
has all that.
Now the Dockerfile:
- FROM nousresearch/hermes-agent:latest (has tts_tool.py, Playwright, etc.)
- Install Piper + voice model on top
- Patch tts_tool.py at build time (Edge fallback -> Piper)
- Runtime fallback in fix-permissions.sh for volume resilience
Cleaner, smaller Dockerfile, and the build-time patch can find
tts_tool.py because it's in the base image's venv.
The Dockerfile starts from debian:stable-slim, not from the official
Hermes image. Without installing hermes-agent from pip, there is no
tools/tts_tool.py in the image at build time, so the patch script
crashes with FileNotFoundError.
Adding hermes-agent to uv pip install gives us tts_tool.py in the
venv site-packages, so the COPY+RUN patch step works cleanly.
Also keep the runtime fallback in fix-permissions.sh for cases where
the volume's site-packages differ from the image.
The build-time COPY+RUN of patch_tts_tool.py failed because
the Dockerfile starts from debian:stable-slim and only copies
the ai/ build context — there's no tools/tts_tool.py in the
image at build time (Hermes is on the mounted data volume).
Move patching to fix-permissions.sh which runs at container
startup when the data volume is mounted, so tts_tool.py is
available via the venv site-packages.
Also make patch_tts_tool.py robust: searches multiple paths
for tts_tool.py, accepts path as argument, exits 0 instead
of 1 when file/pattern not found (build must not fail).
Commit 8e9a75f removed the COPY+RUN of patch_tts_tool.py
because the build context was thought to be insufficient.
The build context is ai/ which contains both the Dockerfile
and patch_tts_tool.py, so COPY works fine.
Without this step the tts_tool.py silently falls through
to Edge TTS as its default provider even when
config.yaml says provider: piper, because 'piper' is not
a recognized provider in the unpatched code. This caused
the female Edge TTS voice (AriaNeural) instead of the
configured Ryan High male voice.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
