Thanks for sharing this interesting project and approach!
One suggestion for improvement: Add some more info to your website/GitHub about the need for a provider and which providers are compatible. It took me a bit to figure that out because there was no prominent info about it. Additionally, none of the demos showed a login or authentication part. To me, it seemed like the VMs just came out of nowhere. So at first, I thought "Cloudrouter" was a project/company that gave away free VMs/GPUs (e.g. free tier/trial thing). But that seemed too good to be true. Later, I noticed the e2b.app domain and then I also found the little note way down at the bottom of the site that says "Provider selection" and "Use E2B provider (default)". Then I got it. However, I should mention that I don't know much about this whole topic. I hadn't heard of E2B or Modal before. Other people might find it more clear.
For those that are wondering about this too, you will need to use a provider like https://e2b.dev/ or https://modal.com/ to use this skill, and you pay them based on usage time.
Right now, all usage is routed through us, hence `cloudrouter login` is required for now. Plan on adding bring-your-own cloud/key, but having something that's fast to setup is hard since we need to pre-build a template that includes VNC, browser, VSCode, worker daemon, etc...
Totally fair point. For me it was just a nice primitive to have -- just one command gives the agent a VM with SSH, file sync, browser, GPU ready to go. Instead of dealing with cloud account setup, security groups, SSH keys, and other shenanigans. For cloudrouter, the dependencies/Docker/VNC/Juypter Lab come pre-baked so you don't need to think about configuring VM environment setups...
This is cool! I tried it out, running outside my agent with `cloudrouter start .` and got a password request to auth into the server. Opened an issue[1].
Moving agent execution off localhost makes sense for parallel workflows, but giving an LLM direct provisioning power is terrifying from a billing perspective. If the agent gets into a retry loop or hallucination spiral, it could easily spin up expensive GPU instances (like that B200 example) without tearing them down. Do you enforce hard budget caps or instance-count limits at the API key level to prevent runaway provisioning? Also, how do you handle SSH key lifecycle management—are keys rotated per session to ensure no lingering access remains if the teardown command fails?
It's a cool idea, but personally I don't like the implementation. I usually don't use monolithic tools that cram a lot of different solutions into one thing. For one thing, especially if they're compiled, it's very hard to just modify them to do one extra thing I need without getting into a long development cycle. For two, they are usually inflexible, restricting what I can do. Third, they often aren't very composeable. Fourth, often they aren't easily pluggable/extensible.
I much prefer independent, loosely coupled, highly cohesive, composeable, extensible tools. It's not a very "programmery" solution, but it makes it easier as a user to fix things, extend things, combine things, etc.
The Docker template you have bundles a ton of apps into one container. This is problematic as it creates a big support burden, build burden, and compatibility burden. Docker works better when you make individual containers of a single app, and run them separately, and connect them with tcp, sockets, or volumes. Then the user can swap them out, add new ones, remove unneded ones, etc, and they can use an official upstream project. Docker-in-docker with a custom docker network works pretty well, and the host is still accessible if needed.
As a nit-pick: your auth code has browser-handling logic. This is low cohesion, a sign of problems to come. And in your rsync code:
I was just commenting the other day on here about how nobody checks SSH host keys and how SSH is basically wide-open due to this. Just leaving this here to show people what I mean. (It's not an easy problem to solve, but ignoring security isn't great either)
Re: monolithic tools. I think having template overrides for the user could solve this issue -- although it is a bit tougher to implement. I wanted a monolithic tool because it optimizes for faster startup times and just works but it does sacrifice configurability for the user.
Re: Docker template. I understand the Docker critique. So, the primary use case is an agent uploading its working directory and spinning it up as a dev environment. The agent needs the project files, the dev server, and the browser all in one place. If these are separate containers, the agent has to reason about volume mounts, Docker networking, etc — potentially more confusion, higher likelihood that agents get something wrong. A single environment where cloudrouter start ./my-project just works is what I envisioned.
Re: SSH host keys. SSH never connects to a real host. It's tunneled through TLS WebSocket via ProxyCommand. Also the hostname is fake, we have per-session auth token on the WebSocket layer, and VMs are ephemeral with fresh keys every boot. So, SSH isn't wide-open. We don't expose the SSH port (port 10000); everything goes through our authenticated proxy.
Myself I already pre-provisioned a kubernetes cluster and it just makes new manifests and deploys there. Less dangerous, less things for it to fail at. The networking is already setup. The costs are known/fixed (unless you autoscale in the cloud). It's much faster to deploy.
Same same... i have prepared a sample config file with most of most common k8s object types as examples and just use that as a skill. I have given it access to my test cluster. I have configured my own container registry as well. Claude generates perfect deployment artifacts every single time. Works superbly well. I use k3s btw.
Im running like upwards of 30 difference services(mixed types) on a single 6$/m contabo instance lol ... such a pleasant ci/cd experience.. no messy webhooks or complicated scripts on integrations... just 2-3 hardcoded commands and plain old k8s config files.. love it.
both. local k8s (Rancher desktop) for devloop integration tests, remote k8s for running services. Helm chart to bootstrap cluster services like CRDs and Cloudflare tunnel.
You can spin up cloud infra in claude code by just having it write IaC code. It's very good at this.
I do with it Pulumi, bc you can write some python or typescript for your infrastructure. But there are many infrastructure as code tools to choose from.
Yes, you can and definitely should use Pulumi or other cloud infra for production use cases. The way I envisioned cloudrouter was to give coding agents throwaway VMs, use it to close the loop on its task, and then stop/delete it afterwards...
Interesting approach. I've been going the opposite direction - building a local orchestration platform where 70+ agents share resources on my own machine. The isolation problem you mention is real. I've found that for many dev tasks, local-first avoids the latency and cost of cloud VMs, though GPU workloads are a different story. Curious how you handle agent state persistence across VM sessions?
I also personally prefer running agents locally instead of in the cloud. For some reason, it feels easier to steer Claude Code when it's running in my terminal vs steering something in the cloud. Maybe part of it is the latency from typing into ssh'd TUIs, and this is something that a GUI can solve... but I still feel more at home with Claude Code/codex in the CLI vs something like Claude Code Web/Codex Cloud. Part of it is likely reliability and "time to first token that AI responded that I can see." But local has tradeoff of conflicting ports/other resources, lag (maybe it's time to upgrade my M1 Max 64gb...), and slight latency incurred since LLM calls have slightly more network latency.
Curious to hear more about your local orchestration platform, how did you solve resource sharing (mainly ports for web stuff tbh)? Or is it more intra-task vs inter-task parallelism?
Railway is awesome! Pretty different use cases though - Railway's MCP is for deploying and managing persistent services (git-push-to-deploy). CloudRouter is about ephemeral sandboxes: the agent spins up a throwaway VM, does its work, and tears it down.
How are you guardrailing it? The first thing I thought of was how cryptominer bots love to spin up lots of gpu-enabled vms (malware). Are there any cost or resource hard-restrictions?
Our approach though is more tide-case agnostic and in the direction of brining full-fledged container orchestration converting from development to training and inference
This is a great approach — giving agents their own compute environment is a huge unlock.
One challenge I keep running into on the other side of this: even with a full VM and browser available, the bottleneck is often teaching the agent what to do. Writing detailed step-by-step instructions for each workflow is tedious and error-prone.
I've been working on a complementary tool (SkillForge — https://skillforge.expert) that takes a different angle: you record your screen doing the task once, and AI extracts every click/keystroke/navigation into a structured skill file the agent can replay.
The combo of something like CloudRouter (agent gets its own machine) + structured skill extraction (agent knows exactly what to do) feels like it could make agent automation much more practical for non-trivial workflows.
Ah, just one step closer to a model with it's own weights file can bootstrap and run itself.
Thanks for sharing this interesting project and approach!
One suggestion for improvement: Add some more info to your website/GitHub about the need for a provider and which providers are compatible. It took me a bit to figure that out because there was no prominent info about it. Additionally, none of the demos showed a login or authentication part. To me, it seemed like the VMs just came out of nowhere. So at first, I thought "Cloudrouter" was a project/company that gave away free VMs/GPUs (e.g. free tier/trial thing). But that seemed too good to be true. Later, I noticed the e2b.app domain and then I also found the little note way down at the bottom of the site that says "Provider selection" and "Use E2B provider (default)". Then I got it. However, I should mention that I don't know much about this whole topic. I hadn't heard of E2B or Modal before. Other people might find it more clear.
For those that are wondering about this too, you will need to use a provider like https://e2b.dev/ or https://modal.com/ to use this skill, and you pay them based on usage time.
Right now, all usage is routed through us, hence `cloudrouter login` is required for now. Plan on adding bring-your-own cloud/key, but having something that's fast to setup is hard since we need to pre-build a template that includes VNC, browser, VSCode, worker daemon, etc...
Thanks for the feedback! Adding the info into the website now.
What stops just mentioning AWS/Azure/GCP CLI tools to agents?
Totally fair point. For me it was just a nice primitive to have -- just one command gives the agent a VM with SSH, file sync, browser, GPU ready to go. Instead of dealing with cloud account setup, security groups, SSH keys, and other shenanigans. For cloudrouter, the dependencies/Docker/VNC/Juypter Lab come pre-baked so you don't need to think about configuring VM environment setups...
You can but I have to say that there's value in a tool that lets the ai do it using less tokens.
That way, it's harder to inject your own business as a mitm dependency in hopes of getting VC funding.
https://news.ycombinator.com/item?id=47009617
Nothing
This is cool! I tried it out, running outside my agent with `cloudrouter start .` and got a password request to auth into the server. Opened an issue[1].
[1] https://github.com/manaflow-ai/manaflow/issues/1711
Hey Nick! I figured out the root cause and have pushed a fix. Could you update the package and try again?
Moving agent execution off localhost makes sense for parallel workflows, but giving an LLM direct provisioning power is terrifying from a billing perspective. If the agent gets into a retry loop or hallucination spiral, it could easily spin up expensive GPU instances (like that B200 example) without tearing them down. Do you enforce hard budget caps or instance-count limits at the API key level to prevent runaway provisioning? Also, how do you handle SSH key lifecycle management—are keys rotated per session to ensure no lingering access remains if the teardown command fails?
It's a cool idea, but personally I don't like the implementation. I usually don't use monolithic tools that cram a lot of different solutions into one thing. For one thing, especially if they're compiled, it's very hard to just modify them to do one extra thing I need without getting into a long development cycle. For two, they are usually inflexible, restricting what I can do. Third, they often aren't very composeable. Fourth, often they aren't easily pluggable/extensible.
I much prefer independent, loosely coupled, highly cohesive, composeable, extensible tools. It's not a very "programmery" solution, but it makes it easier as a user to fix things, extend things, combine things, etc.
The Docker template you have bundles a ton of apps into one container. This is problematic as it creates a big support burden, build burden, and compatibility burden. Docker works better when you make individual containers of a single app, and run them separately, and connect them with tcp, sockets, or volumes. Then the user can swap them out, add new ones, remove unneded ones, etc, and they can use an official upstream project. Docker-in-docker with a custom docker network works pretty well, and the host is still accessible if needed.
As a nit-pick: your auth code has browser-handling logic. This is low cohesion, a sign of problems to come. And in your rsync code:
I was just commenting the other day on here about how nobody checks SSH host keys and how SSH is basically wide-open due to this. Just leaving this here to show people what I mean. (It's not an easy problem to solve, but ignoring security isn't great either)Re: monolithic tools. I think having template overrides for the user could solve this issue -- although it is a bit tougher to implement. I wanted a monolithic tool because it optimizes for faster startup times and just works but it does sacrifice configurability for the user.
Re: Docker template. I understand the Docker critique. So, the primary use case is an agent uploading its working directory and spinning it up as a dev environment. The agent needs the project files, the dev server, and the browser all in one place. If these are separate containers, the agent has to reason about volume mounts, Docker networking, etc — potentially more confusion, higher likelihood that agents get something wrong. A single environment where cloudrouter start ./my-project just works is what I envisioned.
Re: SSH host keys. SSH never connects to a real host. It's tunneled through TLS WebSocket via ProxyCommand. Also the hostname is fake, we have per-session auth token on the WebSocket layer, and VMs are ephemeral with fresh keys every boot. So, SSH isn't wide-open. We don't expose the SSH port (port 10000); everything goes through our authenticated proxy.
Myself I already pre-provisioned a kubernetes cluster and it just makes new manifests and deploys there. Less dangerous, less things for it to fail at. The networking is already setup. The costs are known/fixed (unless you autoscale in the cloud). It's much faster to deploy.
Same same... i have prepared a sample config file with most of most common k8s object types as examples and just use that as a skill. I have given it access to my test cluster. I have configured my own container registry as well. Claude generates perfect deployment artifacts every single time. Works superbly well. I use k3s btw.
Same, I love k3s, so convenient for baremetal self hosted
Im running like upwards of 30 difference services(mixed types) on a single 6$/m contabo instance lol ... such a pleasant ci/cd experience.. no messy webhooks or complicated scripts on integrations... just 2-3 hardcoded commands and plain old k8s config files.. love it.
Fair enough, is this mainly for running services or do you use it for dev loop too?
both. local k8s (Rancher desktop) for devloop integration tests, remote k8s for running services. Helm chart to bootstrap cluster services like CRDs and Cloudflare tunnel.
You can spin up cloud infra in claude code by just having it write IaC code. It's very good at this.
I do with it Pulumi, bc you can write some python or typescript for your infrastructure. But there are many infrastructure as code tools to choose from.
Yes, you can and definitely should use Pulumi or other cloud infra for production use cases. The way I envisioned cloudrouter was to give coding agents throwaway VMs, use it to close the loop on its task, and then stop/delete it afterwards...
Interesting approach. I've been going the opposite direction - building a local orchestration platform where 70+ agents share resources on my own machine. The isolation problem you mention is real. I've found that for many dev tasks, local-first avoids the latency and cost of cloud VMs, though GPU workloads are a different story. Curious how you handle agent state persistence across VM sessions?
I also personally prefer running agents locally instead of in the cloud. For some reason, it feels easier to steer Claude Code when it's running in my terminal vs steering something in the cloud. Maybe part of it is the latency from typing into ssh'd TUIs, and this is something that a GUI can solve... but I still feel more at home with Claude Code/codex in the CLI vs something like Claude Code Web/Codex Cloud. Part of it is likely reliability and "time to first token that AI responded that I can see." But local has tradeoff of conflicting ports/other resources, lag (maybe it's time to upgrade my M1 Max 64gb...), and slight latency incurred since LLM calls have slightly more network latency.
Curious to hear more about your local orchestration platform, how did you solve resource sharing (mainly ports for web stuff tbh)? Or is it more intra-task vs inter-task parallelism?
I think railway deserves a mention here: https://docs.railway.com/ai/mcp-server
Railway is awesome! Pretty different use cases though - Railway's MCP is for deploying and managing persistent services (git-push-to-deploy). CloudRouter is about ephemeral sandboxes: the agent spins up a throwaway VM, does its work, and tears it down.
We are definitely inspired by Railway though!
How are you guardrailing it? The first thing I thought of was how cryptominer bots love to spin up lots of gpu-enabled vms (malware). Are there any cost or resource hard-restrictions?
We have concurrency limits for sandboxes and some of the larger GPUs have guardrails put into place. Contact us when you get to those limits!
Anyone use fly.io sprites for this yet?
Plan on wrapping other sandbox providers besides e2b, modal... hence the name cloudrouter!
Nice, we build something similar at dstack
We recently also added support for agents: https://skills.sh/dstackai/dstack/dstack
Our approach though is more tide-case agnostic and in the direction of brining full-fledged container orchestration converting from development to training and inference
Awesome demo!!!
Freaking wow.
Great demo!
This is a great approach — giving agents their own compute environment is a huge unlock.
One challenge I keep running into on the other side of this: even with a full VM and browser available, the bottleneck is often teaching the agent what to do. Writing detailed step-by-step instructions for each workflow is tedious and error-prone.
I've been working on a complementary tool (SkillForge — https://skillforge.expert) that takes a different angle: you record your screen doing the task once, and AI extracts every click/keystroke/navigation into a structured skill file the agent can replay.
The combo of something like CloudRouter (agent gets its own machine) + structured skill extraction (agent knows exactly what to do) feels like it could make agent automation much more practical for non-trivial workflows.
[dead]
[dead]
Thanks for such an enjoyable read!