./run.shThe first run will automatically build the Docker image and launch the TUI interactive interface. Make sure Docker is running and your SSH key is set up (see Prerequisites below). Hermes Gate launches a temporary local client, while the long-lived work remains in the remote tmux / Hermes session.
After entering, select "➕ Add Server..." and input:
username@ip_address e.g. [email protected]
username@hostname e.g. admin@myserver
username@hostname:port e.g. [email protected]:2222
- Docker installed and running
- SSH key in local
~/.sshdirectory, added to the target server'sauthorized_keys - Remote server has
tmuxandhermesinstalled - Remote command execution currently assumes a bash-based login-shell environment
tmuxandhermesmust be available in the remote login-shell PATH used by SSH- First-time SSH trust for a new host is currently handled with
StrictHostKeyChecking=accept-new
./run.sh # Start and enter container (skips build if already built)
./run.sh rebuild # Force rebuild then start
./run.sh stop # Stop and remove the containerMultiple terminals can run ./run.sh simultaneously — each gets an independent TUI session. The container auto-stops when the last session exits.
Python code under hermes_gate/ is mounted via a Docker volume. After modification, no rebuild is needed — just restart the container.
The following files require a rebuild (./run.sh rebuild) after changes:
pyproject.tomlrequirements.txtentrypoint.shDockerfile
docker compose down # Stop and remove container
docker compose logs hermes-gate # View logs
docker exec -it hermes-gate bash # Enter container shell- Make sure you have SSH keys in your local
~/.sshdirectory before starting (any key type:id_rsa,id_ed25519, customIdentityFile, or SSH agent) - The container stops automatically when you exit the TUI; just run
./run.shagain next time - Attached interaction is primarily native tmux / Hermes behavior rather than a persistent Gate-controlled viewer layer
- Current remote session checks and launch flow assume bash-based login-shell behavior on the target host
- SSH first-connection trust currently uses
accept-new, while later host-key changes are still rejected by SSH