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.
Call stop_spinner in cleanup() to ensure any active spinner is stopped on exit. Consolidate duplicated qm set branches in ubuntu2604-vm.sh into a single invocation to reduce code duplication and simplify VM disk/serial configuration. Remove the explicit ide2 cloudinit device and redundant cloud-init status messages; setup_cloud_init() is still invoked when USE_CLOUD_INIT is enabled, keeping cloud-init configuration centralized.
Introduce optional Cloud-Init integration and better machine type handling for VMs. Changes include: loading cloud-init helpers lazily (load_cloud_init_functions), interactive cloud-init prompt/configuration (vm_prompt_cloud_init) and SSH key handling, a cloud icon for UI, and vm_machine_type_label for readable machine type display. Default machine type switched to q35 and displays the label in prompts and summaries. VM creation logic now conditionally attaches the cloudinit drive (ide2) and runs setup_cloud_init when enabled; otherwise it creates the VM without the cloudinit device. Post-install messaging now either shows cloud-init details or a guidance message about manual guest filesystem expansion. Minor UI/output adjustments and defaults updated accordingly.
Introduce a shared vm-core loader and refactor the Ubuntu 26.04 VM script to use reusable helper functions. misc/vm-core.func: add COMMUNITY_SCRIPTS_URL default and load_api_functions to dynamically source API helpers, then call load_api_functions from load_functions. vm/ubuntu2604-vm.sh: switch to sourcing the shared vm-core via COMMUNITY_SCRIPTS_URL, replace many inline UI and utility functions with generic vm_* helpers (vm_confirm_new_vm, vm_prompt_*, vm_select_storage, vm_define_disk_references, set_description, etc.), modernize quoting and pushd usage, simplify disk import/resizing logic, and set START_VM default to yes. Also update repository URLs to ProxmoxVED and adjust some behavior (machine type handling, storage/disk references). Overall this centralizes common functionality, reduces duplication, and prepares scripts to use the shared core utilities.
Introduce interactive whiptail-based helpers and robust error handling for VM creation.
- Add error_handler() to report failures (calls post_update_to_api if available), print contextual error info, and call cleanup_vmid.
- Ensure TEMP_DIR is removed in cleanup().
- Replace brittle pve_check with version parsing that supports Proxmox VE 8.0–8.9 and 9.0–9.1 (exits with code 105 on unsupported versions).
- Add ssh_check() to warn users running the script over SSH.
- Add sanitize_vm_hostname() and a suite of vm_* helper functions to prompt and validate interactive settings via whiptail: vm_confirm_new_vm, vm_choose_settings_mode, vm_prompt_vmid, vm_prompt_machine_type, vm_apply_machine_type, vm_prompt_disk_size, vm_prompt_disk_cache, vm_prompt_hostname, vm_prompt_cpu_model, vm_prompt_cpu_cores, vm_prompt_ram, vm_prompt_bridge, vm_prompt_mac, vm_prompt_vlan, vm_prompt_mtu, vm_prompt_start_vm.
- Add storage helpers: vm_select_storage, vm_apply_storage_layout, vm_define_disk_references to detect storage pools, set formats/extensions and prepare disk refs.
- Use APP/NSAPP for description title by introducing local description_title in set_description().
These changes centralize validation and interactive flow, improve UX, and harden error reporting and cleanup.
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.
- default_credentials: username null/null (no SSH login for hermes
service account; access is via root like all PVE Helper Scripts)
- Update setup note to reference root instead of hermes user
- Update dashboard tunnel note to use root and -fNL flags
The hermes service account has no password or SSH keys and cannot
be used to log in. Access is via root (standard PVE Helper Scripts
pattern). Also add -fN flags to the dashboard tunnel command so it
runs in the background without opening a shell session.
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.
