Fleet: a Team-Hub on a VPS

Your laptop doesn’t have to be the only machine running askTheodor — a headless copy on a server keeps your workforce producing around the clock.

What you’ll learn

• The two kinds of instance: Command Center vs Team-Hub.
• How to start a hub headless and pair it to your desktop.
• Why a hub can run flat-out yet never spend money or send anything.

1. The two kinds of instance

• Command Center — your normal desktop app, with every screen. It’s the cockpit you steer from, and the only place money is spent and outreach is sent.
• Team-Hub — the same binary started with asktheodor --runner, with no window, usually on a rented VPS. Nobody sits at it; it runs your workhorse workers 24/7. This is the paid “remote” add-on.

2. Start it headless

On the server, launch the runner once by hand and tell it where to keep its data:

asktheodor --runner --data-dir /srv/asktheodor

The first run creates the database, applies migrations, and downloads the built-in embedder model. To survive reboots, install it as a systemd service so it auto-starts and restarts on failure.

3. Pair it into your Fleet

A runner is just another peer. From your Command Center, open Fleet (or Settings → Peers), add the VPS by its host/tunnel URL, complete the pairing handshake, and grant a scope — sync, delegate, or full. Once paired, the hub appears live, its workspace mirrors via sync, and it accepts delegated work.

A hub never touches money and never sends

A Team-Hub has no payment tools in any allowlist, and its channels are draft-only. A worker told to “send this email” prepares the draft and nothing more — running headless, its approval gate auto-denies anything that would leave the machine. The actual send happens later, from a Command Center.

Keep the cockpit, scale the floor

Put your Reviewers, Critics, and Judges on the Command Center; let Researchers, Developers, and Writers grind on the hub. The split is the safety model — every consequential action funnels back through a human.

What a 24/7 hub is actually for

A hub only makes sense when work benefits from continuing while you’re not there. Three cases where it does:

Long jobs that outlive your working day. A research sweep across dozens of sources, or a Plan with a dozen dependent tasks, doesn’t have to finish before you close the laptop. You brief it at six, the hub keeps advancing it overnight, and the deliverables are in the Library by morning — with everything consequential still waiting for you.

Monitoring that has to keep watching. A watch-folder Routine or a scheduled check is only as reliable as the machine it runs on. On a laptop that sleeps and travels, “every morning at eight” is aspirational. On a hub, it’s true.

Drafting overnight, deciding in the morning. Because a hub’s channels are draft-only and its approval gate auto-denies anything outbound, it can prepare a night’s worth of replies and produce exactly zero consequences. You wake to a queue of decisions rather than a set of actions already taken.

The trade you’re making

It’s €10/month per instance, plus your own server, plus the provider tokens the work consumes — and it adds a machine to maintain. It’s worth it when work genuinely needs to continue without you; it isn’t worth it just to feel busy. If your Routines run fine while your laptop is open, you don’t need a hub yet.

Recap

A Team-Hub is askTheodor headless on a server, paired to your Command Center, syncing and producing 24/7 — but structurally unable to spend or send. Next, we point a worker the other way: outward, at your visitors.

📖 Reference in the docs: Deploy to a VPS · Fleet

➡️ Next: Kiosks: a public-facing agent