You have decided Hermes Agent is worth running. Now comes the part that quietly decides how much of your week the agent will consume: how do you actually keep it online?
Most guides answer that with a wall of Docker commands. Three weeks later, the container falls over after an update, the dashboard is unreachable, and you are debugging volume permissions at 11 PM instead of using the agent you set up. There is a simpler path, a more powerful one, and a middle ground that most comparisons miss entirely.
The choice comes down to how much of the operational work you want to own. And here is the part people often do not realize: xCloud can host Hermes both ways. You can deploy your own Hermes container on an xCloud Docker server, or skip the containers entirely with fully managed Hermes Agent hosting. This guide walks through all three routes, DIY Docker, Docker hosting on xCloud, and fully managed hosting, and explains why managed is the better default for most people.
Quick Answer: The Three Ways at a Glance
Too long; did not read? Here is the short version. There are three layers to own when you run a containerized agent: the server, the container, and the Hermes application itself. Each option hands more of those layers to someone else.
| What you own | DIY Docker (any VPS) | Docker Hosting on xCloud | Managed Hermes Hosting |
| Server, networking, SSL | You | xCloud | xCloud |
| Docker + NGINX setup | You | Preconfigured by xCloud | xCloud |
| Compose file and container | You | You (paste, URL, or Git) | xCloud |
| Hermes app and updates | You | You | xCloud |
| Gateway configuration | You | You | Pre-configured |
| Backups and monitoring | You | Server-level by xCloud | Full, automated |
| Skill required | High | Medium | None |
| Setup time | An afternoon | Minutes to a live server | Minutes, one-click |
| Best for | Total control | Developers who want Docker, not sysadmin work | Everyone else |
The pattern is simple. DIY Docker gives you everything and every responsibility. Docker hosting on xCloud removes the server headache but keeps you in control of the container. Fully managed hosting removes all of it. If you just want a reliable agent, that last column is the answer.
Three Ways to Run Hermes Agent
Before the details, one clarification that saves a lot of confusion. This is not “Docker versus no Docker.” A managed platform runs Hermes in containers too. The real question is who is responsible for building, securing, updating, and monitoring the stack. That responsibility comes in three flavors.
Raw DIY Docker. You rent a bare VPS from any provider, install Docker, write a compose file, mount volumes for the agent’s state, put a reverse proxy in front for TLS, and take ownership of every operational detail from there. Maximum control, maximum work.
Docker hosting on xCloud. You still deploy the Hermes container yourself, but xCloud provisions the Docker server for you with Docker and NGINX preconfigured, handles SSL and networking, and locks down SSH. You bring the compose file; xCloud runs the machine underneath it. This is the developer sweet spot: Docker control without the sysadmin grind.
Fully managed Hermes hosting. xCloud provisions the server, deploys Hermes, wires up the gateway and SSL, and handles backups, updates, and monitoring. You sign up, add your API key, and start using the agent. No Docker knowledge required at all.
All three are valid. The right choice depends on how much of that work you actually want to do.
What Running Hermes Agent in Raw Docker Involves
Docker is the recommended way to run Hermes on a server you manage yourself, and for good reason. The image is clean, reproducible, and easy to migrate. Here is what the raw path looks like.
The Official Image and a Compose File
Hermes ships as an official Docker image (ghcr.io/nousresearch/hermes-agent) that bundles the gateway, dashboard, and every runtime dependency, so the host only needs Docker installed. For anything beyond a quick test, a compose file is the maintainable way to run it:
services:
hermes:
image: ghcr.io/nousresearch/hermes-agent:latest # pin a version in production
container_name: hermes
restart: unless-stopped
ports:
- "127.0.0.1:8642:8642" # gateway + web UI; put Caddy/nginx in front for TLS
env_file:
- ./.env # provider keys and bot tokens, never baked into the image
volumes:
- hermes_data:/opt/data # config, .env, sessions, memory, and skills persist here
deploy:
resources:
limits:
memory: 4G
cpus: "2.0"
volumes:
hermes_data:
Bring it up with docker compose up -d, and the gateway plus web UI are reachable on port 8642. Two details are non-negotiable. First, persist the data volume so config, memory, and skills survive restarts and upgrades. Second, pin your image tag in production so a new release does not break the stack without warning. And never run two gateway containers against the same volume, because Hermes assumes a single writer and will corrupt its state.
What You Own With Docker
The compose file is the easy part. Raw self-hosting means you also own everything around it:
- Volumes and permissions, including the UID and GID ownership issues that commonly break things after an update.
- TLS and a reverse proxy, because the gateway needs HTTPS for inbound webhooks and the dashboard should never be public without authentication. An exposed, unauthenticated dashboard was the entry point for a real 2026 attack campaign, so an auth gate is now mandatory on any non-loopback bind.
- Updates, which means pulling new tags, testing them, and rolling back when something breaks.
- Backups, which means scripting volume snapshots and, more importantly, testing that they actually restore.
- Monitoring, which means watching the gateway process and not just the container status, plus logs and health checks.
- Uptime, which means keeping the host alive and recovering cleanly after reboots.
None of this is exotic. But it is real, recurring work, and getting any one piece wrong can cost you your data or your security. If you go this route, our guide on how to secure Hermes Agent on a VPS covers the hardening that belongs alongside a Docker deployment.
Docker Compose vs the Docker Terminal Backend
One thing trips up almost everyone searching for “hermes agent docker,” so it is worth clearing up. There are two different Docker concepts in Hermes, and they are easy to confuse:
- Docker Compose deployment runs the entire agent as a long-lived container. This is a hosting method.
- The Docker terminal backend is a security setting that makes a Hermes session execute shell commands inside isolated, throwaway containers. This is a sandboxing feature, not a deployment.
You can use one, both, or neither. A lot of “Docker is not working” threads dissolve the moment someone realizes these are separate things. Our Hermes Agent skills explainer touches on how that sandbox protects skill execution. This post is about the deployment side.
Docker Hosting on xCloud: Docker Without the Server Admin
Here is the middle path that most Docker-versus-managed comparisons leave out. You do not have to choose between raw DIY Docker and giving up containers entirely. With xCloud’s Custom Docker feature, you deploy your own Docker Compose stack, including the Hermes container, onto a managed xCloud Docker server.
The difference from raw self-hosting is where the line sits. xCloud provisions the Docker server, ships it with Docker and NGINX preconfigured, handles SSL and routing, and locks SSH access down to trusted IPs. You provide the Hermes compose file (paste it in, point to a public URL, or pull it from a Git repository), and xCloud runs the machine underneath. You keep full control of the container, the image, and the config, while the server provisioning, networking, TLS, and hardening that eat your evenings are handled for you.
For a developer who genuinely wants Docker control but does not want to babysit a bare VPS, this is the best of both worlds. Our step-by-step guide to deploying custom Docker with xCloud walks through creating the Docker server and shipping a compose stack.
There is still a limit worth naming honestly: on this path, you own the Hermes container and its lifecycle. The compose file, the image updates and tag pinning, the gateway configuration, the dashboard auth, and the memory and skills volume are still yours to manage. xCloud runs the server; you run Hermes. That is exactly the layer the fully managed option removes.
Fully Managed Hermes Agent Hosting: The Zero-Ops Path
Managed hosting exists to remove the operational surface entirely, including the Hermes application itself. Instead of assembling and maintaining any of the stack above, you get a deployment where the hard parts are already done: one-click provisioning, a pre-configured messaging gateway, free auto-renewing SSL, daily backups, managed Hermes updates, monitoring, and support when something needs attention.
You bring your own AI provider key, and the platform keeps the runtime online and patched. There is no compose file to write, no image tag to pin, no gateway to wire up, and no 3 AM restart when a container falls over. If you can use Telegram, you can use Hermes on the managed path.
Why Managed Hosting Is the Better Default
Look back at the three layers: the server, the container, and the Hermes application. That framing is the whole argument.
Raw DIY Docker leaves all three on your plate. Docker hosting on xCloud takes the server off your plate, which is a real and meaningful upgrade, but the container and the Hermes app lifecycle are still yours. Fully managed hosting takes all three, and the third layer is the one that actually breaks in practice.
Think about what goes wrong with a self-run Hermes container over a year. A new image ships and changes a default, so the gateway stops delivering messages. A volume permission shifts after an update and the agent loses access to its own memory. The dashboard gets exposed because a rule was missed. A Telegram webhook fails silently because the SSL certificate lapsed. None of these are the server’s fault, so a managed Docker server does not save you from them. They live in the container and application layer, which is exactly what fully managed hosting owns on your behalf.
That is why managed hosting is the better default for most people. It is not that Docker is bad. It is that the last layer, the Hermes application itself, is where the recurring, easy-to-miss failures live, and managed hosting is the only option that takes it off your hands. You keep the model choice and your data; you give up the pager. For a founder, a marketer, an agency, or anyone whose job is not “run this agent’s infrastructure,” that trade is almost always worth it.
Head-to-Head: The Decisions That Matter
Setup Time and Skill Required
Raw Docker rewards people who already know Docker. A first production-ready deployment, with volumes, a reverse proxy, TLS, and dashboard auth, is realistically an afternoon, and longer if you are learning as you go. Docker hosting on xCloud shortens that to the time it takes to create a server and paste a compose file. Fully managed hosting is minutes with no container or Linux knowledge at all. If “reverse proxy” and “UID remap” are not part of your vocabulary, that gap is the whole story.
Control and Customization
This is Docker’s genuine strength, and it is why the xCloud Docker path exists. You control the exact image, config, network, and volumes, and you can extend the compose file with sidecars, local inference, or custom tooling. Fully managed hosting gives you guided control within the platform’s guardrails, which is plenty for most workflows but not for deep customization. If you need to modify the runtime or run an unusual topology, a Docker path wins here.
Security and Maintenance
All three can be secure. The question is who maintains that security. On raw Docker, you own the hardening, the mandatory dashboard auth gate, secret management, and patching, forever. Docker hosting on xCloud secures the server layer for you (SSH lockdown, SSL, firewall) but leaves the container and app hardening to you. Fully managed hosting ships a hardened baseline and keeps every layer patched without you tracking releases. For a team without a dedicated ops person, managed removes the single biggest risk: a misconfiguration nobody caught.
True Cost
Raw Docker looks cheaper on paper. A VPS can be a few dollars a month. But the sticker price hides the real cost, which is the hours per week you spend on setup, updates, debugging, and maintenance. Managed hosting has a higher, predictable line item that folds all of that operational time into one fee. For a fuller cost breakdown across managed, VPS, and serverless options, see our comparison of the best Hermes Agent hosting providers.
Reliability and Uptime
Hermes only delivers value when it is running. Persistent memory compounds, skills accrue, and scheduled jobs fire only while the agent is alive. A well-run container with restart: unless-stopped on a solid server is reliable. Fully managed hosting adds monitoring, auto-recovery, and support so uptime is not your job. If the agent’s availability is tied to your work or your income, that safety net is worth a lot.
Which One Should You Choose?
There is no universal answer, only the right fit for you.
Raw DIY Docker If You Want Total Control
Choose this when you:
- Are comfortable with Docker, Linux, networking, and TLS.
- Want full control over the server, image, and surrounding stack.
- Already run a homelab or a spare VPS with capacity to use.
- Treat infrastructure as part of the job rather than a distraction from it.
Docker Hosting on xCloud If You Want Docker Without Sysadmin Work
Choose this when you:
- Want to keep the compose file and container fully in your hands.
- Do not want to provision, secure, and maintain the server yourself.
- Like deploying from a Git repository or a Compose file with SSL and networking already handled.
- Are a developer, not a full-time sysadmin.
Fully Managed Hosting If You Want the Outcome
Choose this when you:
- Want a working agent without touching Docker at all.
- Do not want to own the container, updates, gateway, backups, or monitoring.
- Value predictable cost and included support over a lower sticker price.
- Are a founder, marketer, agency, or team that needs the capability, not the plumbing.
Still weighing the agent itself and not just the hosting? Our Hermes Agent vs OpenClaw comparison covers that side of the decision.
The Catch: Even Docker Needs an Always-On Host
Here is the point that reframes the whole debate. Choosing Docker does not remove the need for infrastructure. It just packages the app. You still need a server that never sleeps.
Run the container on your laptop and the agent stops the moment the lid closes. Memory stops updating. Scheduled automations fail silently. Hermes is built for continuous execution, so production setups run on always-on infrastructure regardless of Docker.
That is why the honest comparison is not “Docker versus managed.” It is a question of how many layers you want to own. Raw Docker is all three. Docker hosting on xCloud is two. Fully managed is none. The more layers you hand off, the more time you get back for the work the agent is supposed to free you up to do.
How to Deploy Hermes Agent on xCloud
Whichever way you lean, xCloud has a route. If you want Docker control, follow the custom Docker deployment guide to spin up a Docker server and ship your Hermes compose stack. If you want zero operations, the fully managed path is faster still:
- Sign up at xCloud and choose a plan.
- xCloud deploys everything automatically: server provisioning, Hermes installation, the messaging gateway, SSL, and backups.
- Open Telegram and start talking to your agent.
No terminal commands. No compose file. No reverse proxy to configure. You bring your own AI provider key, so there is no markup on your model spend. For a step-by-step walkthrough, see our full guide to deploying managed Hermes Agent hosting on xCloud.
Frequently Asked Questions
Can I deploy Hermes Agent with Docker on xCloud?
Yes. xCloud’s Custom Docker feature lets you deploy a Docker Compose stack, including the Hermes container, onto a managed xCloud Docker server with Docker and NGINX preconfigured. You keep control of the container while xCloud handles server provisioning, networking, SSL, and SSH security.
What is the difference between xCloud Docker hosting and managed Hermes hosting?
Docker hosting on xCloud manages the server for you, but you still own the Hermes container, its updates, and its gateway configuration. Fully managed Hermes hosting goes one layer further and manages the Hermes application itself: one-click deploy, pre-configured gateway, managed updates, backups, and monitoring, with no Docker knowledge required.
Does Hermes Agent have an official Docker image?
Yes. Hermes ships an official image (ghcr.io/nousresearch/hermes-agent) that bundles the gateway, dashboard, and runtime dependencies, so the host only needs Docker. It is the recommended way to self-host Hermes, usually through a docker-compose file with a persistent volume.
Is Docker or managed hosting better for Hermes Agent?
It depends on your skills and goals. Docker gives you more control and suits developers comfortable managing containers. Managed hosting is better for most people because it removes the container and application maintenance where the recurring failures actually happen. All paths run the same underlying agent.
Can I run Hermes Agent in Docker on my laptop?
You can for testing, but not for real use. Laptops sleep and disconnect, which stops the agent, pauses memory updates, and breaks scheduled tasks. For continuous operation you need an always-on host such as a VPS or a managed platform.
Do I still need a VPS if I use Docker?
Yes, unless you have another always-on machine. Docker packages the application, but it still needs a host that stays online 24/7. That is why the practical comparison is really about who manages the server, the container, and the Hermes app: you or a managed provider.
What are the minimum requirements to run Hermes in Docker?
Plan for at least 2 GB of RAM, with 4 GB or more recommended for comfortable use, a Linux host with Docker installed, roughly 2 GB of disk for the image plus room for the data volume, and a provider API key. Running a model locally needs significantly more memory.
So, Docker or Managed Hosting?
If you enjoy infrastructure and want root-level control, raw Docker on your own VPS is a great fit, and xCloud’s Docker hosting is the smarter version of it, keeping your compose file in your hands while taking the server off your plate. Both are solid choices for developers who want to own the container.
But if you have ever set something up on a Friday and spent the following Tuesday debugging volume permissions instead of doing your actual work, fully managed hosting is the better call. The agent is identical. The model is yours. The only thing that changes is who carries the pager. Managed hosting is the one option that removes the layer where things quietly break, the Hermes application itself, so you get the same agent running 24/7 with the gateway, SSL, updates, backups, and monitoring all handled for you.
All three roads lead to the same destination: a Hermes Agent that stays online and gets better over time. Choose raw Docker to own the whole stack, Docker hosting on xCloud to keep container control without the server admin, or deploy fully managed Hermes Agent hosting on xCloud to skip the operations entirely and keep the outcome. Your agent can be live in the time it took to read this guide.
If you have found this blog helpful, feel free to subscribe to our blogs for valuable tutorials, guides, knowledge and tips on web hosting and server management. You can also join our Facebook community to share insights and take part in discussions.
