{"slug": "how-i-deployed-hermes-agent-on-aws", "title": "How I Deployed Hermes Agent on AWS", "summary": "Nous Research deployed its open-source Hermes Agent on AWS using a zero-inbound-security-group architecture, relying on AWS Systems Manager Session Manager for admin access and Telegram long-polling for bot communication. The setup runs on a single m7g.medium EC2 instance with persistent agent data on EFS, costing approximately $35 per month.", "body_md": "My EC2 instance has a public IP address. It has zero inbound firewall rules. And yet I can reach my AI agent from my phone on Telegram, pull up a full web workspace in my browser, and run shell commands on it — all without opening a single port, without a VPN, and without SSH.\n\nThe latest version also splits storage deliberately: persistent agent data stays on EFS, while the Hermes install and Python venv moved to the root EBS volume. That change keeps `pip install`\n\n/ `hermes update`\n\nI/O off EFS and brings always-on infra to a highly predictable **~$35/mo**.\n\nThat's the setup this post is about.\n\n[Hermes Agent](https://hermes-agent.nousresearch.com/docs) is an open-source AI agent from Nous Research. It's not a chatbot wrapper. It has persistent memory, skills, a file system, a sandboxed terminal backend, and a full web workspace UI. You point it at a model provider and it runs as a daemon — `hermes-gateway`\n\n— serving an OpenAI-compatible API.\n\nThe web workspace looks like a proper IDE: chat panel, file browser, terminal, job queue. The Telegram integration is a long-polling bot that connects to the same gateway — no extra server, no webhook, no public URL.\n\nI wanted this running on AWS, backed by Amazon Bedrock (no API keys to rotate, IAM role handles auth), with my agent's memory surviving instance replacements.\n\n```\nYour phone (Telegram)\n  └─► Telegram servers ──► hermes-gateway long-poll (outbound HTTPS only)\n\nYour laptop (browser)\n  └─► aws ssm start-session ──► SSM port-forward :3000\n                                   └─► hermes-workspace (loopback only)\n\nEC2 m7g.medium · public subnet · ZERO inbound SG · dynamic public IP\n  │\n  ├─ hermes-gateway   :8642  (127.0.0.1 only)\n  │     ├─ Bedrock inference via IAM role (no API keys)\n  │     ├─ Telegram long-poll (outbound HTTPS)\n  │     └─ OpenAI-compatible API\n  │\n  ├─ hermes-dashboard :9119  (127.0.0.1 only)\n  └─ hermes-workspace :3000  (127.0.0.1 only)\n  │\n  ├── EFS /mnt/efs/hermes  (RETAIN · encrypted · uid=10000 access point)\n  │     .env · config.yaml · sessions · skills · SOUL.md · logs · state DBs\n  │     ↑ persistent agent data — survives instance replacement\n  │\n  ├── EBS root volume\n  │     /opt/hermes-agent      ← hermes venv (pip I/O stays off EFS)\n  │     /opt/hermes-workspace  ← workspace UI\n  │\n  └── Secrets Manager (hermes/runtime)\n        API_SERVER_KEY · TELEGRAM_BOT_TOKEN · TELEGRAM_ALLOWED_USERS\n```\n\nThree CDK stacks, deployed in order:\n\n| Stack | What it provisions |\n|---|---|\n`HermesNetworkStack` |\nVPC (1 AZ), public subnet, IGW, S3 gateway endpoint, security groups |\n`HermesStorageStack` |\nEFS (RETAIN, encrypted, uid=10000 access point), Secrets Manager |\n`HermesComputeStack` |\nEC2 (m7g.medium), IAM (Bedrock-scoped), bootstrap user-data, systemd units |\n\nThe instinct when deploying anything on AWS is to reach for a private subnet, a NAT Gateway, and VPC interface endpoints. That's the enterprise posture. It's also ~$88/mo in endpoint costs alone before your instance even starts.\n\nFor a personal deployment the actual security boundary is not the subnet type — it's what's listening on the instance.\n\nAll three services bind to `127.0.0.1`\n\nonly. The Security Group has zero inbound rules. The public IP on the instance rejects every connection attempt because there is nothing behind it.\n\n```\n# network_stack.py — the entire inbound surface of the instance\nself.instance_security_group = ec2.SecurityGroup(\n    self,\n    \"InstanceSg\",\n    vpc=self.vpc,\n    description=\"Hermes EC2 - zero inbound; egress via IGW. Admin via SSM.\",\n    allow_all_outbound=True,\n)\n# No add_ingress_rule calls. Ever.\n```\n\nAdmin access is via AWS Systems Manager Session Manager — outbound HTTPS to the SSM service endpoint, no inbound port required. SSM also handles port-forwarding, which is how the workspace reaches your browser.\n\nTelegram uses long-polling. The gateway opens an outbound connection to Telegram's servers and holds it. Telegram pushes messages down that connection. Again: zero inbound.\n\nThe result: there is no attack surface on the public IP. Shodan can scan it all day.\n\nPersistent **agent data** — `SOUL.md`\n\n, skills, session history, state DBs, the `.env`\n\nwith all secrets, the `config.yaml`\n\n— lives on an EFS volume mounted at `/mnt/efs/hermes`\n\n. The hermes **binary and venv** live on the root EBS volume at `/opt/hermes-agent`\n\ninstead.\n\nWhy split? EFS Elastic Throughput charges per GB accessed. Moving the venv to EBS removes that install/update path from EFS, keeping steady-state EFS I/O costs around **~$1/mo** instead of paying for heavy throughput during dependency updates. See `docs/STORAGE.md`\n\nfor the full reference.\n\nThe EFS has `RemovalPolicy.RETAIN`\n\n. The access point locks the path to UID 10000. Automatic backups are on with a 35-day window.\n\n```\n# storage_stack.py — the persistence layer\nself.file_system = efs.FileSystem(\n    self,\n    \"HermesEfs\",\n    vpc=vpc,\n    encrypted=True,\n    removal_policy=RemovalPolicy.RETAIN,       # survives cdk destroy\n    lifecycle_policy=efs.LifecyclePolicy.AFTER_30_DAYS,\n    throughput_mode=efs.ThroughputMode.ELASTIC,\n    enable_automatic_backups=True,\n)\n\nself.access_point = self.file_system.add_access_point(\n    \"HermesAccessPointUid10000\",\n    path=\"/hermes\",\n    create_acl=efs.Acl(owner_uid=\"10000\", owner_gid=\"10000\", permissions=\"0750\"),\n    posix_user=efs.PosixUser(uid=\"10000\", gid=\"10000\"),\n)\n```\n\nWhat this means in practice: if the EC2 instance develops a problem, you run `cdk deploy`\n\nand get a fresh one. The new instance mounts the same EFS, reads the same `.env`\n\n, reinstalls the venv to EBS via user-data, and all three systemd services start with the agent's full memory intact. No manual data migration, no re-configuration.\n\nThe EC2 root EBS is flagged `delete_on_termination=True`\n\n. Agent *data* is on EFS (RETAIN); install artifacts on EBS are recreated automatically on each deploy.\n\nHermes connects to Bedrock via the [Hermes Bedrock guide](https://hermes-agent.nousresearch.com/docs/guides/aws-bedrock). The EC2 instance has an IAM role scoped to `bedrock:InvokeModel`\n\n, `bedrock:Converse`\n\n, and the streaming variants — on specific inference-profile and foundation-model ARNs only.\n\nNo API keys anywhere. No key rotation. If the instance is compromised, the blast radius is bounded to Bedrock inference on two specific models. The role cannot touch S3, DynamoDB, other accounts, or anything else.\n\nTwo models run in this stack:\n\n| Model | Role | Why |\n|---|---|---|\n`us.anthropic.claude-sonnet-4-6` |\nPrimary (all main agent tasks) | Best reasoning for the price on Bedrock |\n`us.amazon.nova-lite-v1:0` |\nAuxiliary (5 background slots) | ~85× cheaper than Sonnet for web extraction, vision, summarisation |\n\nThe `us.`\n\nprefix is the cross-region inference profile — Bedrock routes to `us-east-1`\n\n, `us-east-2`\n\n, or `us-west-2`\n\nautomatically for throughput. You enable both models once in the [Bedrock Model Access console](https://us-east-1.console.aws.amazon.com/bedrock/home#/modelaccess) and never touch it again.\n\n| Component | Detail | ≈ Monthly |\n|---|---|---|\nEC2 `m7g.medium` (Graviton, 2 vCPU / 4 GiB) |\n730 hrs × $0.0404/hr | ~$29.50 |\n| EBS gp3 root (30 GiB, encrypted) | venv + workspace on EBS | $2.40 |\n| EFS Standard (~64 MB agent data) | $0.30/GiB-mo storage | ~$0.02 |\n| EFS Elastic throughput I/O | venv/deps on EBS; steady-state session/state access only | ~$1/mo |\n| EFS automatic backups | ~$0.05/GiB-mo | ~$0.50 |\n| Secrets Manager | 1 secret × $0.40 | $0.40 |\n| CloudWatch Logs + metrics | ingestion + custom metrics | ~$2 |\n| NAT Gateway / VPC endpoints | none |\n$0 |\nInfra total (always-on) |\n≈ $35/mo |\n\nNo NAT Gateway. No interface VPC endpoints. The EC2 routes outbound directly through the Internet Gateway. That single architectural decision — public subnet, zero-inbound SG instead of private subnet + NAT — is **58% cheaper** than the equivalent private-subnet setup with six VPC endpoints.\n\n```\naws ec2 stop-instances --instance-ids <InstanceId> --region us-east-1\n```\n\nEC2 compute billing stops immediately, and most EFS data-access I/O should stop with the services. EFS storage, EBS, Secrets Manager, and CloudWatch keep billing at ~$8/mo. When you start it again, SSM is ready in ~60 seconds and all three `hermes-*`\n\nsystemd units restart automatically. No re-bootstrapping, no re-configuration, agent memory fully intact.\n\n**Floor: ~$8/mo when off. ~$35/mo when always-on.**\n\n| Model | Rate | Typical personal use |\n|---|---|---|\n| Claude Sonnet 4.x | ~$3/M in · $15/M out | $10–50/mo |\n| Nova Lite (aux slots) | ~$0.06/M in · $0.24/M out | < $2/mo |\n\nChatGPT Plus is $20/mo. You get no persistent agent filesystem, no terminal backend, no Telegram long-polling, and far less control over where memory and logs live.\n\nThe Hermes setup is more infrastructure to own, but that is the point: you own the memory, the skills, the `SOUL.md`\n\nthat shapes the agent's persona, the logs, and the conversation history. Stop the instance today, redeploy in six months, and the agent picks up from the same EFS-backed state.\n\n`cdk deploy --all`\n\n`hermes/runtime`\n\n), sync to EFS, restart gateway\n\n```\n# Access the workspace from your laptop\naws ssm start-session --target <InstanceId> \\\n  --document-name AWS-StartPortForwardingSession \\\n  --parameters '{\"portNumber\":[\"3000\"],\"localPortNumber\":[\"3000\"]}' \\\n  --region us-east-1\n\nopen http://localhost:3000\n```\n\nAfter step 4, Telegram just works. Message your bot, get a reply. No additional setup.\n\nI started with a private subnet, a NAT Gateway, and VPC interface endpoints for SSM, Bedrock, Secrets Manager, EFS, and CloudWatch. It's what every AWS security guide recommends. It's also ~$88/mo in endpoint costs before a single token is processed.\n\nThe insight that unlocked this architecture: **the security boundary for a personal agent isn't the subnet — it's what's reachable on the instance.** With zero inbound SG rules and all services bound to loopback, the public IP is inert. SSM and Telegram's long-polling handle the two access patterns (admin shell / bot messages) over outbound HTTPS. No VPN, no bastion, no open ports.\n\nThe most secure design for this use case turned out to be the simplest one.\n\n*Built with Hermes Agent · AWS CDK (Python) · Amazon Bedrock · SSM Session Manager*", "url": "https://wpnews.pro/news/how-i-deployed-hermes-agent-on-aws", "canonical_source": "https://dev.to/nitesh_reddychalla_d5515/how-i-deployed-hermes-agent-on-aws-371c", "published_at": "2026-06-24 22:46:01+00:00", "updated_at": "2026-06-24 23:13:05.820334+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-infrastructure"], "entities": ["Nous Research", "Hermes Agent", "AWS", "Amazon Bedrock", "Telegram", "EFS", "EC2", "Systems Manager Session Manager"], "alternates": {"html": "https://wpnews.pro/news/how-i-deployed-hermes-agent-on-aws", "markdown": "https://wpnews.pro/news/how-i-deployed-hermes-agent-on-aws.md", "text": "https://wpnews.pro/news/how-i-deployed-hermes-agent-on-aws.txt", "jsonld": "https://wpnews.pro/news/how-i-deployed-hermes-agent-on-aws.jsonld"}}