Skip to content
REAL-TIME STREAMINGNO STORAGE256 RECEIVERSPUT · POST · GETCURL-NATIVEFANOUTPROGRESS SSEE2E-ENCRYPTION READY
REAL-TIME STREAMINGNO STORAGE256 RECEIVERSPUT · POST · GETCURL-NATIVEFANOUTPROGRESS SSEE2E-ENCRYPTION READY
REAL-TIME STREAMINGNO STORAGE256 RECEIVERSPUT · POST · GETCURL-NATIVEFANOUTPROGRESS SSEE2E-ENCRYPTION READY
REAL-TIME STREAMINGNO STORAGE256 RECEIVERSPUT · POST · GETCURL-NATIVEFANOUTPROGRESS SSEE2E-ENCRYPTION READY
kit / pipe
PipeHOODY PIPE

Named Pipes Over the Internet

POST to a path. GET from the same path. Data flows directly from sender to receiver — no buffering, no uploads, no storage. Just HTTP.

View Documentation
pipe · live transfer

Terminal A — Sender

$ curl -T report.pdf \

…/pipe/my-report

[INFO] Waiting for receiver...

[INFO] Streaming to 1 receiver(s)...

[INFO] Transfer complete.

Terminal B — Receiver

$ curl \

…/pipe/my-report

-o report.pdf

% Total report.pdf

100 2.4M 100 2.4M 0 0 1.8M

Zero storage·Real-time streaming·Up to 256 receivers·5-min TTL
kit / pipe / how-it-works
HOW IT WORKS

Data Flows Through, Not Into

Every byte you send arrives at receivers in real-time. The server is a wire, not a warehouse.

SOURCE

sender

PUT / POST/pipe/{path}

PIPE SERVER

zero storage · up to 256 receivers

GET/pipe/{path}

SINK

receiver

01

Sender opens

Sender POSTs or PUTs to any path. The server waits — up to 5 minutes — for a receiver to connect.

02

Bytes flow through

Data streams byte-by-byte across the wire. Zero buffering. No temp files. No upload step.

03

Receivers connect

Receivers GET the same path and pull the live stream. Up to 256 receivers can fan out from one sender.

kit / pipe / recipes
RECIPES

Common Pipe Compositions

Most recipes are two curl commands — one to send, one to receive.

#1

File Transfer

Peer-to-peer delivery, no intermediary storage.

sender → receiver

$ curl -T report.pdf …/pipe/report

# curl …/pipe/report -o report.pdf

#2

Live Log Stream

Tail a container's logs in real-time from any terminal.

sender → receiver

$ tail -f app.log | curl -T - …/pipe/logs

# curl …/pipe/logs

#3

Screen Share

Stream desktop to up to 10 viewers. No WebRTC.

sender → receiver

$ ffmpeg … | curl -T - …/pipe/screen?n=10

# browser: …/pipe/screen?n=10&video

#4

Directory Sync

Pack, stream, and unpack a directory tree in one pipeline.

sender → receiver

$ tar czf - ./project | curl -T - …/pipe/proj

# curl …/pipe/proj | tar xzf -

#5

Encrypted Transfer

E2E encrypted — server never sees plaintext.

sender → receiver

$ openssl enc … < secret.doc | curl -T - …/pipe/enc

# curl …/pipe/enc | openssl enc -d …

#6

Fan-Out Broadcast

Distribute a build artifact to exactly 3 consumers simultaneously.

sender → receiver

$ curl -T build.zip …/pipe/release?n=3

# curl …/pipe/release?n=3 (×3 receivers)

#7

Progress Spectate (3-party)

Watch speed, ETA, and bytes without consuming a receiver slot.

sender → receiver

$ curl -T dataset.tar.gz …/pipe/ds (sender)

# curl …/pipe/ds + browser: …/pipe/ds?progress

kit / pipe / protocols
PROTOCOLS & CONTENT

What Can Flow Through a Pipe

Any Content-Type that isn't script-executable flows verbatim. Dangerous MIME types are rewritten to text/plain — data is not dropped, XSS is prevented.

application/octet-streamPUT → GET

Binary files, archives, images

/api/v1/pipe/[path]
text/plainPOST → GET

Logs, stdin, config, stdout streams

/api/v1/pipe/[path]
multipart/form-dataPOST → GET

Browser file upload (first part only)

/api/v1/pipe/[path]
video/webm, video/mp4PUT → browser

Screen share, recorded video

/api/v1/pipe/[path]?video
text/event-stream (SSE)GET spectator

Progress monitoring, speed/ETA/state

/api/v1/pipe/[path]?progress
text/html (rewritten)PUT → GET

Rewritten to text/plain before forwarding — XSS prevented, data not dropped

/api/v1/pipe/[path]
Custom headersPUT → GET

X-Hoody-Pipe, X-Piping metadata forwarded

/api/v1/pipe/[path]

All endpoints live on /api/v1/pipe/[path]. Direction describes who writes, who reads.

kit / pipe / limits
LIMITS

Built for Volume

Hard limits enforced per-server. HTTP 429 when capacity is full, HTTP 414 when paths are too long.

#1

256

Max receivers on a single path

#2

1,000

Pending unestablished connections

#3

1,000

Simultaneous in-flight streams

#4

5 min

TTL before HTTP 408 eviction

#5

1,024

Max path length in characters

#6

50

Progress spectators per path

kit / pipe / endpoints
API

9 Endpoints, Two Commands That Matter

POST or PUT to send. GET to receive. Everything else is observability.

Observability & UI

{count, plural, =1 {# endpoint} other {# endpoints}'}

GET /health → { status, activePipes }

GET
/api/v1/pipe/healthJSON: status, version, activePipes
GET
/api/v1/pipe/versionPlain text version string
GET
/api/v1/pipe/helpSelf-hosted curl examples
GET
/api/v1/pipeBrowser web UI for no-code uploads
GET
/api/v1/pipe/noscriptFallback UI for no-JS browsers
OPTIONS
/api/v1/pipe/{path}CORS preflight

Data Transfer

{count, plural, =1 {# endpoint} other {# endpoints}'}

POST or PUT to send · GET to receive

POST
/api/v1/pipe/{path}Send data; streams [INFO] status back to sender
PUT
/api/v1/pipe/{path}Alias for POST; natural for curl -T file
GET
/api/v1/pipe/{path}Receive data; blocks until sender connects
kit / pipe / cta

Two Curl Commands Away

No SDKs. No auth setup. No file size limits. Spin up a Pipe container and start transferring.

Read the Docs