Flit Devlog #4

Devlog #3 ended on software’s most dangerous sentence: it works great on my machine. This one’s about every other machine — a real flit command, a lock on the door, prebuilt binaries for three OSes, a copy on the open internet, and the devices with no terminal at all. Where Flit stops being my tool and becomes a tool.

A CLI that respects the pipe

The flit client is a thin wrapper around curl with opinions: flit "text", flit -f file, cmd | flit, flit -l. The stdin branch is my favorite — if the script sees it’s on the end of a pipe, whatever flows in becomes a drop, no flags, no quoting. So git log --oneline -5 | flit lands on my iPad before I’ve switched windows. Then I wrote the PowerShell sibling and relearned it isn’t “bash with different keywords”: headers are a hashtable, multipart a whole other ritual, and one missing dash cost me embarrassing time.

A lock for the door

Flit was wide open — fine on localhost, horrifying anywhere else. The rule: no FLIT_TOKEN, nothing changes; set it, and everything except /health demands it. The interesting part wasn’t whether to check a token but how you hand it over. A CLI sends Authorization: Bearer; but you can’t staple a header onto a QR code. So the middleware speaks three dialects — Bearer header, ?token=, or cookie — and when the token arrives by URL, the server upgrades it to a cookie so it doesn’t live in your address bar:

if from_query {
    if let Ok(v) = format!("flit_token={expected}; Path=/; HttpOnly; SameSite=Lax").parse() {
        res.headers_mut().insert(header::SET_COOKIE, v);
    }
}

Open the link once, authed from then on. I also turned the upload cap into a knob (FLIT_MAX_MB).

Three OSes, one tag

Push a v* tag and GitHub Actions builds on three native runners — ubuntu, macos, windows — while a fourth gathers the artifacts into one release. But three OSes means three sets of opinions: Windows insists on .exe, wants shell: bash spelled out, and each names its artifact differently so the release job merges them cleanly. None of it hard in hindsight; all of it a red X on the first try. v0.1.0 now ships Linux, macOS, and Windows binaries from one git tag.

Finding a home (the actual hard part)

Nobody says this: deploying was easy, finding where was the fight. My first pick ambushed me mid-signup with a credit-card wall on the “free” tier. Closed the tab, went to Render, which read the Dockerfile from the repo and worked first try — thanks to one patch: check PORT first, fall back to FLIT_ADDR, else 0.0.0.0:7777. Every platform injects PORT and expects you to listen on it; respect that one variable and the container runs anywhere, ignore it and you stare at “deploy succeeded” beside a site that never answers. Flit’s public face: https://flit-xw2a.onrender.com — open on purpose, drops expire in 10 min, uploads cap at 5 MB. The free box dozes when idle, so the first hit yawns before it wakes.

The last mile: devices with no terminal

The piece it was born for. My laptop has a shell; my iPad and phone don’t. Same trick on both — hijack the system share sheet so “Share → Flit” fires an HTTP request. On iPad that’s Apple Shortcuts; Android uses the open-source HTTP Shortcuts app — identical job. One mental model: the share sheet is the send button. A screenshot goes thumb-to-laptop with no computer in the middle — the entire point.

Where Flit stands

• Real-time receive — drops appear instantly (#2)
• Clipboard-direct — text/links hit your clipboard (#3)
• Auto-expiry — drops delete themselves on a TTL (#3)
• Send from anything — Linux/macOS/Windows CLI, any browser, iPad, Android

One binary, downloadable for three OSes, curl-able like a caveman or token-locked if you’re not, plus a live demo at https://flit-xw2a.onrender.com. That’s the build. Flit is shipped.