
Sixty containers on one server
One bare-metal box runs dozens to hundreds of Hoody containers. KSM and BTRFS dedup make the marginal cost near zero.
Slack rejects it. Drive needs a folder share request. Email caps at 25 MB. Two curls — one on your laptop, one on theirs — move the file from disk to disk. The pipe routes the bytes through; nothing is ever uploaded to a server.
GET and PUT the same path. The Hoody Pipe holds whichever side connects first for up to five minutes; once the other side shows up, bytes stream straight through. Nothing is written to disk on the server.
# from your laptopcurl -T dump.sql \ https://pipe.containers.hoody.com/api/v1/pipe/dump-yesterday[INFO] Waiting for 1 receiver to connect…[INFO] Streaming to 1 receiver…[INFO] Transfer complete.
PUT (or POST) with a streaming body. The server prints status lines back as the pipe establishes — useful as a live signal that the other side actually picked up.
# on their boxcurl \ https://pipe.containers.hoody.com/api/v1/pipe/dump-yesterday \ -o dump.sql# 4.2 GB · saved · done.
GET on the same path blocks until the sender connects. The bytes the sender writes appear as the response body — pipe to a file with -o, or to stdin of any program that reads.
Order doesn't matter. If you run curl first, the request blocks until they connect. If they run curl first, theirs blocks instead. Either way, the moment both sides are connected, the bytes start moving.
From the Slack ping to the file landing on their disk — the four moves the pipe makes happen.
“can you send me the prod dump from yesterday?”The file is 4 GB. Slack rejects it, the shared drive needs a folder-share ticket. You stop reaching for either.
curl -T dump.sql …/pipe/dump-yesterdayYour terminal prints “Waiting for 1 receiver to connect…” and sits there. You paste the URL into chat: “run that.”
curl …/pipe/dump-yesterday > dump.sqlThe pipe establishes the moment they connect. Bytes start streaming from your disk through the pipe into the file on theirs.
Transfer complete · 0 bytes on serverServer-side disk usage stays at zero. The pipe path forgets the transfer happened the moment both sides disconnect.
Same number of commands you'd type for a Drive round-trip — minus the login, minus the upload bar, minus the link, minus the cleanup.
Hoody Pipe is a streaming intermediary, not a file service. The file exists on your disk and on theirs. In between, it's just bytes in flight at whatever speed your two networks can sustain — the pipe just forwards.
Pipe paths require no auth on the public deployment. They're addressable URLs scoped to a single transfer; once both sides disconnect, the path is gone. Nothing for the receiver to sign up for.
The transfer never lands on disk on the server. Nothing to clean up, nothing to leak, nothing to expire. The bytes are on your laptop; then they're also on theirs; the path forgets it ever existed.
Two curls. No login. No upload bar. Done.
“Send me that file” used to mean a tab, a sign-in, an upload, a link, a paste, a download. Now it means: type curl, paste the URL, run curl. The fastest version of this you'll ever type.
Most of the tools we used to send a 4 GB file are leftovers from when we couldn't stream bytes between two terminals over HTTP. The pipe makes them all unnecessary.
Two curls. The file's on their box. Nothing was ever uploaded.