Hosting bb remotely

Verdict

Yes — and you almost certainly should not rent a server to do it.

bb already ships the exact thing you described. The server and the thing that runs your agents are separate processes that talk over an outbound WebSocket. You can move the server, or you can leave it where it is and just publish it. The second is one command and costs nothing.

Two facts drive everything below:

• The daemon dials the server. Your laptop needs no inbound port, no public IP, no port forwarding. NAT is a non-issue.
• The bb HTTP API is unauthenticated. From the docs: it “permits command execution and file reads”. A bb server on a public IP is a remote shell on your laptop for anyone who finds it. This single fact rules out the naive “put it on a free VPS with a domain” plan.

Option A — bb connect (recommended)

Server stays on your laptop. getbb.app hosts the tunnel gate. Your bb dials out, gets https://<handle>.getbb.app, and access is gated on your getbb.app session — not a public link.

1. Claim a handle at getbb.app and copy the pairing command.
2. Run it: bb connect --code <code> --server https://<handle>.getbb.app
3. Open the URL from anywhere.

The tunnel is a builtin plugin’s background service, so it lives as long as the bb server runs and re-establishes on restart. bb connect status to inspect, bb connect off to unpair, bb plugin disable connect to cut all remote access.

Bonus: bb connect expose <port> from inside a thread shares a dev server at https://<label>--<port>.getbb.app, same account gate.

Cost: zero servers. What you avoid: a VPS, TLS certs, a reverse proxy, an auth layer, OS patching, and a second copy of your state to back up.

Option B — Tailscale Serve

If you would rather not depend on getbb.app, keep bb on loopback and publish it inside your own tailnet:

tailscale serve --bg --https=443 http://127.0.0.1:38886
bb-app config set BB_APP_URL https://<machine>.<tailnet>.ts.net

Free for personal use. Tailscale ACLs are the access boundary. Works on your phone. Never expose this through Funnel — that puts the unauthenticated API on the public internet.

Option C — actually host bb-server on a free VPS

This is what you literally asked for, so here is the honest version.

The package ships a standalone bb-server entrypoint and a standalone host-daemon. So:

1. VPS: run bb-server. Node 22.19/24/26, git, and native builds for better-sqlite3, node-pty, @parcel/watcher.
2. Make the server reachable — pair bb connect on the VPS, or Tailscale Serve on the VPS. Do not use --server-bind-host 0.0.0.0 on a public box.
3. Open that reachable URL, Settings -> Machines -> Add machine, run the generated one-liner on your laptop. It installs a host-only daemon under ~/.bb-machines/<server-host>/ with its own systemd user unit, joins, and never touches your existing ~/.bb.
4. Projects, threads, and terminals now target --machine <your-laptop>.

Resource envelope is small: your entire ~/.bb is 17 MB today. Node is the constraint, not bb.

Free tiers that actually fit an always-on Node process with a persistent disk:

• Oracle Cloud Always Free — Ampere ARM, up to 4 vCPU / 24 GB, real block storage, no sleep. The only free tier with headroom to spare. Capacity in popular regions is often unavailable; expect retries.
• Google Cloud free e2-micro — 1 GB RAM, US regions only. Enough to run bb-server, tight for compiling the native modules. Build elsewhere or add swap.
• Render / Railway / Fly free tiers: skip. Sleeping services, ephemeral disks, or no free tier at all. A sleeping bb server drops the daemon connection and loses the SQLite state.

Verify current terms before committing; free-tier rules move.

Why Option C is probably not worth it

• Your laptop still has to be awake and online for any agent to run. Moving the server does not make bb work while the laptop is closed.
• You still need bb connect or Tailscale for browser access — the VPS does not remove that step, it duplicates it.
• You gain a second host to patch, a second bb to keep version-matched, and a second SQLite database to back up.

It earns its keep in exactly one case: you want threads to keep running against a repo that lives on an always-on box while your laptop is off. That is not “point the server at this computer” — that is moving the work itself, and the answer there is to enroll the VPS as the execution machine and check the repo out there.

Security notes

• Never --server-bind-host 0.0.0.0 on anything with a public IP. Never Tailscale Funnel. Both put an unauthenticated command-execution API online.
• Each machine has a permission ceiling (maxPermissionMode, default Full Access), settable only from Settings -> Machines by an owner session. If a remote server drives your laptop, lower your laptop’s ceiling.
• Provider credentials stay on the machine that runs the agent. Hosting the server elsewhere does not move your Claude/Codex logins off the laptop.
• Every paired device (desktop app, phone, execution machine) consumes a getbb.app machine slot and is individually revocable from the dashboard.

Recommendation

Run Option A today. It is one command, it is the supported path, and it gives you the phone and remote-browser access you were after. Revisit Option C only if you decide you want agents running while the laptop is off — and at that point host the checkout, not the server.