runtime-orbit

Docker on a laptop is expensive. A Linux VM, a few containers, a build cache, and you've spent 8 GB and half your CPU before your editor opens. Meanwhile there's a machine two metres away with 64 GB doing nothing.

runtime-orbit points this machine's docker at that machine's container runtime over SSH. Heavy docker build, docker run and docker compose execute over there — using its RAM, CPU and disk — while published container ports are forwarded straight back to your localhost, so it feels like Docker never left.

┌─ borrower — your laptop (16 GB) ─┐        ┌─ donor — the beefy one (64 GB) ─┐
│  docker CLI                     │        │  Docker / OrbStack / Podman     │
│  localhost:8080  ◄──────────────┼─ ssh ──┼─►  nginx container :8080        │
│  mostly yours again             │        │  doing the actual work          │
└─────────────────────────────────┘        └─────────────────────────────────┘
Your workflow doesn't change. The compute moves.

Two roles

  • ▸borrower — the machine that's low on RAM. Your laptop. It needs the docker CLI and nothing else. All the unprefixed commands run here.
  • ▸donor — the machine lending its runtime: another Mac, a gaming PC, a Linux box. Its commands live under runtime-orbit donor … (donator and lender also work).
runtime-orbit manages a standard docker context — it does not wrap the docker binary — so docker, docker compose, Testcontainers, IDE integrations and everything else that respects DOCKER_HOST work unchanged.

What it isn't

Not a code-sync tool, not a Kubernetes replacement, not a docker wrapper. Your source stays where it is — bind-mount paths resolve on the donor, which is worth knowing (see Troubleshooting).