The JSON metadata had type "addon" and script path
"/tools/addon/garmin-grafana.sh", but the actual script has always
lived at ct/garmin-grafana.sh. This caused the website to generate an
installer URL that returns 404.
Changes:
- type: "addon" -> "ct"
- script: "/tools/addon/garmin-grafana.sh" -> "ct/garmin-grafana.sh"
- Move config_path to top level (matching ct JSON convention)
- Fill in resource values from ct/garmin-grafana.sh (cpu: 2, ram: 2048,
hdd: 8, os: Debian, version: 13)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- ct/etherpad.sh + install/etherpad-install.sh: use ether/etherpad
(canonical name; ether/etherpad-lite still redirects but the new
name is preferred)
- install/etherpad-install.sh: switch dbType from dev-only "dirty"
to sqlite at /var/lib/etherpad/etherpad.db on first config seed;
matches the same default we land on across the snap, .deb, and
Home Assistant add-on packagings
- json/etherpad.json: refresh note to reflect the sqlite default
and document postgres/mysql as alternatives via dbType/dbSettings
Add container templates (ct/) and install scripts (install/) plus metadata JSON entries for BunkerM, Colanode, Edit-Mind, and ExcaliDash. Each app includes an LXC template script with update routines, a corresponding installer that provisions dependencies, builds the app, configures services (systemd/nginx/supervisor), and example default environment/config. JSON metadata files register interface ports, recommended resources, documentation/website links, and notes for each app.
- Drop 'WARNING: '/'Warning: ' prefixes from note texts — the type:warning
field already communicates severity (per CrazyWolf13 review feedback)
- Set config_path to /home/hermes/.hermes/.env (was directory path)
Adds third-party script warning with user confirmation before running
the upstream installer (install) and updater (update), matching the
kasm/pihole pattern. Removes redundant binary existence check per
reviewer feedback. Adds corresponding JSON warning note.
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.
- 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
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.
