Increase Stoatchat default RAM from 8192 to 10240 in ct/stoatchat.sh and json/stoatchat.json. Add cargo -j 2 to backend builds in ct/stoatchat.sh and install/stoatchat-install.sh to limit parallel jobs. Remove two environment variables (XYOPS_xysat_local and XYOPS_masters) from install/xyops-install.sh service definition to avoid hardcoded local settings.
Introduce new container templates, installers, and metadata for Stoatchat and xyOps. Adds ct scripts (ct/stoatchat.sh, ct/xyops.sh), full install scripts (install/stoatchat-install.sh, install/xyops-install.sh) that provision dependencies, build components, and create systemd services, plus app metadata JSON (json/stoatchat.json, json/xyops.json). Stoatchat installer handles Rust backend build, SolidJS frontend build, MinIO, RabbitMQ, MongoDB, nginx reverse proxy and multiple backend services (exposes on port 80). xyOps installer builds the Node app, sets up the xySat satellite, service unit, and uses port 5522 for the web UI. Default resource recommendations and notes are included in the JSON metadata.
Modernize and simplify VM installer and lobehub installation flows.
Key changes:
- install/lobehub-install.sh: consolidated apt invocation, replaced manual ParadeDB .deb download with fetch_and_deploy_gh_release helper, added postgresql pg_search preload configuration and restart, moved pnpm installation into setup_nodejs via NODE_MODULE, and adjusted build env handling.
- vm/almalinux-10-vm.sh: major refactor to source shared functions from COMMUNITY_SCRIPTS_URL, add load_functions, centralize cloud-init handling (configure_cloudinit_ssh_keys / setup_cloud_init), replace many custom UI/helper functions with standardized helpers and exit_script, update traps and error handling, simplify prompts/defaults, use $STD for apt operations, and streamline image customization and VM creation flow.
- Added vm/headers/almalinux-10-vm containing the VM header art and title.
These changes centralize common logic, improve cloud-init integration, reduce duplicated code, and make maintenance easier.
The previous approach used a /usr/bin/hermes shim to proxy commands from root
to the hermes user, and a hand-crafted system-level systemd unit for the
gateway. This worked for the default profile but broke down for named profiles:
- hermes profile create <name> generates an alias script in
~/.local/bin/<name> that calls hermes with -p <name>. These aliases live
in the hermes user's PATH, not root's, so root could not invoke them.
- Maintaining parity would require per-profile shims, a watcher daemon to
create/remove them, and system-unit mirrors for each profile gateway — all
of which would need to stay in sync with hermes internals across updates.
New approach — work with hermes, not around it:
- loginctl enable-linger hermes: ensures the hermes user's systemd session
starts at boot and persists without login. All user-unit gateways (default
and per-profile) now survive reboots automatically.
- Gateway service management delegated entirely to hermes: 'hermes gateway
install' / 'hermes setup' create and enable the user unit natively.
The install script no longer pre-installs the gateway; hermes prompts the
user to do so at the end of 'hermes setup'.
- hermes-dashboard.service remains a system unit (no native install command
exists for it). Its After= no longer references hermes-gateway.service
since there is no system-unit gateway to depend on.
- /usr/bin/hermes shim removed. Root is guided to 'su - hermes' via a two-
line /etc/profile.d/hermes-hint.sh message on login, with a one-liner to
make the switch automatic. Once logged in as hermes, all hermes commands,
profile aliases, and gateway management work natively.
- update_script simplified: only hermes-dashboard (our unit) is stopped and
restarted. hermes update --yes handles gateway service lifecycle itself.
The response_store.db and session JSON files under ~/.hermes/ are stored
in plaintext and readable by any process with filesystem access. Set
~/.hermes to 0700 (owner-only) and ~/home/hermes to 0750 to restrict
access to conversation history, credentials, and session data.
Ref: https://github.com/NousResearch/hermes-agent/issues/7486
Hermes strips sensitive env vars from tool subprocesses, but child
processes can recover them by reading /proc/<parent_pid>/environ. Add
ProtectProc=invisible and ProcSubset=pid to both systemd services to
hide other processes' /proc entries and limit /proc to the service's
own PID namespace.
Ref: https://github.com/NousResearch/hermes-agent/issues/4427
The Anthropic OAuth helper writes credential files with the process
default umask, resulting in 0644 permissions on sensitive files. Set
UMask=0077 on both hermes-gateway and hermes-dashboard services so all
files created at runtime are owner-only (0600/0700).
Ref: https://github.com/NousResearch/hermes-agent/issues/11003
HERMES_REDACT_SECRETS is off by default, exposing API keys in chat output
and session JSON files. Add HERMES_REDACT_SECRETS=true to the .env file
created by the installer.
Ref: https://github.com/NousResearch/hermes-agent/issues/17691
Adds container scripts for Hermes Agent (Nous Research), a self-improving
AI agent with LLM provider integration, terminal execution, web browsing,
and multi-platform messaging support.
Files:
- ct/hermes-agent.sh
- install/hermes-agent-install.sh
- json/hermes-agent.json
- ct/headers/hermes-agent
Deviations from standard patterns (justified):
1. Uses upstream installer (curl-pipe) instead of fetch_and_deploy_gh_release:
Hermes is a uv-managed Python application with complex dependency
resolution, virtualenv management, and binary placement—not a single
binary or tarball from GitHub Releases.
2. Dedicated 'hermes' service user (not running as root):
The agent executes arbitrary terminal commands on behalf of the user.
Running as root would give the AI unrestricted system access. This
follows the protonmail-bridge service-user pattern for isolation.
3. Dashboard (port 9119) bound to localhost only, requiring SSH tunnel:
The web UI provides admin access to an AI that can execute commands.
SSH tunnel provides an authentication/authorization boundary.
4. /usr/bin/hermes shim script:
The hermes CLI validates cwd permissions; running 'hermes' as root
from /root fails. The shim cd's to /home/hermes and exec's as the
hermes user via runuser.
5. setsid --wait wrapping of upstream installer:
The upstream installer probes /dev/tty for interactive prompts even
with --skip-setup; setsid detaches the controlling terminal.
