Bitrise Remote Dev Environments

Summary

Bitrise Remote Dev Environments (RDE) provides on-demand macOS and Linux cloud virtual machines for developers and coding agents. The machines use the same images, toolchains, hardware families, and caches as Bitrise CI and Build Hub.

  • Provider: Bitrise
  • Product state: Beta
  • Primary focus: Mobile development, especially Apple-platform builds that require real macOS and Xcode
  • Status checked: 2026-07-14

Problem

Code often works on a laptop but fails in continuous integration because the operating system, Xcode version, build tools, dependencies, or cache differ. Coding agents amplify that mismatch because they can generate work faster than one laptop can build and test it.

RDE moves both the developer and agent into the same kind of machine that later runs CI. It is like practicing on the actual stage instead of a similar rehearsal room.

How It Works

  • Session: One RDE session is one cloud VM owned by a user inside a Bitrise workspace.
  • Stacks: Users select the same maintained operating-system images and preinstalled tools used by Bitrise CI.
  • Machine types: macOS runs on Apple silicon. Linux options range from shared machines to dedicated sizes; the product page advertises 2 to 48 vCPUs.
  • Templates: A reusable template selects the stack, machine type, working directory, scripts, inputs, secrets, and IDE links.
  • Preparation: A warmup script runs once when the VM is created. A startup script runs at each start or restore.
  • Persistence: Terminating stops compute but retains the session disk for later restoration. Deleting permanently removes a terminated session.
  • Access: Web terminal, SSH, VS Code Remote, Cursor, JetBrains, and file transfer work on supported sessions. macOS also provides VNC for its graphical desktop and Simulator.
  • Automation: The dashboard, command-line tool, experimental REST API, and open-source MCP server all manage sessions.
  • Agents: Claude Code or Codex can run inside the VM. The MCP server lets an outside agent create sessions, execute commands, move files, and control a macOS GUI.

Security Boundary

  • Full VM: Bitrise says each session is an isolated VM and sessions cannot access each other.
  • Customer separation: Product material says build VMs are never reused across customers. Dedicated-hardware customers can place RDE sessions on their existing private pool.
  • Remote boundary: Agent work runs away from the developer’s laptop and local files unless those files are uploaded or cloned.
  • Persistent session: The disk survives termination, so malicious changes can survive restoration. Delete the session when persistence is not wanted.
  • Credential scope: Bitrise says credentials are scoped to a session. Stored secret values are encrypted at rest.
  • Workspace controls: Sessions belong to workspaces, have user ownership, and use per-workspace quotas.
  • Agent authority: Inside the VM, an agent can read any secret exposed as an environment variable, use forwarded SSH authority, edit the persistent disk, and reach services allowed by the VM’s network.
  • Provider trust: Bitrise operates the hypervisor, storage, remote-access service, images, caches, and control plane. Source code and credentials placed in a session enter that trust boundary.
  • Beta warning: Official docs say RDE and its API can change without notice and should not support production-critical workflows yet.

Platforms And Agents

  • macOS: Real Apple-silicon VMs with M2 Pro, M4, and M4 Pro options, Xcode, Simulator, GUI access, and Apple build tools in US and European data centres.
  • Linux: Shared and dedicated VM sizes with Docker and common build toolchains.
  • Agents: Claude Code and OpenAI Codex are directly documented. Gemini CLI, Cursor, Windsurf, VS Code, JetBrains, GitHub Copilot clients, and custom MCP clients are also listed.
  • Human access: Browser terminal, SSH, IDE remote connections, and macOS VNC.
  • Mobile fit: iOS, tvOS, watchOS, macOS, Android, Flutter, React Native, and other mobile stacks benefit from CI image parity.

Setup

  1. Create or use a Bitrise account and workspace with RDE beta access.
  2. Install the open-source Bitrise command-line tool or use the web interface.
  3. Sign in through the browser.
  4. Choose a Bitrise stack and compatible machine type, or create a reusable template.
  5. Add a warmup script, startup script, working directory, and required inputs.
  6. Create a session and connect through the terminal, IDE, SSH, or macOS VNC.
  7. Run Claude Code, Codex, or another supported client.
  8. Terminate to retain disk state without running compute; restore later or delete permanently.

The CLI’s Claude flow can clone the current repository branch into a new session and open Claude Code. The hosted MCP server uses Bitrise OAuth; a local MCP installation uses a Bitrise token and provides file transfer plus local SSH-agent forwarding.

Network And Credentials

  • Saved inputs: Reusable values such as SSH public keys, API tokens, and Claude credentials are stored at the user level. Secret values are encrypted at rest.
  • Session exposure: Templates can map saved inputs into session environment variables. Once injected, a coding agent can generally read and use them.
  • SSH access: Each session receives an address and one-time password. A saved public key enables passwordless access.
  • SSH forwarding: The locally installed MCP server can forward the caller’s SSH agent into the VM. This avoids copying private keys, but the remote agent can request authentication to any destination the forwarded identity permits.
  • API authentication: The CLI/API can use browser login or a Bitrise personal access token. The hosted MCP service uses OAuth.
  • Network reach: Bitrise publishes outbound IP ranges so private Git and test systems can allow traffic from its machines. Dedicated, VPN, and single-tenant arrangements exist for higher-security Bitrise infrastructure.
  • No documented RDE egress policy: The reviewed RDE docs do not present a per-session deny-all or hostname allow-list comparable to Clawk or Vercel Sandbox.
  • No credential brokering found: Saved secrets are resolved server-side so they are hidden in the UI, but official docs describe exposing them to the session rather than adding them to requests outside the VM.

Pricing

  • Current beta: Bitrise’s June 30 launch post describes the self-serve beta as free.
  • Product page: The current FAQ does not publish stable RDE rates and asks teams to discuss their setup with Bitrise.
  • Future cost: No public general-availability price schedule was found.
  • Idle behavior: Bitrise says archived/terminated sessions preserve disk without metering running compute, but storage retention and future billing terms are not publicly quantified in the reviewed RDE pages.
  • Trial limit: Sessions in free-trial workspaces are capped at eight hours.

Treat the free beta as temporary and request written pricing before designing a large fleet around it.

Strengths

  • Real macOS: A rare hosted option for agent-driven iOS and Apple-platform work with Xcode and Simulator.
  • CI parity: Development and CI use the same maintained stacks and cache infrastructure.
  • Parallel scale: Multiple developers or agents can run independent machines instead of competing for one laptop.
  • Persistent sessions: Terminate and restore without rebuilding the whole environment.
  • Rich access: Terminal, IDE, SSH, VNC, API, CLI, and MCP cover human and autonomous workflows.
  • Templates: Teams can standardize machines, setup, credentials, and working directories.
  • GUI automation: The MCP server can capture screenshots, click, type, scroll, and drag inside a macOS session.
  • Existing enterprise path: Teams already using Bitrise may reuse vendor review, dedicated hardware, and CI infrastructure.
  • Open clients: The CLI and MCP server are open source even though the hosted execution platform is not.

Limits

  • Beta: Breaking API and client changes can occur without notice.
  • Not production-critical: Bitrise explicitly advises against relying on RDE for critical production workflows yet.
  • No stable public pricing: Fleet cost after beta is unknown.
  • Cloud custody: Code, disk state, build outputs, and injected credentials reside on Bitrise infrastructure.
  • Persistent compromise: Archived state can preserve unwanted changes across restores.
  • Secret visibility: Environment-based session secrets remain available to agent code.
  • Powerful SSH forwarding: It protects private key files but can still authorize unwanted Git or SSH actions.
  • Network-control gap: No agent-friendly egress deny-list or hostname policy was found in RDE documentation.
  • Limited free sessions: Free-trial sessions terminate after eight hours.
  • Stored disk expiry: Terminated disks are retained only for a limited, unspecified time before cleanup.
  • Mobile specialization: The strongest value is for teams already using Bitrise CI/Build Hub or requiring macOS; generic Linux users have many alternatives.
  • Hosted MCP limitations: File transfer is local-install-only, and hosted command execution lacks local SSH-agent forwarding.

Activity And Maturity

Checked 2026-07-14:

  • Beta launch: Public self-serve beta announced 2026-06-30.
  • Documentation: Main RDE documentation and a 42-endpoint API reference were published 2026-06-29.
  • MCP server: bitrise-io/bitrise-mcp-dev-environments had 35 commits, three releases, and latest version v1.2.1 on 2026-07-09.
  • Implementation signal: The MCP repository documents session lifecycle, templates, saved inputs, SSH execution, file transfer, and macOS GUI control.
  • Platform base: RDE builds on Bitrise’s established mobile CI and macOS VM fleet rather than a new standalone hypervisor platform.
  • Production usage claim: The product page says beta users include mobile teams at large consumer applications but does not name them.
  • Assessment: Strong underlying infrastructure with a very new RDE control plane, clients, documentation, and commercial model. Suitable for evaluation and non-critical work; premature as a fixed long-term dependency without a vendor agreement.

Best Fit

Bitrise RDE best fits a mobile team that:

  • already builds with Bitrise CI or Build Hub;
  • needs real Apple-silicon macOS for Xcode, Simulator, and agents;
  • wants developers and agents to use the same stack as CI;
  • needs parallel environments and persistent disk;
  • can place code and selected credentials on Bitrise;
  • accepts beta changes and direct pricing discussions.

It is a weaker fit for offline/local-only work, strict per-agent outbound filtering, workloads requiring a stable public price, production-critical automation, or generic Linux tasks that do not benefit from Bitrise stack parity.

Comparison

  • Versus Clawk: Clawk is a local, disposable, network-restricted Linux VM aimed at individual coding agents. Bitrise RDE is a hosted team/fleet service with persistent macOS and Linux sessions, CI parity, GUI access, and orchestration. Clawk keeps code local and has clearer outbound allow-listing.
  • Versus Vercel Sandbox: Both provide managed isolated VMs and programmatic fleet control. Vercel emphasizes short untrusted-code jobs, explicit network policy, and credential brokering. Bitrise emphasizes persistent development, macOS/Xcode, CI stacks, and IDE access.
  • Versus exe.dev: Both offer persistent remote machines for agents. exe.dev has simpler SSH-first pooled pricing and general Linux hosting. Bitrise adds real macOS, mobile CI parity, maintained Xcode stacks, and enterprise fleet integration.
  • Versus GitHub Codespaces: Codespaces is mature and repository-centric but normally Linux-container based. Bitrise’s distinguishing capability is real macOS VMs and direct parity with Bitrise CI images and caches.
  • Versus local Mac minis: RDE avoids buying, networking, updating, and scheduling hardware while scaling horizontally. Local Macs keep code under the team’s custody and offer predictable owned-hardware cost.
  • Versus Firejail/process sandboxes: RDE moves the workload entirely off the laptop and uses full VMs. Firejail is much lighter and free but shares the host Linux kernel and cannot provide macOS.

HN Context

Bitrise RDE was mentioned twice in HN thread 48892859 by dietdrb:

  • Cloud alternative: They said Bitrise was building the cloud version of Clawk with hosted, isolated macOS and Linux VMs that can run in parallel.
  • macOS distinction: In response to a list including Codespaces, CodeAnywhere, and Claude Code, they said those options did not provide the macOS environments needed by iOS and tvOS developers.
  • Experience claim: They said Bitrise had operated macOS VMs for CI for ten years and extended that existing product to remote development.

The comments appear promotional and likely come from someone connected to the project, though the comments did not state their formal role. Their macOS comparison is the central useful point; the current official product material supports that RDE offers real Apple-silicon macOS VMs.

Direct Sources

Unknowns

  • General pricing: Final rates, storage fees, data-transfer costs, and agent-fleet discounts are not public.
  • Disk retention: The exact retention time and deletion guarantees for terminated RDE disks are not stated in the reviewed pages.
  • Egress controls: No RDE-specific destination allow-list, deny-all policy, or credential-brokering design was found.
  • VM internals: The public RDE pages do not give a detailed hypervisor threat model or independent RDE-specific audit.
  • Regions by machine: Exact region availability for every RDE stack and machine type requires workspace-specific confirmation.
  • Dedicated isolation terms: Hardware tenancy, network connection, and compliance details depend on the customer’s Bitrise agreement.
  • Beta customers: Named RDE production references and independent performance benchmarks were not found.
  • API stability: The API is versioned but explicitly experimental and may break without deprecation.

Sources

    • imported AI research note for Bitrise Remote Dev Environments.