Skip to content
use-cases / fastest-send-me-that-file / hero
PIPE · SHARE STREAMS · FILE TRANSFER

The fastest 'send me that file' you've ever typed

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.

use-cases / fastest-send-me-that-file / flow

One pipe path. Two curls. No middle file.

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.

pipe.containers.hoody.com/dump-yesterday
PUT · SENDERyou

Push the file out of curl

# 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.

GET · RECEIVERthem

Pull the file straight to disk

# 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.

n=1 · default 1-to-1 transferpipe waits up to 5 minutes0 bytes stored on server

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.

use-cases / fastest-send-me-that-file / steps

What it looks like in real time

From the Slack ping to the file landing on their disk — the four moves the pipe makes happen.

Slack ping → file on their boxFOUR STEPS · ONE PIPE
10:14 · PING01

Teammate asks for the file

“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.

10:14 · PUT02

You curl -T the file out

curl -T dump.sql …/pipe/dump-yesterday

Your terminal prints “Waiting for 1 receiver to connect…” and sits there. You paste the URL into chat: “run that.”

10:15 · GET03

They curl the URL in

curl …/pipe/dump-yesterday > dump.sql

The pipe establishes the moment they connect. Bytes start streaming from your disk through the pipe into the file on theirs.

10:15 · DONE04

File on their box, nothing left behind

Transfer complete · 0 bytes on server

Server-side disk usage stays at zero. The pipe path forgets the transfer happened the moment both sides disconnect.

use-cases / fastest-send-me-that-file / reasons

Why a curl beats a share

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.

NO UPLOAD

There is no progress bar to watch

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.

NO LOGIN

No account, no folder share, no IT ticket

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.

NO RESIDUE

Server stores zero bytes — ever

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.

use-cases / fastest-send-me-that-file / punchline

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.

  • no upload
  • no link to share
  • no login on either side
use-cases / fastest-send-me-that-file / replaces

What this replaces

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.

  • DropboxSign-in, manual share, wait for sync
  • Google DriveFolder permission ticket through IT
  • Slack file uploadsHard cap on size, then “please use a real link”
  • WeTransferEmail gates, ad pages, mystery retention windows
  • AirDrop (across networks)Same-Wi-Fi only, fails the moment you're remote
  • Firefox SendGot shut down, never came back
  • Custom file sharesSelf-hosted box, bucket, and a forgotten cron to expire it
use-cases / fastest-send-me-that-file / cta

Two curls. The file's on their box. Nothing was ever uploaded.

use-cases / fastest-send-me-that-file / related

Read the others