You can pry localhost from my cold dead hands.
Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud
21–30 of 87 posts
Re: Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud
#22I might use this if it supported any old cloud or VPS, and was at most $10/mo. The fact that you have decided that this platform should only live in your own custom cloud is unappealing to me. Or, open source it and let us run it on our own VPS and keep your expensive cloud for those who want to pay. As it stands would never consider it.
I'm building something like this that you can run in your own cloud!
It's nowhere near advanced as boxes.dev but it's built on the premise of running on any cloud. Indeed I have it running on two different bare metal server providers and I'm about to add a third (Azure) as I'm using my day job as my first customer.
Can I grab your contact details and schedule a demo?
Re: Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud
#23Maybe I’m naive but the longest single workflow I ran was maybe 15 minutes. How do you steer agents to run “overnight”? And what is the quality of such execution?
"build me a 10 million dollar MRR saas, make no mistakes"
Re: Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud
#24[flagged]
Re: Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud
#25What kind of cpu/memory do the vms get? Is there a way to define the template that's used, so I can say to a new team member, log in to boxes.dev and all the repos and tools are already there for you? And where do you get the machines, can we bring our own? The orchestration layer and product experience ticks all the boxes for me but where Codex, Claude, and Cursor have fallen down for me in the past is:
- slow and outdated vms
- horrible/no way to standardize environments for my team
- no way to bring our own compute to help resolve these issues ^
Re: Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud
#26It feels somehow weird to see a cloud tool usable only from Macs. Oh well.
Re: Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud
#27Maybe I’m naive but the longest single workflow I ran was maybe 15 minutes. How do you steer agents to run “overnight”? And what is the quality of such execution?
To add to what @nab said, the longest ("overnight") runs are usually after going back and forth to build out a big multi-phase plan doc -- especially when each phase has an extensive manual test plan (agent runs the app in a browser, clicks through the workflow, watches logs, confirms behavior, etc).
These can go for many hours from all the manual testing and debugging. Quality really depends on how much you spec things out beforehand, and how you define the test plan / "success" gates. If the agent can't even run the app to test it then things can definitely go off the rails!
Re: Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud
#28Interesting. Given that OpenAI and Anthropic are steadily moving down the stack (e.g. remote execution, Codex desktop, Claude Code integrations), how do you think about defensibility? Do you expect the labs to eventually offer a cloud-native ADE themselves, and if so, what advantage do you think an independent platform retains? Also, do you see Boxes supporting OpenCode and self-hosted/local models in the future? If…
A few angles to this. One is that coding just went through a massive change over the past year, that is not yet fully settled. Remember when everyone insisted on using IDEs and seeing the code with a chat sidebar? It's hard to argue you'll still be reading code a year from now. And even today, most people are still developing locally, which we're betting will shift to the cloud over the next few years. I imagine othe…
>It's hard to argue you'll still be reading code a year from now
groan
Re: Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud
#29Interesting. Given that OpenAI and Anthropic are steadily moving down the stack (e.g. remote execution, Codex desktop, Claude Code integrations), how do you think about defensibility? Do you expect the labs to eventually offer a cloud-native ADE themselves, and if so, what advantage do you think an independent platform retains? Also, do you see Boxes supporting OpenCode and self-hosted/local models in the future? If…
A few angles to this. One is that coding just went through a massive change over the past year, that is not yet fully settled. Remember when everyone insisted on using IDEs and seeing the code with a chat sidebar? It's hard to argue you'll still be reading code a year from now. And even today, most people are still developing locally, which we're betting will shift to the cloud over the next few years. I imagine othe…
Maybe I'm in the minority but I still program with an IDE and a chat window in the side at work, as well as when I work on side projects. I do like to actually see the code that is getting produced.
Re: Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud
#30Earlier quoted context omitted.
Thanks a ton for the feedback. Yeah, this is something we'll try to solve in the long term. One of the things that makes this work really smoothly for setup and speed is the ability to have a template box that you can instantly snapshot and fork (disk and RAM) to spin up new machines. There aren't many sandbox providers that do that well for running a full app and development environment, but I'm sure there will be m…
Pretty sure you could accomplish this in a large physical server or even a huge resource VM (that has KVM passthrough) with some sort of microvm technology? Then that would obviate the need for "multiple cloud instance per coding thread", it would just be a microvm on the large server. Then again, I'm just the guy running his mouth, and you guys are the ones actually doing the work :) BTW, looks very polished and tho…
Nope you're exactly right - we're using microVMs today (Firecracker VMs via E2B) and running that same shape but on customer-owned machines is definitely one approach we're looking into.
And thank you!