Remote Development from Any Browser with blit.sh and moo

I wrote this for a good friend of mine to explain how I have started using two new tools made by pcarrier.com

---

For years, remote development has meant one of two things: a bare SSH session in a terminal emulator, or a heavyweight solution like VS Code Remote or a cloud IDE that drags an entire editor stack across the wire. Two newer tools — blit and moo — suggest a third path. Run your tools on the remote machine, and reach all of them through a browser tab.

The pairing works because the two tools solve complementary halves of the problem. Blit streams terminals (and, experimentally, GUI apps) to any browser with low latency. Moo gives you a browser-based workbench for coding agents — chat, diffs, tool traces, and persistent memory — running against the repositories on whatever machine it's installed on. Put both on a remote box and you have a complete development environment: an AI agent doing the heavy lifting in moo, and real terminals in blit for everything else.

What blit is #

Blit describes itself as a terminal multiplexer and experimental Wayland compositor for browsers and AI agents. It's a single binary with no required dependencies. The core trick: it runs your PTYs on the host and streams delta-compressed updates to a WebGL renderer in the browser, so a terminal in a browser tab feels close to native.

Three features matter for remote development.

First, sharing over WebRTC. blit share prints a URL you can open from anywhere — or hand to a teammate for real-time access to the same terminal. Because it's WebRTC, it punches through NAT without SSH keys or port forwarding.

Second, named SSH remotes with auto-install. You register a remote once, and blit installs itself on the far end the first time you connect. The remote machine only needs curl or wget and CA certificates.

Third, terminals as an API. Scripts — or AI agents — can start processes, send keystrokes, wait for output patterns, and read screen contents as text. This is what makes blit more than a fancy SSH client; it's a programmable surface for automation.

What moo is #

Moo, by Pierre Carrier, is a local-first agent harness you drive from a browser UI and inspect while it works. Under the hood it's a Rust host embedding a V8 runtime for TypeScript tools, with SQLite for durable state. On top, a Solid-based web shell shows chat, timelines, diffs, tool calls, and memory side by side.

The design choices that stand out:

• Scratch worktrees. Each chat gets an isolated worktree with git or jj context, so agent changes stay quarantined from your main checkout until you decide to keep them.
• Inspectable everything. Tool calls, memory snapshots, and source views are all first-class in the UI. You watch the agent work rather than trusting a summary.
• Durable memory. Moo stores RDF-based facts you can assert, retract, patch, and query — globally or per project — so context survives across sessions.
• Provider-agnostic. It coordinates credentials for OpenAI, Anthropic, Qwen, GLM, xAI, DeepSeek, and Kimi.

Moo is explicitly not a hosted service. It's built for local agents, on the theory that local privileges matter: the agent works with direct filesystem and process access inside workspaces you configure. That sounds like the opposite of remote development — until you realize "local" just means local to wherever moo runs.

The recipe: local-first tools on a remote machine #

The pattern is simple: install both tools on the remote machine (a VPS, a homelab box, a beefy workstation at the office), then reach their browser UIs from wherever you are.

1. Install on the remote host #

SSH in once, then:

curl -sf https://install.blit.sh | sh
curl -sf https://moo.pcarrier.com/install | sh

Both installers drop a single binary. (On Windows, the PowerShell equivalents are irm https://install.blit.sh/install.ps1 | iex and irm https://moo.pcarrier.com/install.ps1 | iex.) Note that blit's full feature set — including the Wayland compositor for GUI streaming — is Linux-only; macOS and Windows get PTY multiplexing.

2. Register the remote with blit on your laptop #

Install blit locally too, then teach it about your server:

blit remote add dev ssh:[email protected]
blit remote set-default dev

From now on, blit --on dev terminal list shows what's running on the server, and blit open gives you a browser interface to it. Blit auto-installs on the remote on first connect, so if you skipped step 1 for blit, this handles it.

3. Start moo on the remote #

On the server:

moo serve

This starts the workbench UI. Since moo binds locally by design, tunnel the port over SSH from your laptop:

ssh -L 8080:localhost:8080 [email protected]

(Substitute whatever port moo serve reports.) Open the forwarded port in your browser and you're in the workbench — chat, diffs, and tool traces for agents running against the repos on your server, with all the privileges of a local process there.

4. Work #

A concrete session looks like this. In one tab, moo's workbench: you start a chat from a project directory, moo creates a scratch worktree, and the agent begins making changes you can watch as diffs and tool calls. In another tab, blit: real terminals on the same machine for running tests, tailing logs, or poking at anything the agent shouldn't touch.

Blit's scripting surface even lets you close the loop between the two. Kick off a long build and block on the result:

blit terminal start -t build make -j8
blit terminal wait 1 --pattern 'BUILD OK'
blit terminal show 1

An agent — moo's or anyone else's — can drive that same interface: start a process, wait for a pattern, read the screen. Your terminals become tools the agent can use, with you watching over its shoulder in the same browser.

5. Share when you need another pair of eyes #

When you want a colleague to look at something, don't screen-share a video of a terminal:

blit share

Send the URL. They get the actual terminal, live, in their browser — no accounts, no SSH keys, no VPN.

Using moo for local web development with 11ty #

The recipe above treats moo as a remote tool, but its home turf is your own laptop — and static site work is a perfect fit. My site runs on Eleventy, and an 11ty project is exactly the kind of codebase an agent workbench shines on: lots of small, legible files (Nunjucks templates, Markdown content, a config file), fast builds, and instant visual feedback.

The workflow: run moo serve on your laptop, open the workbench, and start a chat from the site's project directory. Moo creates a scratch worktree, so the agent's experiments never touch your working checkout. Then hand it the kind of tasks that eat an afternoon when done by hand — porting a theme's layouts to Nunjucks (I've been converting Ghost's Headline theme this way), wiring up @11ty/eleventy-img for responsive images, restructuring front matter across dozens of posts, or writing a collection filter you've been putting off.

Because moo's tools include process access, the agent can run the build itself:

npx @11ty/eleventy --serve

You watch the tool calls and diffs in one pane while the dev server output streams in another. When the changes look right in the diff view — and in the live preview at localhost:8080 — you merge the worktree. When they don't, you throw the worktree away and nothing happened.

The durable memory is the underrated part for site work. Assert facts like "layouts live in _includes," "posts use the post tag," or "image shortcodes go through eleventy-img" once, and every future chat starts already knowing your site's conventions instead of rediscovering them.

Using blit for remote web development with 11ty #

The same 11ty project works from the other direction too: keep the site building on a remote machine and drive it through blit. This is handy when your laptop is underpowered, when the site's asset pipeline is heavy, or when you just want a build that keeps running after you close the lid.

Start the dev server in a named blit terminal on your remote:

blit --on dev terminal start -t site npx @11ty/eleventy --serve
blit --on dev terminal wait 1 --pattern 'Server at'

The wait command blocks until Eleventy prints its "Server at" line, which makes this scriptable — a deploy script or an agent can start the server and know exactly when it's ready. blit open gives you the terminal in a browser tab from anywhere.

One clarification worth being explicit about: blit streams terminals, not HTTP. To see the rendered site, tunnel Eleventy's port alongside your session:

ssh -L 8080:localhost:8080 [email protected]

Now the terminal lives in a blit tab and the live preview lives at localhost:8080, both fed by the remote machine. And when you want a second opinion on a template bug, blit share hands a collaborator the actual terminal — they can scroll your build errors themselves instead of squinting at a screenshot.

Using moo for local document and transcript conversion #

The third use case has nothing to do with web servers: moo as a harness for the document-conversion toolchain I use to make teaching materials and podcasts accessible.

The underlying tools are the usual command-line suspects. On a Mac:

brew install ocrmypdf tesseract poppler exiftool pandoc

plus OpenAI's Whisper for transcription. Over time these have accreted into a small set of scripts (mine live in ~/github/personal/scripts):

• ocr-a11y-pdf.py — runs scanned PDFs through OCRmyPDF and Tesseract so they carry a real text layer. A scanned reading that a screen reader sees as blank images becomes a searchable, readable document.
• pdf-to-html.py — converts PDFs to HTML (via Poppler and pandoc), because for many students HTML is simply a better format than PDF: reflowable on a phone, zoomable without horizontal scrolling, friendlier to assistive technology.
• pdf_markdown_conversion_script — the same idea aimed at Markdown, which makes course readings easy to excerpt, annotate, and republish on an 11ty site.
• apple-m1-transcribe.py — runs Whisper transcription locally on Apple Silicon, so every podcast episode and recorded lecture gets a transcript without shipping audio to a cloud service.

Each script is simple on its own. The tedium is in the batches: a semester's worth of scanned readings, a back catalog of podcast episodes. This is where moo earns its place. Point a chat at the scripts directory, and the agent can run the tools as processes — OCR this folder of PDFs, transcribe these twelve episodes, convert the results to HTML, fix the metadata with exiftool — while every invocation and its output stays inspectable in the timeline. When a file fails (and one always fails), you can see exactly which command choked and why, rather than excavating a log file.

The accessibility framing is the point, not a bonus. A course reading that exists only as a crooked scan excludes students who use screen readers; a podcast without a transcript excludes Deaf and hard-of-hearing listeners, and everyone who'd rather skim than listen. Transcripts and true-text documents also make material searchable, quotable, and translatable. These conversions are exactly the kind of work that gets skipped because it's tedious — and exactly the kind of work an inspectable local agent, with private access to your files and no cloud upload, is suited to grind through.

Why this combination works #

The deeper appeal here is architectural. Both tools reject the model where your development environment lives inside someone else's cloud. Blit is a single dependency-free binary; moo requires no hosted backend. Everything — code, agent memory, terminal state — stays on hardware you control. The browser is just a viewport.

That inverts the usual trade-off of remote development. Traditionally you gave up locality (and often privacy) to get access-from-anywhere. With blit and moo, the machine doing the work keeps full local privileges — moo's whole premise — while you keep access from any device with a browser. The "remote" in remote development stops meaning "diminished."

A few caveats. Blit's Wayland/GUI streaming is explicitly experimental, and its full feature set assumes Linux on the server. Moo is young and moving fast (moo upgrade will be a regular habit). And because moo grants agents real filesystem and process access, treat the machine it runs on accordingly — a dedicated dev box or VM, not your production server.

But as a sketch of where remote development is heading — agents in one tab, terminals in another, everything running on your own machine, reachable from anywhere — this pairing is the most convincing one I've tried.

Links #

• blit: https://blit.sh · https://github.com/indent-com/blit
• moo: https://moo.pcarrier.com/ · https://github.com/pcarrier/moo