Install dev-mux

"Install" means something different for each role. Pick your role first, then follow the platform steps for that role. With the managed product the hub is provisioned for you — there is nothing to install for the hub role.

Which role am I installing?

If you are unsure: the box where your code and your agents live is a spoke; the box in your hands is a device.

Before you install

The hub reaches your spokes over Tailscale, a private network. Follow the Tailscale setup guide for that connection. A browser can reach a managed hub's public Command Center at https://<your-hub>.dev-mux.com/cc/; Cloudflare sign-in and DevMux device enrollment are separate steps. Native apps and terminal clients need the connection address supplied by your hub owner. A private tailnet address also requires Tailscale on the device.

Install a spoke

A spoke runs the single-file dev script. It needs no heavy dependencies — no databases, no tokens, no secrets. The public one-line bootstrap installs dev, wires the current codebase's hooks, creates a minimal runnable .dev/session.conf when one is absent (and preserves an existing one), and registers the spoke with your hub:

curl -fsSL https://dev-mux.com/install | bash

Answer the prompts for the existing absolute codebase path, its session name, and your hub. After bootstrap reaches done:, local installation and wiring are complete. When you supplied a hub, the adopt path also reports registration accepted; if you left the hub blank, no registration was attempted. The completion output does not claim that the poller or Cockpit can already see the spoke. Verify the finished path explicitly:

dev onboard-check "$PWD" --hub <your-hub-url>
REPO_ROOT="$PWD" dev ls
REPO_ROOT="$PWD" dev up

Then confirm the live session appears in Cockpit. Install your coding agent (for example, Claude Code) before relying on agent-activity reporting. If bootstrap reports a failed hook, config, or registration step, use the manual recovery in Add spokes; do not repeat those commands after a successful run.

Spoke on a Raspberry Pi or cloud VM

The same public one-liner works on a Raspberry Pi, a GCP/AWS/Azure VM, or any Linux box. The floor is identical: bash, tmux, git. No native code runs on a spoke.

Spoke on macOS (Apple Silicon)

A Mac works as a spoke; the hub drives its tmux exactly like a Linux box. One thing to clear on Apple Silicon: Homebrew is not on the non-interactive PATH that a remote command runs under, so surface dev and tmux on a system path:

sudo ln -sf ~/.local/bin/dev /usr/local/bin/dev
sudo ln -sf "$(command -v tmux)" /usr/local/bin/tmux

Keep the spoke's repo on the internal disk (not an external volume) so macOS file permissions do not block the remote session.

Install a device

For the browser Command Center, open your hub's /cc/ address and use the device enrollment link supplied by your owner. No terminal-client installation is required. For an optional desktop terminal client, install devf:

curl -fsSL https://dev-mux.com/dl/install.sh | bash -s -- --role device
export DEV_HUB=<your-hub-host>

<your-hub-host> is your hub's Tailscale name (for example hub.tailnet-XXXX.ts.net). Then run the onboarding helper for your platform, for example devf onboard mac.

Windows (WSL2)

tmux and the dev-mux core run under WSL2 on Windows. The PowerShell installer sets up WSL2, installs the tool inside it, and recommends WezTerm:

./install.ps1 -Role device -Hub <your-hub-host>   # or -Role spoke

Then drive the fleet from WezTerm into WSL with devf.

iPhone

The native DevMux iPhone app is a SwiftUI fleet client with a terminal, files, screenshots and session controls. It communicates with the hub over HTTPS/WSS, not SSH. You do not install the spoke tooling or devf on your phone.

  1. Ask your hub owner for the currently supported app build and installation invitation. TestFlight distribution requires an invitation; an App Store submission does not mean a public listing is available. Use only the distribution link supplied for your build.
  2. Obtain your hub's native-client connection address and a device-scoped access token. The owner creates the grant on the hub with devf enroll ios <device-name> and shares it privately. Do not use the hub operator token or copy credentials from another device.
  3. Open DevMux. Enter that hub address and paste the scoped token into the onboarding form, then connect. The app validates the protected fleet before saving the credential in Keychain. A browser's Cloudflare sign-in does not sign the native app in; if the supplied public address redirects the app to a login page, ask for the owner's supported private HTTPS endpoint and connect Tailscale first. Do not disable the hub's access controls.
  4. Confirm your codebases load, open a session, and verify its identity before typing. Settings lets you replace the saved token when your owner supplies a new grant; merely visiting Settings does not erase it.

Push notifications and Live Activities are disabled in the current v1 release. Enabling iOS notification permission alone does not enable them. They require a separately provisioned app build, APNs configuration on the hub, and real-device delivery verification.

If the app says unauthorized, ask the owner to check or replace this phone's grant. If it says unreachable, check the supplied address and your network/Tailscale connection. Do not interpret either message as an empty fleet.

An SSH client remains an optional alternative for terminal-only use with a reachable hub; it is not the native app's installation path:

ssh <your-hub-host>
devf next so

Sessions remain in tmux on the machine where they run; disconnecting a client does not end that work. This is tmux-backed sessions with automatic reconnect, not a special always-on tunnel.

What connects to what

Every convenience tier — cockpit, phone, glasses — is additive. The fleet is fully drivable from the smallest tier alone.

Next steps