Dashboard · project · MCP hub

The same window, start to finish.

This is Rig. Every part of your project in one list: what is running, which port it is on, which database it uses, and what just fell over.

rig / client-portal / processeslive

client-portal4marketing-site1billing-api2

Process	Port	Status
web (vite)	:5173	Running
api (hono)	:3000	Running
queue worker	none	Exited 1
scheduler	none	Stopped

2 of 4 running

3 processes up
Logs streaming
:3000 claimed
⌘K everything
Cursor linked via MCP
Live Link active
Postgres managed
Valet site open

The gut-punch

Before: six terminal tabs. After: one board.

A terminal tab is a text window where a program runs. Most projects need several, and nobody tells you when one quietly stops.

Before · six terminal tabs

tab 1 · npm run dev: which port did it take?
tab 2 · php artisan queue:work: died an hour ago
tab 3 · docker compose up: the error scrolled away
tab 4 · lsof -i :3000: again
tab 5 · tail -f laravel.log
tab 6 · …the one you forgot about

After · one board

Every process started in health order
One merged log stream that survives a restart
Ports owned, so you never run lsof again
A crash becomes a suggested fix
⌘K reaches anything

Works with

Fits round the tools you already use.

Rig does not replace your editor, your database or your web server. It sits around them and keeps them running.

AI editors

Cursor
Claude Code
Codex
Copilot CLI
OpenCode
Pi
OpenClaw
Antigravity
LM Studio
Hermes
Windsurf
VS Code

Local stacks

WordPress
Laravel + Valet
Node / Vite
Procfile
Composer / PHP
Docker Compose

Optional cloud

Job 1 · Start your project

Boot the whole stack in the order that actually works.

Your project is several programs that depend on each other; Rig finds them all and starts them in the right order with one click.

One click boots the group. Health-checked, in order.

You drop in the project folder. Rig finds the Procfile, the package.json scripts, the artisan sidecars and the Compose services (the lists of programs your project already describes). A group is one click: Vite, API, Postgres and the queue start in health-aware order, which means each part waits until the one it needs is really up. Not the order you remembered to open tabs.

New Project can scaffold from a template, clone, or detect what is already there. Start, stop and restart each process on its own. The board remembers what was up. Scripts detected, port owned, Cursor linked for this project.

Procfile + npm / pnpm / bun discovery
Project groups: one click boots everything
Start / stop / restart per process
Health-aware start order
New project wizard: folder, template or clone
WordPress and Laravel scaffolds when you want them

01 · Run

rig / acme-stack / grouplive

Process	Port	Status
postgres	:5432	Running
api	:8787	Running
web (vite)	:3000	Running
queue	none	Running

Group up · 4 of 4 running, in order

04 · PHP / Laravel

Laravel is a first-class citizen, not a sidecar you forgot.

Composer and Laravel are detected. Valet's *.test web address sits on the project with an Open site button. Queue, Horizon and schedule run as artisan sidecars (the helper programs a Laravel app needs): started with the group, logged with everything else, restarted when they die.

It sits beside Valet or Herd. Rig is the control plane, not a replacement PHP runtime.

Composer + Laravel detection
Valet *.test URL + Open site, e.g. client-portal.test ↗
Artisan sidecars: queue, horizon, schedule, reverb
Tails laravel.log into the same stream

Laravel + Valet →

WordPress · shipped

Local WP without a LEMP VM.

No need for a virtual server just to run WordPress. New Project → WordPress sets up MySQL, php -S, trusted HTTPS and a fresh install. Or point it at an existing wp-config folder and it detects the stack.

It coexists with Local and Valet: no takeover. When the client needs eyes on it, mint a Live Link. MCP can inventory themes, plugins, page builders and Woo from the same hub.

One-click install + Copy admin login
Docker MySQL sidecar when you need it
{slug}.localhost with HTTPS that actually trusts
Coexists with Local / Valet, no takeover

WordPress in Rig →How detection works →vs Local →Download →

Job 2 · See what is happening

One log stream. Kept across restarts.

Every message from every part of your project lands in one place, so when something breaks you can see why.

When checkout breaks, you should not be searching four windows.

Every service streams into one pane, with a colour tag for each and a filter. The lines are still there after you restart the sidecar that died. The attention board lights up, and you get a native notification if you walked away.

Ports live next to the logs, so you see who claimed :3000 without opening Activity Monitor. Laravel's log tails into the same stream as Vite and the queue. That is the whole point of a control plane.

Unified live log stream, colour tags, filter and search
Logs kept across restarts
“Explain this error” agent assist
Attention board: HTTP health, crash loops, ports, dependencies
Menu bar status + native “needs attention” notifications

02 · Observe

rig / client-portal / logslive

webGET /checkout 500 · 38ms

apiPOST /orders → calling payments

laravel[error] Payment gateway timed out

queueSendReceipt job failed · exited 1

rigqueue crashed · restarting it for you

queuerunning again · logs kept from before

One pane for every process.

Rig 1.1.0 project screen: run script and lane, CPU, memory and health, and every process with its port — The real project screen in Rig 1.1.0: run script, lane, health and every process with its port.

Job 3 · Stay in control, fix what breaks

Ports, lanes, env. ⌘K for the rest.

Rig owns the ports, keeps each setup's settings apart and tries to repair a crash itself before it asks you.

Who owns the port, and the button that takes it back.

A port is the numbered door a program listens on, like :3000. When an old program is stuck on yours, that is a button in Rig, not a folklore command. Reclaim it from the board, no more lsof.

Lanes keep branch, env, port and worktree together, so this morning's review does not collide with yesterday's API. Env (your settings and secret keys) is masked per lane: client keys stay out of the default stack. Git status sits on the project. The command palette reaches anything, and if you live in a terminal, $ rig up ships with the app.

Port ownership + reclaim
Lanes: branch · env · port · worktree
Masked env manager per lane (local / staging / production)
Git branch and status per project
⌘K command palette
rig CLI: rig up and friends

How a full stack boots →

03 · Control

rig / portslive

:5173web (vite)Running

:3000node · left over from yesterday

:5432postgresRunning

Something else is sitting on port 3000.

07 · Services & recovery

It tries to fix itself first.

Setup diagnose plus one-click fixes for the boring stuff. Managed local Postgres and Redis when you do not want another Docker ritual. A crash is parsed into a suggested fix loop, not a red badge you ignore. Parse the crash, suggest the fix, and do not paste a stack trace into Slack.

Sparkle keeps both chips current, Apple silicon and Intel, while you work.

Setup diagnose + one-click fixes
Managed local Postgres / Redis
Crash parse → suggested fix loop
Sparkle auto-updates, both chips

In the product

Health that is not just curl.

“Running” in Rig means more than “the program started”. It checks the site really answers, spots a process stuck in a crash loop, and notices when a database it needs is missing. You see that next to the logs, on the computer it actually runs on.

Job 4 · Show your work

Send someone a link to the site running on your computer, then switch it off the moment you are done. No deploying a copy anywhere.

10 · Profiles & community

Show your work.

If you want to, show people what you build. A public profile is optional.

Public @handle on userig.app/u
Members directory + follow graph
Dev DNA: the last 90 days of local activity
Community forum sign-in (bugs and ideas)

Profiles

Community

Talk to the people who make it.

Report a bug, ask for a feature, or see what others are building with Rig. Your Rig account signs you in.

Community

Job 5 · Let your AI assistant help

95 tools. Live runtime. Not a pasted shell.

AI assistants like Claude and Cursor can check what is running and read the errors through Rig, instead of guessing from what you paste in.

Link the hub once. The editor sees what is up, what crashed, who owns the port.

MCP is the standard way AI assistants plug into tools. Rig's hub listens only on your own computer (127.0.0.1) with a scoped token. Cursor, Claude, Codex, ChatGPT or any MCP client call tools against what is actually running: create a project, inventory WordPress, open Adminer on loopback, mint a Live Link, compose up, git, env, wake a machine. Instead of inventing kill -9.

You choose how much it may do: full, control, or read. Rotate the token and every editor unlinks. Source never leaves your computer; the agent sees process state. That story has its own page because it is the reason people stay.

Full · control · read blast radius
Create · groups · Compose
wp_inspect · page builders · Woo · Adminer
Live Link · wake · screen · remote restart
Activity log of every call

create_project
wp_inspect
open_adminer
share_live_link
compose_up
diagnose_crash
wake_device

AI & MCP story →Cursor MCP →Setup docs →ACP for Zed and JetBrains →

06 · AI & MCP · the differentiator

rig / mcp hub / activitylive

cursorget_status client-portal → 3 up, 1 down

cursorget_logs queue --tail 50

cursordiagnose_crash queue → ECONNREFUSED :5433

cursorrestart_project queue · waiting for your OK

youApproved

rigqueue running on :5432 · call logged

Every tool call, logged. Writes wait for your yes.

Rig 1.1.0 Connections: the MCP hub, linked editors and per-project agent access — Connections in Rig 1.1.0: the MCP hub, your linked editors, and agent access set per project.

Job 6 · Work across machines and teams

Every machine on one catalog. Lose the laptop, not the setup.

Optional extras for when you have more than one computer, or more than one person; everything above works without them.

08 · Cloud & teams

Who is running what, without hiring someone to babysit the fleet.

Optional cloud gives you a fleet view of every computer with CPU, memory and update status. Remote start, stop and restart on the machine that owns the project. Shared catalog, seats, roles, activity. Passkeys and 2FA on the account; Touch ID / Face ID on Mac. The Network tab is Live Links plus who can actually be reached.

For teams →Cloud →

Fleet view: CPU / mem / update status
Remote start / stop / restart on an assigned machine
Bulk restart every machine on a catalog project
Shared catalog, seats, roles, activity
Passkeys + 2FA for Cloud; Touch ID / Face ID on Mac
Network: Live Links + device reachability

09 · Continuity

Lose the computer, not the setup.

Continuity is an encrypted backup of your Rig setup, never your source code. It runs daily or weekly while Rig is open. Restore on a new computer, then Teleport the folders across. You keep a recovery key that looks like RIG-CONT-7Q2M-····-····; it is shown once.

Cloud and Continuity →

Encrypted backup of your Rig setup, never source
Daily / weekly schedule while Rig is open
Restore on a new computer, then Teleport folders
Secrets vault stays end-to-end encrypted

11 · Private mesh

Your machines on one network.

Your computers build an encrypted device-to-device network wherever they are. Your range, your names, nothing to configure.

Encrypted device to device, wherever they are
Your range, your names
Nothing to configure

How Mesh works

12 · Wake & Screen

Wake the other machine. Then screen in.

A sleeping machine is not an offline machine. Wake a closed lid through another machine on that network, then screen in with Apple's own screen sharing, over the mesh, not a random SaaS desktop. From chat, the agent can list devices, wake one, or restart a catalog project on every machine that owns it.

Wake through another machine on that network
Then screen in over the mesh
Apple’s own screen sharing

How it works

13 · Addresses & rules

Write the firewall in English.

A firewall decides which machine may talk to which. In Rig you write it as a sentence: Macs tagged studio can reach mini on 51820. Not a JSON file you will get wrong at 11pm.

Pick your range
Name every machine
Macs tagged X can reach Y on Z

Tags and rules

In the product

Procfile + sidecars, one log pane.

More of the board, on the computer it actually runs on: the Procfile and every sidecar it starts, and one log pane for all of them, whichever machine you are on.

Get Rig

Rig 1.1.0 Machines: every Mac in your fleet with its mesh address, Rig version, stacks and remote actions — Machines in Rig 1.1.0: every Mac with its mesh address, Rig version, stacks and remote actions.

Spec sheet · shipped, not roadmap