flyer

Share a single HTML file, or a PDF, at a short public link. No account, no API key, nothing to install. The link expires on its own.

One command
npx flingflyers report.html --persist
https://flingflyers.com/p/x7Kp2mQ   (copied to clipboard)
persisted · 4210 bytes · expires 2026-08-01T09:14:00.000Z

That is the entire product. You made an HTML file; now someone can open it in a browser on another device without you sending them the file.

Needs Node 22 or newer. Zero dependencies. Nothing to sign up for.

Which interface you want

There is one question, and it decides everything else: can you run a command?

You have a shell

Use the CLI. Terminal, coding agent, CI, anything with npx. Nothing to install or connect, and it is the only route that can encrypt.

You don't

Use the connector. Claude on a phone or in a browser has no shell, so a remote MCP server is the only way to publish from there.

Command line
npx flingflyers page.html --persist          # host for 7 days, print the link, exit
npx flingflyers page.html                    # serve live from this terminal
npx flingflyers page.html -e --persist       # encrypted; the key stays in the link
cat page.html | npx flingflyers - --persist  # read from stdin

Hosted, or live

Hosted (--persist) uploads the file and exits. The link keeps working with nothing running. Seven days by default, --ttl 24h|7d|30d, thirty days maximum. This is almost always what you want.

Live (no flag) stores nothing on the server. The process stays in the foreground and answers each visitor from the file on disk, re-reading it every time — so you can edit and refresh. Ctrl-C kills the link. Good for a demo you are still changing; wrong for anything someone opens later.

A live link can become a hosted one at any point and the URL does not change. That is the part worth knowing: you can share the link first and decide later whether it should outlive your terminal.

Scripting

--json prints exactly one JSON object on stdout and nothing else. Errors go to stderr with exit code 1.

$ npx flingflyers report.html --persist --ttl 24h --json
{"id":"x7Kp2mQ","url":"https://flingflyers.com/p/x7Kp2mQ","mode":"blob",
 "encrypted":false,"sizeBytes":1204,"expiresAt":1752950000,
 "expiresAtIso":"2026-07-19T18:33:20.000Z","host":"https://flingflyers.com"}

Afterwards

flingflyers lslist your flyers and their state
flingflyers revoke <id>kill a link now
flingflyers persist <id>re-upload after editing, and reset the expiry
flingflyers resume <id>reconnect a live host

There are no accounts. Ownership is a token in ~/.config/flyer/pastes.json, so these only work from the machine that created the flyer.

Connector

For anything without a shell. Add this as a custom connector in Claude and publish_flyer becomes available in any conversation, on any device.

https://flingflyers.com/mcp

Streamable HTTP, no authentication, no account. Three tools: publish_flyer, update_flyer — which revises a page you already published without moving its link — and revoke_flyer. Listed in the MCP registry as com.flingflyers/flingflyers.

The connector publishes plain flyers only. Your document reaches the server as text, so the encryption key cannot be created on your machine — which is the only thing that makes it worth having. For an encrypted flyer, run the CLI locally.

HTTP

If you are not on Node and don't want a connector. Nothing to authenticate to create a flyer.

POST   /api/pastes                {"encrypted": false} → {id, ownerToken, urls}
POST   /api/pastes/:id/persist    body = the bytes; Authorization: Bearer <ownerToken>
DELETE /api/pastes/:id            Authorization: Bearer <ownerToken>
GET    /p/:id                     the flyer

ownerToken comes back once and is the only proof of ownership. Keep it if you want to revoke or update later.

Agent-readable version of this page: /llms.txt.

What it will not do

Encryption with -e means the file is encrypted on your machine and the key travels in the part of the URL browsers never send to a server. So the host stores ciphertext it cannot read. But the host also serves the code that decrypts, so the honest claim is an honest host can't read your content — not that a malicious one couldn't. And anyone you give the full link to can read it.