Hermes Agent runs on your own hardware, writes new skills while you sleep, and never stops calling APIs. Give every provider and tool request one predictable exit: two fixed static EU IPs.
# egress for every outbound call
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
OPENROUTER_API_KEY=sk-or-...
ANTHROPIC_API_KEY=sk-ant-...
A managed agent platform worries about its own network. Hermes Agent on your VPS or homelab inherits your address situation, and an agent that learns new integrations on its own makes that situation worse fast.
Hermes runs wherever you installed it: a homelab behind a residential line that gets a new IP on reconnect, or a cloud VM whose exit changes after a rebuild. The agent's identity to every external service shifts underneath it, and the skill that worked yesterday starts returning 403s.
You sensibly restricted the OPENROUTER_API_KEY or ANTHROPIC_API_KEY in ~/.hermes/.env to a specific allowlist. That protection only holds while the host's address stays inside it, which is precisely what a self-hosted box cannot promise.
Hermes's learning loop turns experience into skills and refines them during use. Every generated skill can start calling an API you have never reviewed. You cannot pre-register destinations you do not know yet, but you can pin the source: one address pair that every skill, present and future, exits through.
Between the messaging gateway for Telegram and Discord, the web UI, and cron-style schedules, Hermes keeps working at 3am. A broken egress discovered hours later means a half-finished research thread and a stack of failed tool calls, not a convenient retry.
Hermes Agent
skills, providers, gateway
HTTPS Proxy
(Static EU IP)
LLM providers + tool APIs
OpenRouter, Anthropic, and whatever it learns
Model calls, freshly generated skills, gateway traffic: everything Hermes sends outward crosses the same two European addresses. Whatever the loop dreams up next, the allowlist entry protecting it never goes stale.
~/.hermes/.env next to the keys you already keep there; standard tooling honours HTTPS_PROXY without code changes.A proxy for self-hosted workloads that must look like one stable machine to the outside world, run by an EU company, not a scraping network.
Hermes already keeps its secrets in ~/.hermes/.env. The proxy lives in the same file, the same systemd unit, the same mental model.
Your agent's prompts and tool traffic leave from EU data centres, which keeps the data-path description simple under GDPR and the EU AI Act's transparency expectations.
People who took the self-hosting deal: full control on your side, full responsibility for the network path.
Hermes on a home server or mini PC behind a dynamic residential address, where the router handing out a new IP quietly breaks every allowlist the agent relies on.
Agents on rented cloud instances that get rebuilt, migrated, or re-provisioned, dragging their egress address along with every change.
Operators running the Telegram or Discord messaging gateway so the agent answers around the clock, where downtime is measured in missed conversations.
Self-hosters who lock every API key to an allowlist and want their autonomous agent to respect the same discipline they apply to their own credentials.
Hermes keeps its environment in ~/.hermes/.env. The proxy belongs there too.
Add HTTPS_PROXY to the same file that already holds OPENROUTER_API_KEY and ANTHROPIC_API_KEY. Processes that inherit the environment route their outbound calls through your fixed pair from that moment on.
# ~/.hermes/.env
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
OPENROUTER_API_KEY=sk-or-...
ANTHROPIC_API_KEY=sk-ant-...A skill the learning loop created might do nothing more exotic than an ordinary HTTP call. Standard tooling honours the variable on its own, as with Python's requests.
import requests
resp = requests.post(
"https://openrouter.ai/api/v1/chat/completions",
headers={"Authorization": f"Bearer {os.environ['OPENROUTER_API_KEY']}"},
json={"model": "...", "messages": messages},
timeout=60,
)
# HTTPS_PROXY from the environment is honoured automaticallyFor an always-on install, export the variable where the agent starts so restarts and reboots cannot lose it. Credentials stay in the env file, never in the unit.
# systemd unit for an always-on agent
[Service]
EnvironmentFile=/home/you/.hermes/.env
ExecStart=/usr/local/bin/hermes start
Restart=on-failureRegister the pair everywhere it matters
The account hands you two fixed European addresses that relieve each other on demand. Add both to the allowlists on your provider keys and to any firewall rules guarding the agent's tools: whichever node carries the traffic, the origin the services observe never wanders off that short list.
📖 Complete Documentation: For detailed examples, error handling, and advanced configurations, see the all guides.
An agent that acts in your name sends prompts, tool results, and sometimes personal data outward. Where that traffic exits is part of its compliance story.
When skills touch personal data, egress from EU data centres keeps the processing location easy to state in your records instead of a question mark.
The proxy passes the encrypted provider session along unread. Keys, prompts, and tool payloads stay sealed between your agent and the API they were addressed to.
Two European IPs covering for each other, so the address your agent presents stays put across reconnects and rebuilds.
Drop HTTPS_PROXY beside the provider keys and let standard tooling do the rest. No agent fork, no patched SDK.
Skills the loop invents tomorrow inherit the same exit, so new integrations are covered before they exist.
Egress inside the Union for an AI workload, matching where the EU AI Act expects the operation to be accountable.
Failover between the two nodes is part of the pair, keeping gateway sessions and scheduled jobs alive through maintenance.
Starting from €19/month. Flexible plans for every scale. Cancel anytime.
One env var in ~/.hermes/.env and every call your agent makes, today or after a hundred learned skills, leaves through the same two EU IPs.
Starting from €19/month. Flexible plans for every scale. Cancel anytime.
Hermes keeps its configuration in ~/.hermes/.env and runs ordinary outbound HTTPS to its providers and tools, which is exactly the pattern a proxy variable fits. Export HTTPS_PROXY in the agent's environment (the env file, or a systemd EnvironmentFile) and standard HTTP tooling honours it without touching the agent itself.
That is the strongest argument for pinning the source rather than the destinations. The learning loop can draft a skill that talks to a service you have never configured, and you cannot allowlist what you cannot predict. With the proxy in the environment, any new skill inherits the same fixed exit automatically, so your provider key restrictions and firewall rules apply to everything the agent does, present and future.
Yes. Both of your account's European addresses are stable, so you can list the pair on an OpenRouter or Anthropic key allowlist and leave it there. The two nodes back each other up, and because the addresses themselves never change, failover never takes the source outside the key's restrictions.
Happy to talk through your Hermes setup, your provider keys, and how a fixed EU pair keeps an autonomous agent inside your security rules.
Contact Our Founders →