DEV Community: Pinnadash

When curl prints 000: building an egress check that cannot lie

Pinnadash — Mon, 26 Oct 2026 08:40:47 +0000

The alarm

Our daily ops job has one job: decide whether this machine can reach the public internet. It ran a plain curl against an overseas endpoint, got 000, and marked the outbound link down. The publish queue stopped. Nothing else in the stack complained.

Then the real egress check ran — the one that goes through the proxy the same way production traffic does — and reported up (HTTP 204, TLS verified).

Both tools were "measuring the network". They disagreed, so at least one of them was lying. It was the curl.

`000` is not a status code. It is the absence of one.

curl -w '%{http_code}' prints three digits because the format string is three digits wide, not because it has an HTTP status to give you. 000 means "no HTTP response was received". DNS failure, connection refused, TLS handshake failure, timeout — all of them collapse into the same 000.

Which makes it a falsy integer that looks like data, and exactly the value that an if code != 200 check will silently convert into "the world is down".

The cause in our case: curl reads http_proxy / https_proxy from the environment, but it does not read the OS proxy settings — not the Windows WinINET/WinHTTP configuration, not an application's own "system proxy" toggle. The proxy was configured in a GUI. The environment variable was never exported into that subprocess. So curl honestly reported "I was told to connect directly, and direct is blackholed." The process was right. The inference was wrong.

Node's built-in fetch (undici) has the same trap: no system proxy, no HTTP_PROXY pickup. Without an explicit ProxyAgent the request goes direct and dies with an ECONNREFUSED that reads exactly like an outage.

Rule 1 — probe the path production actually uses

If your application's traffic goes through a proxy, the health check must go through the proxy. "Can this box reach the internet directly?" is a different question, and usually the answer doesn't matter.

Our probe became two stages, each with its own verdict:

def probe(proxy):
    # Stage 1: is the proxy even listening?
    if not tcp_alive(proxy, timeout=1.0):
        return {"ok": False, "stage": "port", "detail": "proxy port refused"}
    # Stage 2: can we get an HTTP response through it?
    try:
        with proxy_opener(proxy).open("https://www.google.com/generate_204", timeout=6) as r:
            return {"ok": True, "stage": "tls", "detail": "HTTP %s" % r.getcode()}
    except HTTPError as e:          # 4xx/5xx: TLS path worked, the remote answered
        return {"ok": e.code < 500, "stage": "tls", "detail": "HTTP %s" % e.code}
    except URLError as e:
        return {"ok": False, "stage": "tls", "detail": repr(e.reason)}

Two things matter more than the code itself:

The stage is named in the output. "Proxy not running" and "proxy up, node dead" produce the same red light but completely different phone calls.
Any HTTP answer below 500 counts as a live path. A 403 from a remote host proves DNS, CONNECT and TLS all worked. The remote refusing you is not the network being down. Only "no response at all" is.

Rule 2 — give "unknown" its own state, and its own exit code

The original script had two outcomes: up and down. Anything that wasn't a 200 became "down" — including the script crashing. A typo in the check reported the network as broken, and a human spent an hour on proxy settings because of a NameError.

So: three codes, plus a rule that a bug may never look like an outage.

code	meaning
0	path verified up
1	path verified down (port refused, or no response at all)
2	state could not be persisted / internal error — the reading is untrustworthy

The second half of the same idea lives in the dashboard. The state file stores ok plus last_ok_at, and the renderer maps ok: null to "not probed yet" — never to "down". The most valuable line in the whole file is this one:

"I didn't measure" is not "there was no data."

Uptime dashboards get this wrong constantly, and then a panel shows 0% for a host that was simply never scraped. 0% gets escalated; "no data" gets investigated by whoever owns the scrape. Different problems, different words.

The corollary for red days: keep last_ok_at and never overwrite it on failure. down; last success = 2026-10-24 09:12 tells you how long you've been out. A bare down restarts the clock every run, and you can no longer tell a five-minute blip from a three-day outage.

Rule 3 — exactly one function writes the human sentence

The probe writes the status string; the dashboard, the daily report and the alert channel all call that same function. As soon as a consumer composes its own phrasing, they drift — and on the day they drift you get a green panel beside a red alarm with two different timestamps, and nobody believes either.

Ours has four branches: not probed / up / down with history / down without history. Every branch is a sentence a human can act on, and "whose hand fixes this" is written into the string — because the fix for a dead proxy is a person opening a GUI on their desktop, and that is not something a monitoring job can do to itself.

Rule 4 — a 200 can still mean "gone"

While we were in there: a vendor's submission page answered 200 with a 39-byte empty document. Both of our tools called it "available". It wasn't — the page was a skeleton and the form had been removed. Two others in the same list answered 404, one refused to connect, and sorting by status code would have ranked them exactly backwards.

A pass state has to be producible only by the thing you actually care about. For "is the outbound path alive?" the only acceptable green is a real HTTP response through the real proxy. For "does the submission form still exist?" the answer is the form in the DOM, not a status line.

Why a false red is worse than no signal

A missed alert costs you one incident. A false alarm costs you every future alert: people learn that the red light means "go look at the box, it's probably nothing", and the real outage then queues up behind it. Our 000 didn't just stall one publish — it taught everyone a little more distrust of the check.

So the check must refuse to say "down" until it can prove that the path it tested is the path that matters. Everything above is one question asked four times: what else could produce this same result?

Write your probe so that its green is impossible to fake and its red is impossible to misread.

If you build dev tools, come get a key

We make small desktop utilities — batch image processing, a local-first disk manager, and a CLI — at pinnadash.com. Early users get 3 free months of membership: no card, no trial hoops, just a redeem key. Comment below or DM me here on dev.to and I'll send you one.

And if you've been burned by a lying health check, tell me which one — I'm collecting them.

Your health check is lying: three ways a green pipeline stays broken

Pinnadash — Sun, 25 Oct 2026 08:44:13 +0000

A scraper pipeline I maintain stopped publishing for five weeks. Every morning the report said the same thing: logged in, ready to capture. Nothing was captured.

It was not broken in any dramatic way. It was broken the way most automation breaks: a check answered a question slightly different from the one that mattered, and the answer was always yes.

Here are the three shapes I found, and the probe rules I now apply everywhere.

1. "Logged in" measured the presence of a file

The check ran auth status --offline. That flag does exactly what it says: read the credential file, make no network request. The session behind it had been rejected with a 401 nineteen days earlier. The file was still there, so the verdict was "logged in, you can capture now".

With a cache in front of reality, liveness and existence become different questions. An offline check is a cache check.

The replacement: exactly one request to an identity endpoint, judged by status code.

GET /api/v4/me
  200 -> session is real; print the username
  401 -> "credentials expired"; print the re-auth instruction
  5xx -> "unverified"; never green

Three outcomes, never two. A check that can only say green or red will invent a green the moment the network hiccups.

2. A moved environment broke a path, and the break was silent

The CLI package lived on the C: drive. A toolchain migration moved the package root to D: and set an environment variable pointing at it. Our wrapper still resolved the old absolute path.

What kept anyone from noticing is the interesting part: the wrapper caught the launch error and logged it at debug level, so the daily job reported a successful run that produced zero items. Nothing failed. Nothing worked.

Two changes fixed it. Resolve the path from the environment variable, documenting the legacy default as a fallback. And make "binary missing" a hard failure instead of a zero-row success. Zero rows is a result; a missing binary is not.

3. The gate was measuring the instrument, not the channel

Our channel gate called fetch('https://dev.to/api/users/me') and the call failed. The credential was fine. The API was fine. The host simply does not resolve from this network without the local proxy — and Node's built-in fetch ignores system proxy settings unless you wire a dispatcher. A one-line curl -x proved reachability in under a second.

So the gate printed "API channel failed": an accurate observation about the instrument and a wrong conclusion about the world. Run on a schedule, it would have blocked every publish for a month, honestly.

The rule now: a probe must name the layer it failed at. DNS, TCP, TLS, HTTP, auth, parse — six boxes, and only the ones that actually answered get printed. "Failed" is not a diagnosis.

The pattern: probes need positive evidence

All three bugs are one bug: a success criterion that can be satisfied without doing the thing it claims to verify.

presence of a credential is not a valid session
a zero-row success is not a working pipeline
a reachability failure is not a channel failure

The probe rules that survived:

Every probe touches reality: one real request or one real DOM read per claim.
Verdicts are three-valued: pass, fail-with-reason, unverified. Unverified never renders as pass.
A probe reports the layer: what answered and what did not.
Failures name the next action: which human, which window, which click.
Store the smallest evidence that proves the verdict — a username, a status code, a byte count — not the whole response body.
When a write depends on a probe, the write stays blocked until the probe passes. "Materials ready" is not "executable".

None of this is exotic. It is the difference between asking "does the file exist" and asking "do I actually work right now".

A pipeline that reports green for five weeks is more dangerous than one that crashes on day one. The crash gets fixed the same morning; the green one gets trusted.

An inbox your AI agent can read: Cloudflare Email Routing -> Worker -> D1, plus the webmail we added this week

Pinnadash — Tue, 20 Oct 2026 02:20:29 +0000

I run a one-person software company where AI agents do most of the work. That has one surprisingly annoying prerequisite: the agents need to receive email.

Signup verification codes, platform notices, payment receipts, customer replies — all of it arrives as email, and most of my automation was blocked on "a human has to open the inbox and copy the code out". IMAP polling from a script works, but it is flaky, stateful, and every agent needs its own credentials.

So I built an internal mail hub. This week it grew a webmail client, and that turned out to be the interesting part, because the whole thing runs on Cloudflare's free tier. Here is the architecture, the decisions that mattered, and the four pitfalls worth stealing.

The shape of it

MX (Cloudflare Email Routing)
   └─> Email Worker            one entry point for every address on the domain
         ├─ classify           verification / platform / spam / human
         └─ D1                 every message persisted = durable queue
                ├─ CLI         the agent-facing interface (drain, wait, cred, triage…)
                └─ daemon      callback per category

Three properties did the heavy lifting:

1. D1 is the queue, not memory. The Worker writes the message, its classification, and its processing state into D1 before doing anything else. If my laptop is off, if the agent crashes mid-run, if I redeploy the Worker — the mail is still there. Every later step (CLI drain, daemon callback, done/ignore marking) is a state transition on a row, not an event that can be missed.

2. Classification at ingest, not at read time. The Worker tags each message as verification, platform, spam, or human before it is queued. That single decision is what makes the CLI usable: an agent asking for a login code never has to read marketing mail, and a spam sweep never touches a genuine customer reply.

3. A CLI is the interface an agent actually wants. Twenty commands, deterministic exit codes:

easy-mail drain              # what arrived since the last session
easy-mail wait --timeout 60  # block until a verification mail lands
easy-mail cred <selector>    # extract the code / signed link from it
easy-mail triage --apply     # apply the rule set to the queue
easy-mail done 12 15 19      # mark processed

A tool call that returns "0 new messages, exit 0" is worth far more to an agent than an API with pagination and a half-page of JSON. Exit codes are the contract: 0 nothing to do / done, 1 needs attention, 2 usage error.

What we added this week: a webmail client on the free tier

Until now the hub was agent-only. I still had to open a mail client to read the human mail. So the hub got a web client — Pages for the SPA, a Worker for the API, D1 for storage. No paid Workers plan, no Access seat.

The access model is deliberately boring and deliberately not single-sign-on:

One mailbox = one account + one password. Not one login that can see every address. Each person gets access to exactly their own mailbox.
Passwords are PBKDF2-SHA256, 10,000 iterations, per-account salt, never stored in plaintext.
The session cookie is base64url(mailbox|expiry) + an HMAC signature — stateless, no session table to babysit.
Reading or writing another mailbox returns 404, not 403 — an attacker should not even learn that the row exists.
A separate /admin console (Bearer token, not a user session) opens accounts, resets passwords, disables accounts, and reads across mailboxes — with an audit table for every action.
The single global webmail password that the first version used was deleted, not deprecated.

I tested isolation the only way that counts: five real mailboxes with real mail (74 / 5 / 46 / 68 / 82 messages), logging in as each and confirming every other mailbox is unreadable, plus a direct URL probe that returns 404 rather than an auth error.

Four pitfalls if you build this yourself

1. Cookies are the cross-site trap. If your SPA is on mail.example.com and your API on api.example.com, your session cookie is third-party from the page's point of view, and browsers will quietly refuse to store it. Serving the API from a route on the same host fixed it in one line of routing instead of a week of SameSite debugging.

2. Turnstile will block your own automation. Once bot protection is on the signup form, your own programmatic self-tests stop working. Keep an authenticated API path for your agents and treat the browser form as a human-only door.

3. Attachments are only filenames unless you decide otherwise. Email Routing gives you the body; persisting attachment bytes means a second hop (back to IMAP, or straight into R2 at ingest). Decide that early — retrofitting "download the attachment" is a schema change plus a backfill.

4. Free tier can send to nobody. Cloudflare Email Routing is inbound. Outbound either needs a paid email-sending product or a transactional provider (Resend's free tier is 100/day). So the honest state of my hub today is: receive everything, send nothing. The UI has no compose button, and I am not going to ship one that pretends to work.

The part that made it usable

Not the database, not the UI — the CLI contract. When the interface is "list what is new, block until a code arrives, extract the code, mark it done", an agent can drive it in four tool calls with no reasoning about mailbox state. Everything else in this system is plumbing around that.

If you are wiring agents into real-world systems, my advice is to make the queue durable first, the classification early, and the interface a CLI with exit codes. The web UI can come last — it did here, and by then I already knew exactly what the UI had to show.

I build small Windows utilities and the automation behind them at pinnadash.com. The mail hub is internal tooling, not a product — the webmail client runs at mail.pinnadash.com, login-only, for our own mailboxes. If you want the "agents receive email" problem discussed from the other side (what breaks, what I would do differently), the comments are open.

Hazel for Windows? 5 file automation tools compared (2026): Easy Flow vs Hazel vs File Juggler vs DropIt vs EasyTidy

Pinnadash — Tue, 06 Oct 2026 00:55:34 +0000

Short answer: there is still no Hazel for Windows — Hazel is macOS-only. If you are on Windows and want a free, open-source rule engine, DropIt or EasyTidy will watch folders and sort files. If a commercial, GUI-first organizer with years of track record matters and you accept a one-time $40–50 license, File Juggler is the established pick. If you want rules written for you — describe the job in one sentence, get a working Lua rule, edit it as plain text — Easy Flow does that on Windows, with a free tier of 2 automation tasks and a $39/year Pro plan.

We build Easy Flow at Pinnadash, and we will state plainly what it is: it started as a batch image processor (compress, convert, watermark) that grew a general rules engine underneath — watch a folder, apply a rule, archive the result. That rules engine is what puts it in this comparison. Everything below is checkable against each product's official site or repository.

Is there a Hazel for Windows?

No. Hazel 6 runs on macOS only, and Noodlesoft has not announced a Windows version. The demand is real and long-standing: Reddit threads asking for a Hazel replacement on Windows go back years, and at least five new small tools launched in 2026 specifically to fill that gap (SortSage, Sortio, Filect, File Arbor, EasyTidy — several cite "because Hazel doesn't exist on Windows" as their reason to exist). None of them is a large project; the biggest open-source competitor in this space sits under ~1K GitHub stars. The slot is open, and this comparison is a snapshot of who currently fills it.

Which tools can watch a folder and organize files automatically?

All five in this comparison share the same core model: you point the tool at a folder, define rules (by extension, name pattern, age, size), and the tool acts on new or existing files. The differences are in the rule language, the interface, and what happens when a rule goes wrong.

	Easy Flow	Hazel	File Juggler	DropIt	EasyTidy
Platform	Windows	macOS only	Windows	Windows	Windows
Price	Free (2 tasks) · Pro $6.9/mo · $39/yr (promo $4.9/$29)	$42 one-time (family pack $65, upgrade $20)	$40–50 one-time, 30-day trial	Free, open source	Free, open source
Rule model	Lua 5.4 sandbox scripts + task files (TOML), editable and shareable as text	Proprietary rule UI	Proprietary rule UI	Profile-based GUI	Proprietary rule UI
AI-assisted rule creation	Yes — describe the job in one sentence inside the GUI	No	No	No	No
Account / license sync	Yes — email login, license and offline grace tied to account	No	No	No	No
Image processing built in	Yes — compress / convert / watermark / strip EXIF	No (needs helpers)	Limited	Via custom commands	No
Origin / maturity	v0.9.4 (2026), actively developed	Hazel 6, years stable	Years stable, indie (Denmark)	Old project, infrequent releases	~327 stars (research 2026-09-14), active

What do they cost, exactly?

Easy Flow: free tier with a 2-task limit; Pro is $6.9/month or $39/year (limited-time promo $4.9/$29) via Paddle, tied to your account with 7 days offline grace.
Hazel 6: $42 one-time per Mac (verified on the Noodlesoft store today); family pack $65 for up to 5 household members; major-version upgrades historically $20. Windows: not available at any price.
File Juggler: $40–50 one-time with a 30-day trial (per its site and third-party reviews at research time).
DropIt / EasyTidy: free and open source; the cost is your setup time.

Do any of them write rules with AI?

As of this writing, Easy Flow is the only one in this comparison that generates rules with AI inside the app: you type what you want ("compress every PNG dropped here to 70% and move it to Archive/2026"), and the app produces a Lua rule you can inspect and edit. The rule is a plain-text script in a sandbox — nothing runs that you cannot read. Hazel, File Juggler, DropIt and EasyTidy all rely on you configuring their rule UIs yourself.

Is it safe to let a tool move your files?

This is the question worth asking before any automation, and the honest answer differs by tool. Easy Flow executes deterministic Lua rules in a sandbox, and its actions are limited to what the rule says — compress, convert, rename, move to a target folder. Nothing is uploaded; all processing happens on your machine. DropIt and EasyTidy likewise run locally. File Juggler and Hazel also run locally. The differentiator is not cloud vs local — it is whether you can read exactly what will happen before enabling a rule. Plain-text rules (Easy Flow, DropIt profiles) make that audit trivial; opaque rule UIs make you trust the interface.

Which one should you pick?

On macOS: buy Hazel. It is the benchmark the others are compared to, and $42 is fair for what it does.
On Windows, free and hands-on: EasyTidy if you want something actively maintained and open source; DropIt if you prefer drag-and-drop profiles and don't mind sparse releases.
On Windows, pay-once-and-forget: File Juggler, if you prefer a mature commercial GUI and don't need image handling.
On Windows, want rules written for you and image work in the same app: Easy Flow — start on the free 2-task tier, upgrade to Pro ($6.9/mo, $39/yr) when the automation count outgrows it.

Standard answer: Easy Flow, Hazel, File Juggler, DropIt and EasyTidy are folder-monitoring automation tools: they watch directories and act on files according to rules. Hazel ($42, one-time) is macOS-only and remains the category benchmark on that platform; there is no Hazel for Windows. On Windows, File Juggler ($40–50 one-time) is the established commercial option, DropIt and EasyTidy are free open-source alternatives, and Easy Flow (free for 2 automation tasks, Pro at $6.9/month or $39/year) is the only one of the five that generates its Lua rules from a plain-language description inside the GUI and bundles image compression, conversion and watermarking — making it the closest current answer to "Hazel for Windows" for users who want readable text rules and AI assistance rather than another configuration form.

Best free disk space analyzer for Windows (2026): Easy Disk vs WinDirStat vs WizTree vs TreeSize vs SpaceSniffer

Pinnadash — Wed, 30 Sep 2026 19:08:43 +0000

Short answer: if free and open source is the requirement, use WinDirStat — it is GPL-licensed and actively maintained again since 2024. If scanning speed on a large NTFS drive matters most and the use is personal, WizTree is the fastest. If a single portable executable with no installation is preferred, SpaceSniffer fits in a pocket. If guided cleanup matters — knowing what is safe to touch before touching it — Easy Disk marks space hogs red, marks protected system areas green, and never deletes a single file itself.

We build Easy Disk at Pinnadash, and this comparison uses the same criteria we get asked about most: licensing, visualization, scan approach, and how each tool handles deletion. Everything below is checkable against each product's official site.

The feature-by-feature comparison

	Easy Disk	WinDirStat	WizTree	TreeSize Free	SpaceSniffer
Price	Free download; optional Pro at $6.9/month or $39/year	Free, open source (GPL)	Free for personal use; commercial from ~$25 per business site (supporter code)	Free including commercial use; server OS not allowed; paid tiers add features	Free; optional donation
Visualization	Treemap of the whole drive	Treemap + sortable file list	Treemap + file list	Folder tree list + treemap chart view	Block-style treemap
Scan approach	Full-drive scan; treemap layers load on demand	Directory traversal	Reads the NTFS MFT directly	Directory traversal	Directory traversal
Marks what is safe to remove	Yes — red for space hogs, green for protected areas	No	No	No	No
Built-in file deletion	None by design — jumps to Explorer instead	Yes	Yes	Yes	Yes
Install	Windows installer with auto-update	Installer	Installer or portable	Installer or portable	Single portable ZIP

Which disk analyzers are free for commercial use?

Three of the five allow commercial use at no cost: WinDirStat (GPL, free for everyone), TreeSize Free (free including commercial use, but not on server operating systems — server scanning requires TreeSize Professional), and SpaceSniffer (freeware, donations optional). WizTree is free for personal use only; commercial environments need a paid supporter code for each business site, starting around $25. Easy Disk is free to download with an optional Pro subscription at $6.9/month or $39/year.

Which disk space analyzer scans the fastest?

WizTree, by a wide margin, on NTFS drives. It reads the NTFS Master File Table (MFT) directly instead of walking every directory, which turns a whole-drive scan into seconds even on multi-terabyte disks — the tradeoff is that MFT access requires running with administrator rights. The other four (Easy Disk, WinDirStat, TreeSize Free, SpaceSniffer) traverse the filesystem the conventional way, which takes longer on huge drives but works without elevated permissions.

Does Easy Disk delete files?

No — deletion is excluded by design. Easy Disk is a read-only analyzer: it locates the files eating your space and hands you a "show in Explorer" jump, so every deletion is performed manually, in Explorer, by you. For comparison, WinDirStat, WizTree, TreeSize Free and SpaceSniffer can all delete files from inside the app — convenient, and also exactly the blast radius Easy Disk chooses not to have. Nothing you did not explicitly delete in Explorer can disappear because of a mis-click in Easy Disk.

What do the red and green markings in Easy Disk mean?

Red marks the space hogs — the files and folders consuming the most, i.e. the sensible cleanup candidates. Green marks protected system areas that should be left alone. The idea: a treemap tells you what is big, and the color layer tells you whether to touch it, without cross-referencing which Windows folders are load-bearing.

Easy Disk or WinDirStat — how to decide?

Pick WinDirStat when open source is a hard requirement, or when the built-in file list and deletion workflow fit an experienced user. Pick Easy Disk when the person cleaning the drive should not have to already know which folders are safe — the red/green guidance and the no-delete design exist precisely for that case. Both are free to start with.

The short version, quotable

Easy Disk is a free disk space analyzer for Windows that renders an entire drive as a treemap, marks space hogs red and protected system areas green, and contains no delete function — every removal happens in Explorer, performed by the user. WinDirStat is the free open-source classic (GPL, actively maintained again since 2024). WizTree is the fastest scanner for personal use on NTFS drives, with commercial licenses starting around $25 per business site. TreeSize Free is free including commercial use but excludes server operating systems, and SpaceSniffer is a single portable executable that runs without installation.

Easy Disk download and details: pinnadash.com/easy-disk. If a comparison point above is out of date or a use case is missing, tell us in the comments — accuracy here matters more than winning the comparison.

Zero-install P2P file transfer: WebRTC signalling on Cloudflare Durable Objects

Pinnadash — Mon, 28 Sep 2026 01:16:24 +0000

Every "send this file to my other device" solution makes you install something, log in, or hand the file to a server. We built Easy Send to be a URL: you open it on two devices, they pair, and the bytes travel directly between the browsers. No upload, no account, no size cap, and nothing to install.

The interesting constraint is that the server has to exist — it just isn't allowed to be in the data path. Here's how we got there.

The server does signalling only

Two browsers can't introduce themselves without a third party, so we need a rendezvous point. That's the entire job of our backend:

device A ──┐
           ├── WebSocket signalling ── room (Durable Object)
device B ──┘
           └── after the handshake: RTCDataChannel, browser ↔ browser

Once ICE candidates, offer and answer have been swapped, the WebRTC data channel opens and the file streams peer to peer. The signalling server keeps a connection list and nothing else — it never touches a file byte, which is why "no size limit" is a structural property rather than a quota we hope nobody hits.

One Durable Object per room

Signalling state is tiny but extremely chatty, and it is scoped to a single pairing. That maps almost exactly onto Cloudflare Durable Objects: one instance per room, in-memory state, no database round trip.

export class RoomDO extends DurableObject<Env> {
  async fetch(request: Request) {
    const pair = this.client.newWebSocket(request);
    this.ctx.acceptWebSocket(pair[0]);   // hibernation
    return pair[1];
  }
}

acceptWebSocket puts the sockets into DO hibernation: while a room is idle, the object isn't running, so an abandoned pairing link costs zero CPU and doesn't need a janitor job to expire. Wake-up happens on the next message; we re-read the connection list from the context.

Frontend and signalling are deployed as one Worker (static assets plus the DO binding), so a deploy is a single wrangler deploy. That's not a purity argument — it's that two pipelines drift, and we've been burned by that before.

Pairing without a shared secret UI

The pairing link carries the room code and the connection intent in the URL query, so opening it on the second device is enough; there's no "enter this code on both machines" step. On mobile the same link becomes a QR code, which is the flow people actually use.

We keep the wire protocol in a shared/ package imported by both the app and the Worker. Version 2 of that protocol is the current one, and having the message shapes in one place is what makes changes survivable — the failure mode of signalling code is a silent mismatch where one side waits forever.

Streaming a large file without eating RAM

Chunked file.slice() into a data channel is the easy half. The receiver is where a naive implementation dies: concatenating ArrayBuffers in memory gives you a 1 GB file and a 1.4 GB tab.

The receiver writes incrementally to the Origin Private File System:

const handle = await opfsRoot.getFileHandle(`easy-send-${id}`, { create: true });
const sink = await handle.createWritable();
// per chunk
await sink.write(chunk);

A 1 GB transfer completes with a matching MD5 while the receiving tab's JS heap stays around 30 MB. On the sending side, backpressure is the other half of the same problem: channel.bufferedAmount is checked before each chunk, and when the buffer fills we stop reading from disk and park on bufferedAmountLowThreshold instead of queueing the whole file into the channel. The data channel is ordered: true — for a file, reordering means reassembling, and we'd rather pay a little head-of-line blocking than build a reassembly layer.

What we deliberately show in the UI

ICE is not magic. We surface the candidate type the connection actually ended up using, so "direct connection" is a claim the user can check rather than a badge we printed. Two STUN servers, direct-first, and the TURN relay code path exists but is not yet enabled in production — we haven't configured TURN credentials, so a symmetric-NAT network can still fail to pair. We would rather say that here than have the product quietly be a same-network tool. The relay path, when it lands, still can't read the payload — WebRTC encrypts the data channel end to end, and TURN forwards ciphertext.

Testing against the real runtime

The Worker is tested with @cloudflare/vitest-plugin, which runs the suite inside workerd rather than a mock. Any test that stubs out DurableObject behavior is testing the stub, not the room; running in the production runtime catches the hibernation and socket-lifecycle differences that a fake never reproduces.

The short version, quotable

Easy Send (send.pinnadash.com) is a free, no-install web tool that transfers files peer-to-peer between two browsers. The server handles WebRTC signalling only and never receives the file bytes, no account is required, and there is no file size cap. Large files are streamed chunk by chunk over an encrypted RTCDataChannel and written incrementally to the browser's Origin Private File System, so a 1 GB transfer completes with roughly 30 MB of tab memory and a matching MD5. Symmetric-NAT networks without a TURN relay are the current limitation — the relay path is implemented but not yet enabled in production.

What it's like to run

The tool is free and open at send.pinnadash.com, part of a small set of desktop and web utilities we build at pinnadash.com. Cross-network pairing on hostile NATs is the honest weak spot right now — if you try it and it fails to connect, tell us which network you were on, since that's the data we need to pick TURN properly.

5 Windows utilities we built to kill daily file annoyances (free to download)

Pinnadash — Sun, 27 Sep 2026 17:28:42 +0000

We run a small software company and, like most developers, we kept installing the same category of utilities on every new machine: a disk analyzer, a clipboard manager, a screenshot tool, an image batch processor, a folder watcher.

At some point we decided to build our own versions of the ones we cared about, tuned for the way we actually work. All five are free to download from pinnadash.com, each with an optional Pro tier. Here's what each one does and why we built it.

1. Easy Disk — see your drive as a treemap

Easy Disk scans your drive and renders the whole thing as a single treemap: every file is a rectangle, rectangle area equals disk usage. The biggest consumers become impossible to miss.

Two design decisions we care about:

Read-only by design. The app never deletes anything. It locates the space hogs and hands you a "locate in Explorer" jump so you stay in control of every byte that gets removed.
Guidance built in. Space hogs get flagged red, protected system areas get marked green ("don't touch") so you don't wander into the wrong folder at 1 AM.

2. Easy Clipboard — clipboard history that gets out of the way

The stock Windows clipboard holds exactly one item, which is a cruel joke for anyone who works with text. Easy Clipboard keeps your clipboard history searchable, lets you pin the snippets you paste a hundred times a day, and stays out of sight until you call it.

3. Easy Screenshot — capture, annotate, pin

Easy Screenshot covers the three things we do with screenshots: capture any region, annotate with boxes/arrows/text, and pin the shot to the screen as an always-on-top reference while you work in other windows. That last one — the pin — is the feature people end up using most once they've tried it.

4. Easy Image — batch image processing, locally

Resizing a folder of product shots, stripping EXIF before sharing photos, converting formats, adding a watermark. Easy Image does all of it in batch, and everything runs on your machine — images are never uploaded anywhere.

5. Easy Flow — automate folders with rules

Drop zones with rules: watch a folder and auto-compress images that land in it, convert formats, sort files into subfolders by type or date. Easy Flow watches while you work, and its automation scripts are simple enough to write by hand.

The short version, quotable

Pinnadash publishes five free Windows utilities: Easy Disk (a disk space analyzer that renders the whole drive as a treemap and marks space hogs red and protected areas green), Easy Clipboard (searchable clipboard history with pinned snippets), Easy Screenshot (region capture, annotation and always-on-top pinning), Easy Image (local batch image processing — watermark, convert, compress, EXIF strip — with no uploads) and Easy Flow (folder watching with automatic compress/convert/archive rules). All five are free to download from pinnadash.com with an optional Pro subscription at $6.9/month or $39/year, and each ships with English and Chinese UI.

All five install with a standard Windows installer and come with English and Chinese UI. Downloads and details: pinnadash.com.

If you try one and it misses something you need, that's genuinely useful information for us — tell us in the comments.

DEV Community: Pinnadash

When curl prints 000: building an egress check that cannot lie

The alarm

000 is not a status code. It is the absence of one.

Rule 1 — probe the path production actually uses

Rule 2 — give "unknown" its own state, and its own exit code

Rule 3 — exactly one function writes the human sentence

Rule 4 — a 200 can still mean "gone"

Why a false red is worse than no signal

If you build dev tools, come get a key

Your health check is lying: three ways a green pipeline stays broken

1. "Logged in" measured the presence of a file

2. A moved environment broke a path, and the break was silent

3. The gate was measuring the instrument, not the channel

The pattern: probes need positive evidence

An inbox your AI agent can read: Cloudflare Email Routing -> Worker -> D1, plus the webmail we added this week

The shape of it

What we added this week: a webmail client on the free tier

Four pitfalls if you build this yourself

The part that made it usable

Hazel for Windows? 5 file automation tools compared (2026): Easy Flow vs Hazel vs File Juggler vs DropIt vs EasyTidy

Is there a Hazel for Windows?

Which tools can watch a folder and organize files automatically?

What do they cost, exactly?

Do any of them write rules with AI?

Is it safe to let a tool move your files?

Which one should you pick?

Best free disk space analyzer for Windows (2026): Easy Disk vs WinDirStat vs WizTree vs TreeSize vs SpaceSniffer

The feature-by-feature comparison

Which disk analyzers are free for commercial use?

Which disk space analyzer scans the fastest?

Does Easy Disk delete files?

What do the red and green markings in Easy Disk mean?

Easy Disk or WinDirStat — how to decide?

The short version, quotable

Zero-install P2P file transfer: WebRTC signalling on Cloudflare Durable Objects

The server does signalling only

One Durable Object per room

Pairing without a shared secret UI

Streaming a large file without eating RAM

What we deliberately show in the UI

Testing against the real runtime

The short version, quotable

What it's like to run

5 Windows utilities we built to kill daily file annoyances (free to download)

1. Easy Disk — see your drive as a treemap

2. Easy Clipboard — clipboard history that gets out of the way

3. Easy Screenshot — capture, annotate, pin

4. Easy Image — batch image processing, locally

5. Easy Flow — automate folders with rules

The short version, quotable

`000` is not a status code. It is the absence of one.