Bitrise RDE gives you cloud Macs & Linux machines that start in seconds, the same machines, stacks and caches as your CI. Give every agent its machine and run them in parallel via MCP, or attach VS Code, Cursor or Claude Code. Archive when you stop, restore later.
Hey Product Hunt, I’m Arpad, VP of Engineering at Bitrise (mobile DevOps startup).
Agents need somewhere real to run. You can hand an agent a task, but it has to execute somewhere.
❌ On your laptop it fights you for the CPU and the simulator, running multiple in parallel and you won’t be able to do a video call without CPU clipping and fans screaming. ❌ In a throwaway container it has no real device tooling, no warm dependencies and no memory of the last run, so it spends its first tokens rebuilding an environment it’s about to lose again.
✅ Bitrise Remote Dev Environments are that somewhere:
Bitrise RDE are on-demand cloud VMs (real macOS on Apple Silicon, or Linux) that an agent drives headless through our open-source MCP server.
Start a batch on different branches, → let them work in parallel, → collect the PRs. Or attach VS Code, Cursor or Claude Code over SSH and work in it yourself, like a laptop, but many.
The reason it actually works: these are the same machines that run production builds for mobile teams at scale. Same Apple Silicon hardware, same stacks, cloned from the same golden image the CI build fleet uses.
🤷♀️ Honestly this came out of a thing that annoys all of us. CI fails on something your laptop never hits: a different Xcode, a stale pod cache, a simulator runtime you don't have locally. You pull the branch, it passes, and your afternoon is gone comparing two machines instead of fixing the bug.
Agents made it worse: same problem, none of the judgement. It burns tokens down rabbit holes, sometimes fixes the environment only to hit the same wall next run in a fresh VM, then confidently opens a PR that can’t build – or fixes the wrong thing.
So we gave the human and the AI agent the same machine. When the environment you write code in is the one that tests it, a whole category of works-on-my-machine stops existing. Ask me anything about how it works, what it costs, or where it still falls short.
Kudos on launching your product. A bit basic, but why have decided to have a mobile focus for your RDE?
@lisadziuba Congrats on going live! I’m wondering how easy is to to launch VMs/cloud Mac? Do I need to register account or can I can try it without registration?
Amazing to hear that the age old problem of "it works locally" will finally meet its end!!
I had not even thought about how when agents hit this wall it likely results on a pit of burnt tokens trying to fix something that is not trivial to fix. Centralizing the environment this way is huge in this regard
I have one follow up question: what if I archive my VM, am I paying for it?
Interesting project! What do you use to virtualize sessions on Mac? Wondering from the standpoint of executing browser-based tasks — wondering will it fire anti-bot protection on websites due to virtualization.
Congrats team. If I need an older Xcode to reproduce a bug, can I get one? And how long do you keep old versions around?
Congrats on the launch! How does pricing actually work for your product, per seat, per machine, or per minute? And if an agent leaves a session running overnight, what stops the bill running with it?
Hey Product Hunt 👋, I'm Barnabas, CEO at Bitrise.
We first launched here back in 2014, when the problem was simply getting mobile builds to run reliably in the cloud. 11 years later we're back with Remote Dev Environments 🚀, and the problem has changed shape: it's not just developers who need a machine now, it's their agents too.
Happy to be back, and happy to answer anything in the comments today.
Last one that's come to mind...
How do you approach egress? e.g. During RDE sessions can egress be restricted, or will an AI agent have the same network access like a normal CI job?
Another from me:
How does your Remote Dev Env solution differentiate from others like GitHub Codespaces, Daytona, or E2B for the "give my coding agent a real sandboxed machine" use case?
Is it mainly faster builds or does the bigger benefit come from reducing manual testing and release work?
Giving every agent its own disposable cloud Mac instead of sharing one box is the right call once you're running more than one or two in parallel, that's exactly where local setups start fighting each other over ports and file locks. What I'd want to understand before adopting this is the cost model at real parallelism - if I've got a swarm of 10-20 agents each with their own machine running most of the day, does the CI-cache-sharing keep the bill sane, or does it scale close to linear with instance count?
congrats, team! one thing I would like to know before trusting production credentials inside it - who has the access to a running RDE session besides the agent. is there an audit trail if a human needs to jump in?
Can I use VS Code on my local computer while actually developing on the remote VM? Basically, can I connect my local VS Code directly to the virtual machine and work there as if it were local?
Hey, member of the Bitrise docs team here 📝
First of all, congrats! 🎉 And a quick question about templates for iOS.
How much of an existing Bitrise setup carries over (thinking stack, connected repo, workspace secrets) versus needing to be defined again for RDE? And where does code signing land: are certs and profiles part of the template? Or something you set up per session?
(Okay, this is a COUPLE of quick questions 😬)
I would like to know which testing problems teams usually struggle with most.
About Bitrise Remote Dev Environments on Product Hunt
“Cloud Macs your coding agents can actually build on”
Bitrise Remote Dev Environments launched on Product Hunt on September 17th, 2026 and earned 331 upvotes and 147 comments, earning #2 Product of the Day. Bitrise RDE gives you cloud Macs & Linux machines that start in seconds, the same machines, stacks and caches as your CI. Give every agent its machine and run them in parallel via MCP, or attach VS Code, Cursor or Claude Code. Archive when you stop, restore later.
Bitrise Remote Dev Environments was featured in Mac (103.7k followers), Developer Tools (519.6k followers) and Artificial Intelligence (478.9k followers) on Product Hunt. Together, these topics include over 215.8k products, making this a competitive space to launch in.
Who hunted Bitrise Remote Dev Environments?
Bitrise Remote Dev Environments was hunted by Lisa Dziuba. A “hunter” on Product Hunt is the community member who submits a product to the platform — uploading the images, the link, and tagging the makers behind it. Hunters typically write the first comment explaining why a product is worth attention, and their followers are notified the moment they post. Around 79% of featured launches on Product Hunt are self-hunted by their makers, but a well-known hunter still acts as a signal of quality to the rest of the community. See the full all-time top hunters leaderboard to discover who is shaping the Product Hunt ecosystem.
Reviews
Bitrise Remote Dev Environments has received 4 reviews on Product Hunt with an average rating of 5.00/5. Read all reviews on Product Hunt.
Want to see how Bitrise Remote Dev Environments stacked up against nearby launches in real time? Check out the live launch dashboard for upvote speed charts, proximity comparisons, and more analytics.
Lisa Dziuba
Hey Product Hunt, I’m Arpad, VP of Engineering at Bitrise (mobile DevOps startup).
Agents need somewhere real to run.
You can hand an agent a task, but it has to execute somewhere.
❌ On your laptop it fights you for the CPU and the simulator, running multiple in parallel and you won’t be able to do a video call without CPU clipping and fans screaming.
❌ In a throwaway container it has no real device tooling, no warm dependencies and no memory of the last run, so it spends its first tokens rebuilding an environment it’s about to lose again.
✅ Bitrise Remote Dev Environments are that somewhere:
Bitrise RDE are on-demand cloud VMs (real macOS on Apple Silicon, or Linux) that an agent drives headless through our open-source MCP server.
Start a batch on different branches, → let them work in parallel, → collect the PRs. Or attach VS Code, Cursor or Claude Code over SSH and work in it yourself, like a laptop, but many.
The reason it actually works: these are the same machines that run production builds for mobile teams at scale. Same Apple Silicon hardware, same stacks, cloned from the same golden image the CI build fleet uses.
🤷♀️ Honestly this came out of a thing that annoys all of us. CI fails on something your laptop never hits: a different Xcode, a stale pod cache, a simulator runtime you don't have locally. You pull the branch, it passes, and your afternoon is gone comparing two machines instead of fixing the bug.
Agents made it worse: same problem, none of the judgement. It burns tokens down rabbit holes, sometimes fixes the environment only to hit the same wall next run in a fresh VM, then confidently opens a PR that can’t build – or fixes the wrong thing.
So we gave the human and the AI agent the same machine. When the environment you write code in is the one that tests it, a whole category of works-on-my-machine stops existing. Ask me anything about how it works, what it costs, or where it still falls short.