Cloud dev environments for agentic coding. Run each Claude Code or Codex chat on its own computer in the cloud, connect from mobile and desktop, and code from anywhere.
Hi Product Hunt! It's great to be back with a new launch. Fond memories of launching my last company, Gem, here way back in 2017!
We’re Nick and Drew, and we’re building boxes.dev – the first cloud-only agentic dev environment (ADE) that gives every Codex and Claude Code agent its own cloud computer.
We spent the last year coding almost exclusively with Codex / Claude Code, but got tired of leaving our laptops cracked open and dealing with clunky git worktrees. Developing on localhost was holding us back, so we decided to build the cloud-based ADE that we wished existed.
We’re obviously biased, but we’ve been building boxes.dev with boxes.dev for months and it’s been a gamechanger – it’s hard to imagine going back.
Key features:
Super easy setup (our agent scans your local dev setup and ports it to the cloud)
Full-featured desktop, CLI, and mobile app (not just handoffs or remote control)
Uses your Claude Code / Codex subscription (native harnesses & familiar UX)
Your coding agents can run/test your full app end-to-end in isolation
Scheduled automations & Slack integration
Optimized for parallel agent workflows
All new users get 10 free box-hours to test it out at boxes.dev. Hope you’ll give it a try – would love any and all feedback!
@patrickkavanagh They can! This is one of the reasons we built Boxes.dev. The models are great at testing their own work now with things like playwright. But having 5 copies of our app running locally and 5 copies of chromium so each of our parallel coding agents could test independently was getting out of hand on our laptops. With Boxes.dev, each thread/agent gets its own independent VM and filesystem, so you're not running out of resources.
@fberrez1 Yes, it does! You get full control over a linux box in the cloud for each claude code and codex thread (and a template box that gets snapshotted and cloned to produce the VM for every thread). It's great at running chromium headless, running playwright, and even sending you screenshots to the thread (visible in the desktop app and mobile). And because each thread/VM is independent of the others you can have a bunch of them running multiple copies of your app and chromium in parallel without slowing down the others. If it works on your laptop via the codex/claude CLI, it will almost certainly work on boxes.dev.
This looks great Nick, congrats on launching! Having a way to give Claude its own computer rather than trusting it with your own (terrifying) is a real smart idea and the space is heating up. I'm rooting for y'all and will be sure to try it out!
@seandotexe Thanks Sean! Yes, it feels freeing not having agents running wild on my personal laptop, with our VMs only having access to development credentials.
Report
Congrats on the launch Nick and Drew!
Early user of Boxes, and a big big fan. Some of my workloads are multi-hour so I’d previously have to either delay kicking it off or walking around with my laptop open (if you’ve been around South Park in SF you may have seen me doing this 😅).
Boxes has made this so much more convenient. But also broadly I’ve just started spending way less time at my computer, doing my thinking on whiteboards and notebooks, compiling requirements that way before kicking off tasks via my phone instead.
And for those wondering “why not use the cloud hosted versions of Claude Code or Codex” - for me a lot of it is down to needing local instances of a db for testing, wanting playwright screenshots for certain tasks when completed, etc. it’s literally my computer on the cloud.
Awesome idea. Have several my own boxes in USA running under my TV. However now I am traveling in Asia and latency makes work uncomfortable. Hope your boxes will be fast.
@sergebulaev Over the long term, we'll support spinning up VMs in local point of presence datacenters, so any threads/agents you create or wake up while traveling can be colocated with you.
But one thing I've noticed using boxes.dev on a plane is that since I'm just sending messages to a thread and looking at screenshots from the agent testing its own work, the user experience isn't that bad even with a lot of latency. Of course, if I have to use the terminal, that's slower, but on a plane I end up just pushing the agent to do whatever I wanted to do manually in a terminal window.
Report
This looks great. I spend a lot of time running coding agents so giving each one its own machine makes a lot of sense. Can you run several agents in parallel on the same repo?
@ianhxu Yes! This was the primary motivation for us -- you can have multiple threads/agents running in parallel, each with their own totally independent machine. No more running out of resources locally or having to juggle git worktrees. Since we have a template/main box that you have full control of, there's also no setup required per-thread/per-machine, each thread's VM starts from a perfect snapshot of the template box.
One thing that seems under-discussed with cloud coding environments is continuity.
Are users primarily spinning up fresh environments for each task, or do the most active users end up building long-lived workspaces that accumulate context over time?
@samyak_sanklecha We handle this with the notion of a "main box" or template box, which you can imagine to be your development laptop in the cloud. When you set up boxes.dev, our coding agents find your environment variables and undeclared dependencies locally, and then get your app fully running in a cloud VM. After it's set up, you can always jump into the terminal or make any changes you want on the template box.
When you create a new task, that main box is snapshotted (filesystem and RAM), and then a new independent fork is created from the snapshot.
So whenever you want to add context or update your setup on boxes.dev, change it on the main box and update the snapshot, and all future threads will get created from that snapshot.
Report
@nbushak That's interesting because it solves the continuity problem going forward, but it also raises the question of feedback.
If a fork discovers a better dependency, configuration, or workflow while working on a task, do you see that knowledge flowing back into the main box automatically, or is the main box intentionally treated as a human-curated source of truth?
It feels like the long-term challenge is deciding what should be inherited by future tasks versus what should remain local to a single fork.
@samyak_sanklecha Agreed, it's not a perfect model. Most configuation/dependencies are committed into the repo (and so are auto discovered when the main devbox or other devboxes pull it down), but occasionally you do need to go in and update a dependency on the main machine. It's not perfect but we're continuing to refine this as we go!
Nice! One thing I use all the time with claude code on my local is the secrets (.dev.vars, .envrc) so I can test things like OAuth flows or 3p integrations. How do you handle that with boxes.dev? Is there a secure way for me to put secrets on the boxes?
@willsmithte As a part of project setup, we ask if you want to send your dev secret files to the cloud box -- based on a local scan we run with coding agents to find which files are needed to run your app. If you say yes, those files are included in the encrypted project bundle we send to the remote machine (where another agent then sets up your project).
Right now the boxes are just linux machines with agents running on them, so expectation is that dev secrets live on the box itself (and more sensitive ones like prod keys should not be uploaded or at least require 2FA to work).
We're also looking into some kind of key storage construct that'd require human confirmation for access to certain other keys, but we're still iterating on the right UX for it.
Report
@drew_regitsky Awesome so you've thought of this exact case, that's great. Will give it a go this week, thanks for the reply
@willsmithte Of course and thanks for giving it a try! Definitely reach out if you have feedback or hit any issues -- we're still actively building and love hearing from people on first impressions + what we still need to improve.
Replies
Boxes.dev
Hi Product Hunt! It's great to be back with a new launch. Fond memories of launching my last company, Gem, here way back in 2017!
We’re Nick and Drew, and we’re building boxes.dev – the first cloud-only agentic dev environment (ADE) that gives every Codex and Claude Code agent its own cloud computer.
We spent the last year coding almost exclusively with Codex / Claude Code, but got tired of leaving our laptops cracked open and dealing with clunky git worktrees. Developing on localhost was holding us back, so we decided to build the cloud-based ADE that we wished existed.
We’re obviously biased, but we’ve been building boxes.dev with boxes.dev for months and it’s been a gamechanger – it’s hard to imagine going back.
Key features:
Super easy setup (our agent scans your local dev setup and ports it to the cloud)
Full-featured desktop, CLI, and mobile app (not just handoffs or remote control)
Uses your Claude Code / Codex subscription (native harnesses & familiar UX)
Your coding agents can run/test your full app end-to-end in isolation
Scheduled automations & Slack integration
Optimized for parallel agent workflows
All new users get 10 free box-hours to test it out at boxes.dev. Hope you’ll give it a try – would love any and all feedback!
Atlantic Money
@nbushak Looks great! Can the agents spin up playwright for tests?
Boxes.dev
@patrickkavanagh They can! This is one of the reasons we built Boxes.dev. The models are great at testing their own work now with things like playwright. But having 5 copies of our app running locally and 5 copies of chromium so each of our parallel coding agents could test independently was getting out of hand on our laptops. With Boxes.dev, each thread/agent gets its own independent VM and filesystem, so you're not running out of resources.
Fabric
@nbushak perfect. Exactly what I need.
Foyer
Does it have access to mcp and skills? can it run things like playwright mcp? how does it work?
I could be very interested to use it in my startup
Boxes.dev
@fberrez1 Yes, it does! You get full control over a linux box in the cloud for each claude code and codex thread (and a template box that gets snapshotted and cloned to produce the VM for every thread). It's great at running chromium headless, running playwright, and even sending you screenshots to the thread (visible in the desktop app and mobile). And because each thread/VM is independent of the others you can have a bunch of them running multiple copies of your app and chromium in parallel without slowing down the others. If it works on your laptop via the codex/claude CLI, it will almost certainly work on boxes.dev.
Novus
This looks great Nick, congrats on launching! Having a way to give Claude its own computer rather than trusting it with your own (terrifying) is a real smart idea and the space is heating up. I'm rooting for y'all and will be sure to try it out!
Boxes.dev
@seandotexe Thanks Sean! Yes, it feels freeing not having agents running wild on my personal laptop, with our VMs only having access to development credentials.
Congrats on the launch Nick and Drew!
Early user of Boxes, and a big big fan. Some of my workloads are multi-hour so I’d previously have to either delay kicking it off or walking around with my laptop open (if you’ve been around South Park in SF you may have seen me doing this 😅).
Boxes has made this so much more convenient. But also broadly I’ve just started spending way less time at my computer, doing my thinking on whiteboards and notebooks, compiling requirements that way before kicking off tasks via my phone instead.
And for those wondering “why not use the cloud hosted versions of Claude Code or Codex” - for me a lot of it is down to needing local instances of a db for testing, wanting playwright screenshots for certain tasks when completed, etc. it’s literally my computer on the cloud.
Boxes.dev
@raveesh Thanks so much for being an early user and believer in us!
Publora
Awesome idea. Have several my own boxes in USA running under my TV. However now I am traveling in Asia and latency makes work uncomfortable. Hope your boxes will be fast.
Boxes.dev
@sergebulaev Over the long term, we'll support spinning up VMs in local point of presence datacenters, so any threads/agents you create or wake up while traveling can be colocated with you.
But one thing I've noticed using boxes.dev on a plane is that since I'm just sending messages to a thread and looking at screenshots from the agent testing its own work, the user experience isn't that bad even with a lot of latency. Of course, if I have to use the terminal, that's slower, but on a plane I end up just pushing the agent to do whatever I wanted to do manually in a terminal window.
This looks great. I spend a lot of time running coding agents so giving each one its own machine makes a lot of sense. Can you run several agents in parallel on the same repo?
Boxes.dev
@ianhxu Yes! This was the primary motivation for us -- you can have multiple threads/agents running in parallel, each with their own totally independent machine. No more running out of resources locally or having to juggle git worktrees. Since we have a template/main box that you have full control of, there's also no setup required per-thread/per-machine, each thread's VM starts from a perfect snapshot of the template box.
Merge
Congrats on the launch! I've been playing around with the platform for a while now and have been blown away
Boxes.dev
@gil_feig Thanks a ton Gil!
One thing that seems under-discussed with cloud coding environments is continuity.
Are users primarily spinning up fresh environments for each task, or do the most active users end up building long-lived workspaces that accumulate context over time?
Boxes.dev
@samyak_sanklecha We handle this with the notion of a "main box" or template box, which you can imagine to be your development laptop in the cloud. When you set up boxes.dev, our coding agents find your environment variables and undeclared dependencies locally, and then get your app fully running in a cloud VM. After it's set up, you can always jump into the terminal or make any changes you want on the template box.
When you create a new task, that main box is snapshotted (filesystem and RAM), and then a new independent fork is created from the snapshot.
So whenever you want to add context or update your setup on boxes.dev, change it on the main box and update the snapshot, and all future threads will get created from that snapshot.
@nbushak That's interesting because it solves the continuity problem going forward, but it also raises the question of feedback.
If a fork discovers a better dependency, configuration, or workflow while working on a task, do you see that knowledge flowing back into the main box automatically, or is the main box intentionally treated as a human-curated source of truth?
It feels like the long-term challenge is deciding what should be inherited by future tasks versus what should remain local to a single fork.
Boxes.dev
@samyak_sanklecha Agreed, it's not a perfect model. Most configuation/dependencies are committed into the repo (and so are auto discovered when the main devbox or other devboxes pull it down), but occasionally you do need to go in and update a dependency on the main machine. It's not perfect but we're continuing to refine this as we go!
PersistIQ
Congrats on the launch, using it now!
Boxes.dev
@iloveluce Thanks Luciano!
Nice! One thing I use all the time with claude code on my local is the secrets (.dev.vars, .envrc) so I can test things like OAuth flows or 3p integrations. How do you handle that with boxes.dev? Is there a secure way for me to put secrets on the boxes?
Boxes.dev
@willsmithte As a part of project setup, we ask if you want to send your dev secret files to the cloud box -- based on a local scan we run with coding agents to find which files are needed to run your app. If you say yes, those files are included in the encrypted project bundle we send to the remote machine (where another agent then sets up your project).
Right now the boxes are just linux machines with agents running on them, so expectation is that dev secrets live on the box itself (and more sensitive ones like prod keys should not be uploaded or at least require 2FA to work).
We're also looking into some kind of key storage construct that'd require human confirmation for access to certain other keys, but we're still iterating on the right UX for it.
@drew_regitsky Awesome so you've thought of this exact case, that's great. Will give it a go this week, thanks for the reply
Boxes.dev
@willsmithte Of course and thanks for giving it a try! Definitely reach out if you have feedback or hit any issues -- we're still actively building and love hearing from people on first impressions + what we still need to improve.