Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud

boxes.dev

Post reply on HN
Print view View original

51–60 of 87 posts

Re: Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud

#51

Post by nab »

2001zhaozhao wrote: post #40

Really cool tool! I am building a self-hosted tool (OpenClaw-like) to solve the same problem (running agents 24/7 and access from monile), which I think is the main alterative approach to cloud tools. I'm glad that other people have recognized the problem. We currently use worktrees btw. We have a port allocation system that sends ports to the agent automatically, which suffices for smoke testing web projects in para…

Nice -- yeah I definitely think it's possible to get configuration figured out for worktrees, but does require a some setup. Glad you all are in a good place on that front.

RE: setup required to make a project ready for VM deployment, not sure how complex your app is, but we've found that coding agents do a pretty good job at finding your dependencies locally, installing them on the remote, and ensuring your app runs on the remote end. If you have a few minutes, try out our auto-setup. Most people haven't had to lift a finger to get their apps running in VMs.

Re: Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud

#52

Post by [deleted] »

aliclark wrote: post #22
indigodaddy wrote: post #3

I 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! https://flexenv.com/ 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?

[deleted]

Re: Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud

#53

Post by nab »

gorgmah wrote: post #47
imoreno wrote: post #43

Don't Anthropic and OpenAI both offer the same thing built in? What are the difference with this service?

their product attempts to duplicate your local dev setup on a machine on the cloud, which means they copy your .env / local postgres db, local docker-compose stack etc. It worked quite well for me, I tried it just now (except for postgres + setting up git). I think the product is quite good but still needs a bit of polishing. I'm a bit frustrated that they restrained EU users from downloading their app, but I guess t…

Oof, I don't think we paid super close attention to the country list when shipping our app. We'll fix this for you, but it might be a few days for things to make it out of review. Really appreciate you trying it out. It's still pretty early so things are still rough around the edges, but we'll be keeping an eye out on our logs for bugs, and feel free to reach out to feedback at boxes.dev if you notice any issues.

Re: Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud

#54

Post by phsource »

iloveluce wrote: post #2

Interesting. 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…

Personally, with our company on Cursor, I can see why model makers are not the best people to go all the way down the stack. Using the right model for the situation will continue to be important, and model makers, by design, do not want to give you the choice to run different models.

Right now, we use:

- Kimi K2.5 for easy fixes, asking about the code, various agentic commands (e.g., summarizing Loom videos for Slack messages)

- Opus 4.8, Sonnet, or Kimi for planning (we find GPT-5.5 to have too terse outputs for plans)

- Kimi K2.5, Composer 2.5, GPT-5.4 mini, etc. for faster implementation (i.e. we don't have to wait around for the slower tokens-per-second generation on Sonnet, etc.)

If we had to only use Opus, Sonnet, and Haiku, I'd definitely be looking to switch harnesses

Re: Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud

#55

Post by yodon »

dregitsky wrote: post #48
peterldowns wrote: post #25

What 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 o…

> What kind of cpu/memory do the vms get? Default is 4 vCPU / 8 GB memory but it's configurable at the team/project level (can go higher). > 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? Yes we're moving in this direction! For the current public version each person sets up their box and then agent thread…

Don't Microsoft and others already offer this?

Re: Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud

#56

Post by bruckie »

What's the security story? I would love to adopt cloud dev environments that are constrained enough that I can safely run agents in YOLO mode, but not so constrained that they are useless. I would want it to be safe enough to run 80 to 90% of typical development work without supervision, and then have an escape hatch that allows doing other things with human supervision.

edit: and if anyone knows of an existing service that has these properties, I'd love to know about it.

Re: Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud

#57

Post by nab »

bruckie wrote: post #56

What's the security story? I would love to adopt cloud dev environments that are constrained enough that I can safely run agents in YOLO mode, but not so constrained that they are useless. I would want it to be safe enough to run 80 to 90% of typical development work without supervision, and then have an escape hatch that allows doing other things with human supervision. edit: and if anyone knows of an existing servi…

We're currently running Firecracker VMs in E2B, which separate kernel level isolation. Over the long term, we're open to making it cloud/provider agnostic if you don't like that and want to run in your own cloud.

Right now, since these are just linux machines, agents only have access to what you give them. For most development workflows, this means you're putting development environment variables and keys there.

We're also considering having some sort of key storage construct that allows you to require human confirmation for access to certain other keys, but curious if you have any thoughts on what the ideal UX is.

You can of course just build your ideal solution on the template box (perhaps 2 factor authentication via AWS secrets manager to get access to certain keys that require human confirmation), and update your skills. Then all future threads/forks will have access to that setup.

Re: Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud

#58

Post by soco »

nab wrote: post #34
soco wrote: post #26

It feels somehow weird to see a cloud tool usable only from Macs. Oh well.

Sorry about that. We should have made that more clear in the post but unfortunately HN doesn't let us edit it anymore. We're just 2 people right now and wanted to ship early. We want to support other platforms over the long term. We are cloud, but there is a local component for porting your local environment for the fast onboarding, so it requires some care. Are you on Windows?

I'm both Windows and Linux, so either would work for me.

Re: Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud

#59

Post by cohix »

kordlessagain wrote: post #41
cohix wrote: post #4

I really like the pricing model and focus on not shafting people by auto-sleeping when an agent is done working. I’ve been working on an [OSS TUI]( https://github.com/prettysmartdev/awman ) for managing agent execution and workflows in containers (local or remotely) and would love to collaborate if you’re interested.

Awman looks great - just installed on Windows and it built the image. I'm trying to figure out how to launch an agent... FWIW, I'm working on Nemesis8: https://github.com/DeepBlueDynamics/nemesis8 if you want to team up. I'm kordless at gmail or kord at deepbluedynamics

Would love to have some collaboration on the Windows side. Windows builds get published but get little to no manual testing, and not “fully supported” as of now but I would like to. If you can file issues and/or PRs I’d happily review.

Will check out your project as well, looks similar to where I started with awman but it’s morphed since then.

Re: Show HN: Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud

#60

Post by nab »

cohix wrote: post #4

I really like the pricing model and focus on not shafting people by auto-sleeping when an agent is done working. I’ve been working on an [OSS TUI]( https://github.com/prettysmartdev/awman ) for managing agent execution and workflows in containers (local or remotely) and would love to collaborate if you’re interested.

Nice, love the idea of having containers that can work on either local or remote. We may end up reaching out once we start thinking about that.

And thanks re: pricing model. It's a start, and we still have a lot of optimizations to go there to make this as cheap as possible, but we think it's a good base to build upon to make agents as efficient as possible compute-wise.

Post reply on HN