Headless teamwork

The Vibetight desktop app is great when you want to see what the agent is doing in real time and your repo lives on your laptop. But laptops sleep. Laptops get closed. Laptops get carried into meetings.

For teams that want continuous coverage (or individuals who’d rather work while hiking) Vibetight also runs headless.

What “headless” means here

A headless Vibetight device is a regular Linux server running a small agent worker. Same pairing flow, same permission model, same board integration, just without a tray icon or a UI. The device shows up alongside your desktop devices in Settings → Devices, and agents on it are assignable from the web.

You install it once on a box you control:

• A long-running cloud VM (DigitalOcean, Hetzner, AWS, anywhere you have a Linux SSH login)
• A team dev server
• A dedicated build server with beefy compute
• A spot instance you spin up for burst capacity and tear down when idle

Why Linux only

Mac headless isn’t really a thing. Apple doesn’t license server-headless macOS, and Mac mini farms are an expensive workaround that doesn’t fit our cost model. Windows headless exists but is much rarer in cloud environments, and we’ve decided to wait for demand rather than ship a runtime we can’t test against real users.

Linux is the headless we’re building. If your team already has a fleet management story for Linux servers, headless Vibetight fits into it.

Typical team setups

The “one shared box” team. Two-to-four engineers, one fat dev server, three agents auto-pickup-enabled. Anyone on the team can drop work onto any agent from anywhere. Bills add up to one EC2 line item instead of one per engineer.

The “everyone has their own + a shared overflow” team. Each engineer pairs their laptop for fast-feedback work, plus a shared headless box for overnight or weekend runs. Everyone wins.

The “fully managed” team. No engineer pairs anything personally. Ops pairs a fleet of headless workers, sets up agents with auto-pickup, and engineers just drop tasks on the board. Closest to a “queue of work, pool of workers” SaaS model.

What you trade off

• You don’t see the agent’s screen. All interaction goes through the web UI: chat messages, tool calls, permission prompts. Most users find this better than watching a terminal, but it’s a difference.
• Your code lives on the worker. Headless workers clone your repo into per-task sandboxes. If that’s incompatible with your security posture, run on a worker you trust (your own VPC, your own VM).
• You’re responsible for the box. We don’t manage compute for you. The trade-off is full control over where your code runs and what touches it.

Combine freely

A team can run any mix: some desktop, some headless, some on subscription auth, some on API key. Tasks routed by the scheduler don’t care about device shape. The model is “give the work to whichever agent has a free slot and is allowed to run it.”