Hermes AI Agent + n8n AI Agents Browse on AWS

Security and data¶

What the image does, what it deliberately does not do, and how each claim is checked.

The image checks several of these claims itself while it is being built, and the build stops, so no image is created if any of them fails. Every image we build is then launched on two fresh instances and checked again. Both lists are at the end of this page.

The short version¶

Hermes and n8n run on your instance and talk to each other only inside it. You open n8n in your browser over HTTPS, and nobody reaches it without your instance's ID at first and your n8n account after that. The Hermes API and Hermes's own connections to n8n are never exposed to the internet, and every key the two use with each other is generated on your instance's first boot, unique to it.

Your data¶

Workflows, credentials, n8n accounts and history are stored on the instance's disk, in /home/ubuntu/.n8n. n8n encrypts saved credentials with a key unique to your instance.
Hermes's settings, memory and sessions are stored in /home/ubuntu/.hermes.
Your conversations with Hermes go to the model provider you chose, under that provider's terms, and to any messaging app you connected.
Workflows reach whatever services you build them to reach.
Nothing is sent to Software Sushi. The image has no accounts, no licence check and no tracking of its own, and n8n's usage statistics are turned off.

What is reachable¶

Service	Listens on	Reachable from
The n8n dashboard (Caddy)	ports 443 and 80	Everyone, over HTTPS; port 80 only sends visitors on to HTTPS. See the dashboard
n8n itself	`127.0.0.1:5678`	The instance only. The dashboard passes requests on to it
The setup gate	`127.0.0.1:5690`	The instance only. The dashboard asks it about each request
Hermes API (used by n8n)	`127.0.0.1:8642`	The instance only. Never served by the dashboard
SSH	port 22	The addresses you allow in the security group

n8n runs in a container on the instance's own network and listens only on 127.0.0.1, so no security-group or Docker rule can expose it directly. The only way in from outside is the dashboard, and sudo hermes-n8n web off closes it.

The n8n dashboard¶

HTTPS, with a trusted certificate. Let's Encrypt issues it for your instance's own IP address at boot, and it renews itself every six days. Ports 80 and 443 stay open to every address so Let's Encrypt can check the instance. No certificate, private key or Let's Encrypt account ships in the image: each instance gets its own.
The instance ID guards first-time setup. n8n gives its owner account to whoever sets it up first. Until that account exists, every request needs your instance's ID first. Wrong IDs are refused after a short pause and logged, and ten from one address lock it out for 15 minutes. The ID is checked against the instance's own metadata, and a correct one sets a browser cookie that is sent over HTTPS only.
n8n's own sign-in after that. Once the owner account exists, the instance-ID page steps aside, and n8n's accounts protect the editor, with n8n's secure cookies. Turning on two-factor authentication in n8n is recommended.
Never served: Hermes's connections to n8n (its tools and the workflow builder) answer only inside the instance, and the Hermes API is not on the dashboard at all.
Blocked by default: n8n's public REST API (/api/v1). Open it with sudo hermes-n8n public-api on if you need it.
Public by design: webhooks and forms of workflows you publish, once the owner account exists, and n8n's /healthz health check, which reports only whether n8n is running.
No remote control of the web server. Caddy's admin API is switched off, so nothing on the instance, including Hermes's own terminal tool, can change what the dashboard serves. Changes go through hermes-n8n as root.

Host protections¶

The image keeps a host firewall, as defence in depth behind your security group:

UFW denies all inbound traffic except SSH and the dashboard's ports 80 and 443, and allows outbound traffic.
fail2ban blocks addresses that repeatedly fail to sign in over SSH.
SSH accepts keys only: PasswordAuthentication no, PermitRootLogin prohibit-password, MaxAuthTries 3, no X11 forwarding.
IMDSv2 is required for the instance metadata service.
Network settings turn off ICMP redirects and IP forwarding.

Two places to open a port

Because of UFW, opening a port in the security group is not enough on its own. Nothing in this guide needs another inbound port. hermes-n8n web off closes 80 and 443 in UFW; remove them from the security group yourself.

Keys and secrets¶

Each instance generates its own keys on first boot, from OpenSSL's cryptographic random generator:

Key	Used for	Stored
n8n encryption key	Encrypting your saved n8n credentials	`/etc/hermes-n8n/secrets` and `/etc/n8n/n8n.env`, root only. n8n also keeps a copy in `/home/ubuntu/.n8n`
Hermes API key	n8n calling Hermes	`/etc/hermes-n8n`, and in Hermes's `.env`
Hermes tools token	Hermes calling the Hermes tools workflow	`/etc/hermes-n8n`, and in Hermes's `config.yaml`
Workflow builder token	Hermes building workflows	Issued by n8n to you. Saved in `/etc/hermes-n8n` and Hermes's `config.yaml` by connect-builder

The full secrets file in /etc/hermes-n8n is readable by root only. The keys Hermes needs to repair its own connections are also in a copy that ubuntu, the account Hermes runs as, can read. Hermes's .env and config.yaml are readable only by ubuntu. Replace the generated keys at any time with sudo hermes-n8n rotate-secrets.

What Hermes is allowed to do in n8n¶

Run the tools you attach to the Hermes tools workflow, without changing them.
Once you connect the workflow builder: create workflows, edit the ones it created, test, publish and archive them.
Edit a workflow you made yourself only after you switch on Available in MCP for it.
Never permanently delete a workflow, an n8n Agent or a data table column. Those tools are hidden from Hermes.

Patching¶

Every build runs a full apt-get dist-upgrade before installing anything, so the image ships with the security updates available on its build date.
unattended-upgrades stays on, so a running instance keeps receiving security updates. Automatic reboots stay off.
telnet clients are removed.
n8n moves to newer tested versions with sudo hermes-n8n upgrade.

What ships in the image¶

Ubuntu 24.04 LTS, fully updated at build time
Hermes Agent, installed from a pinned upstream release and checked against its exact source commit, with the Telegram, Discord, Slack and Anthropic extras
Docker Engine and n8n, pinned to an exact image digest that is checked when the image is built and never downloaded again at run time
The hermes-n8n command and the two starter workflows, Ask Hermes and Hermes tools
The dashboard's HTTPS layer (Caddy, and the tool that gets and renews its certificate), installed from a pinned release checked against its SHA-256 checksum
/etc/hermes-agent-release, /etc/hermes-agent-commit, /etc/n8n-release and /etc/n8n-digest, recording exactly what was installed

What does not ship in the image¶

No keys or secrets of any kind: they are generated on your instance's first boot
No TLS certificate, private key or Let's Encrypt account: each instance gets its own when it starts
No n8n data, accounts or settings, and no saved random-number state, so no two instances share a secret
No SSH keys: authorized_keys files are removed before the image is captured
No model provider keys or messaging tokens: you add your own
No telemetry of ours

Checked on every build¶

Unless all of these checks pass, no image is created, and the build terminates:

Hermes is the requested release, at its exact upstream commit
The n8n image matches its pinned digest, reports the expected version, and runs as the expected user
Docker's signing key matches its published fingerprint
The dashboard's HTTPS release matches its pinned checksum, and Caddy accepts the dashboard's routes, with the public API both blocked and open
n8n's settings file, its data folder and the first-boot secrets are absent from the image
The release markers in the image match the requested versions

Checked on a real first boot¶

Every image we build is launched on two fresh instances and checked before it can be released:

First boot finishes, and the recorded versions match the image
Every secret and settings file has the expected owner and permissions
Every key is 64 hexadecimal characters, the keys differ from each other, and the second instance's keys differ from the first's
n8n, the setup gate and the Hermes API listen on 127.0.0.1 only, and UFW denies inbound traffic except SSH, 80 and 443
From outside, each instance serves HTTPS with a publicly trusted Let's Encrypt certificate for its own IP, and http:// sends you on to https://
Through the dashboard, Hermes's connections and n8n's public API answer not found, n8n's owner setup is refused without the instance ID, a wrong ID is refused and logged, and the right one opens setup with a HTTPS-only cookie
Caddy's admin API is off, and Caddy runs as its own user
hermes-n8n web off closes the dashboard and its ports while Hermes keeps working, and web on brings it back
The Hermes API refuses requests without its key and accepts the instance's key, and Hermes connects to its n8n tools
Removed connection settings come back on the next restart, while a connection switched off stays off
hermes-n8n doctor repairs a broken connection
The workflow builder reports not connected until you connect it, and refuses an invalid token
No key appears in any log on the instance
The instance requires IMDSv2

Reporting a vulnerability¶

Email info@softwaresushi.com with the AMI ID, the region, and what you found. Please do not open a public issue. Reports reach the same inbox as everything else, and we reply within two business days.

Last updated October 27, 2026 · Suggest an improvement