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.
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.
