The native macOS GUI for Apple's container CLI — built for the agent era

Apple's containerization framework gives every container its own lightweight VM with a dedicated IP and sub-second startup — but ships CLI-only, with no GUI, no compose, and no restart policies. Runbay fills those gaps natively, and turns every container into an MCP tool your coding agent can drive.

Download for macOS Set up with Claude Code

Signed & notarized .dmg, direct from runbay.app — also on GitHub Releases and via your Polar subscription. Apple Silicon · macOS 26 recommended · container CLI 1.0.0.

What it is

Three pillars, zero hype

A full-lifecycle GUI for Apple's actual runtime — not a Docker wrapper — that also speaks MCP both ways and keeps your services running.

01

A Docker Desktop alternative for apple/container

Native Table views for the full lifecycle: run, stop, restart, remove, plus Edit & Recreate. Everything you expect, built for Apple's runtime.

  • Stacks — compose-style orchestration the CLI doesn't have (8 templates, health gating)
  • docker-compose import with every unmappable key surfaced as a warning
  • Images, volumes, networks, live stats, streaming logs, in-app PTY terminal
  • One-click DB backup/restore · migration assistant from Docker & OrbStack

02

Agent-native — the only GUI that speaks MCP both ways

Runbay is an MCP server. No sidecar, no config. Your agent sees your containers as tools automatically.

  • Zero-config per-container tools: logs__, stats__, exec__, db_query__
  • Live resources & synthesized lifecycle events over MCP notifications
  • One-click registration into Claude Code, Claude Desktop, or Cursor
  • Agent Sandboxes: disposable VMs to run a coding agent off your host

03

It keeps things running

Apple's runtime supervises nothing — the CLI has no --restart. Runbay adds an app-side supervisor.

  • Daemon watchdog polls the engine every 30s with backoff
  • Keep-alive + launch-at-login via SMAppService
  • Opt-in per-container "Keep Running" crash-restart and health-driven restart
  • Honest about the sandbox limit — see the supervisor docs
claude ~ mcp tools
runbay  MCP server · tools update as containers start/stop
logs__postgresTail logs from the postgres container
stats__postgresLive CPU / RAM / network snapshot
db_query__postgresRun a validated, read-only SQL query
exec__redisRun a read-only allow-listed command
logs__nginxTail logs from the nginx container
sandbox_createSpin up a disposable agent VM
sandbox_runExecute a command inside a sandbox
Resources: container://postgres/logs · container://postgres/stats · container://events/recent
MCP both ways

Your containers become agent tools

Every running container automatically exposes logs__, stats__, and exec__ tools; database containers add a validated, read-only db_query__. Tools appear and disappear as containers start and stop, via notifications/tools/list_changed.

Register the runbay server into Claude Code, Claude Desktop, or Cursor with one click. Config files are edited with a byte-level JSON splice that preserves every unrelated key — malformed configs are refused, never clobbered.

Read the agent setup guide →

A look inside

Native, dense, and honest about state

Real screenshots land here before public launch. Slots reserved for the seven core surfaces.

01Dashboard
Dashboard with live stats and the disk-usage card.
02Containers table
Container Table view with inline actions and a running detail pane.
03Stacks & compose import
Stacks browser and a compose-import review sheet with warnings visible.
04MCP settings
One-click Claude Code / Cursor registration and the dynamic tool list.
05Agent sandbox
Sandbox create sheet showing the isolation picker and credential warning.
06Supervisor
Supervisor tab: watchdog state and per-container "Keep Running" toggles.
07In-app terminal
Real PTY terminal (SwiftTerm) attached to a container.

Drop the captures into site/assets/ and the placeholder boxes swap to images automatically — paths are wired in the markup.

What you need

Requirements, stated plainly

macOS 26 Tahoe recommended

Apple officially supports the container CLI only on macOS 26, where you get custom networks and container-to-container networking. It runs on macOS 15 — degraded, and the app says so in-app.

Apple Silicon

Apple's containerization framework does not support Intel. Nested virtualization for agent sandboxes wants M3 or newer.

container CLI 1.0.0+

Install the signed .pkg from apple/container releases. CLI 1.1.0 is additive and safe.

We'd rather you know exactly what you're getting. Read the honest limitations → — macOS 15 networking, engine self-restart under the sandbox, upstream build speed, and more.

Pricing

Free for you. A subscription for your company.

Every feature is in both tiers. The line is who you are, not what you get.

Free

$0

Personal & non-commercial use

  • The complete container platform
  • Stacks, compose import & migration assistant
  • Auto-MCP: tools, resources & events
  • Agent Sandboxes & the Supervisor
  • Every feature — nothing held back
Download free

No account required. Download and go.

Questions about the license, activation, or offline use? Read the licensing terms in plain language →

FAQ

The questions you're actually asking

How is this different from OrbStack or Docker Desktop?

OrbStack and Docker Desktop manage the Docker/Linux-VM world. Container Desktop is a GUI for Apple's own container runtime — each container gets its own lightweight VM and a dedicated IP, with no shared kernel. Apple ships that runtime CLI-only; we add the GUI, compose-style Stacks, a restart supervisor, and an MCP bridge none of the others have. It is not a Docker wrapper and it does not expose a Docker socket. See the migration guide for moving over.

Does it work on macOS 15, or do I need macOS 26?

It runs on macOS 15, but Apple only officially supports the container CLI on macOS 26 Tahoe. On macOS 15 you lose container-to-container networking and container network create — an Apple constraint, not ours. The app detects this and tells you honestly in-app. macOS 26 is the full experience. Apple Silicon is required either way.

Is my data local? What leaves my machine?

Everything runs on your Mac. Containers, logs, stats, and the SQLite cache are all local. The MCP server listens on a local Unix socket (or localhost TCP) only, rate-limited, with no TLS yet — so keep it to your machine. There is no telemetry backend, no hosted agent compute, and no config/license sync server: license validation talks directly to Polar's hosted API, and that's the only outbound call in normal use.

What is MCP, and why does it matter here?

MCP (Model Context Protocol) is the open standard coding agents use to discover and call tools. Runbay is an MCP server: every running container automatically becomes a set of tools (logs__, stats__, exec__, and db_query__ for databases) plus live resources and lifecycle events. Your agent can read logs, check stats, run a read-only query, or spin up a disposable sandbox — without you writing any glue. See the agent setup guide.

What are the license terms?

Free for personal and non-commercial use, with every feature included. Commercial use at a company requires an $8/user/month subscription — an honor-system license key model, like OrbStack. The key validates against Polar's hosted API and caches for offline use with a grace window, so you're not locked out on a flight. Plain-language details are in the licensing doc.

Can my agent touch my host filesystem or credentials?

Not by default. Agent Sandboxes are disposable container machine VMs, and the only host-filesystem lever the CLI offers is --home-mount none|ro|rw. The default is Isolated (none): your $HOME, SSH keys, and cloud tokens stay invisible. The ro and rw options carry explicit, red-text credential-exposure warnings. Read the honest isolation model in the sandboxes doc.