A zero-dependency, single-file Go pastebin built for terminals — burn-after-read by default, two independent encryption layers, and a curl one-liner instead of a login form.
I keep ending up in situations where I need to move a small piece of text — a log snippet, a password, a container's stdout — from one machine to another, and the clipboard just isn't there.
SSH session on a remote box.
A locked-down corporate laptop that won't let me touch the OS clipboard at all.
A container with no shared volume and no browser.
Slack is right there, but pasting a database password into a channel that's archived forever is a special kind of bad idea.
So I built CPYNET — a paste-sharing tool with exactly one interface that matters: .
That's the whole thing.
No account, no API key, no clicking around.
Two calls and you've moved text between two machines that have nothing in common except a network path.
Burn-after-read, actually The paste above is gone the instant that second runs.
Not "gone in 24 hours" — gone the moment it's read, whether that's one second later or one minute later.
Read it twice (even from the same machine) and the second request gets a plain .
It also auto-expires on a timer (2 minutes by default) even if nobody ever reads it, so an unread secret doesn't just sit there.
None of this lives on disk.
It's a Go behind a mutex, in memory, for the lifetime of one process.
Restart the server and every paste that hasn't been read yet is just... gone.
That's not a limitation I'm working around — it's the actual point.
A "burn after read" tool that persists to disk somewhere you're not thinking about isn't really burning anything.
The shell functions, if you don't want to remember the curl flags That wires up two functions, and : also drops the text on your clipboard if it can find a way to (////) — pure convenience, never required.
Both functions are plain shell, both talk to the exact same HTTP endpoints the web UI uses.
There's no separate "API" to keep in sync with the "real" product — the curl pipe is the product.
Two encryption layers, for two different threat models Password protection ( / ) is AES-256-GCM with a key derived via PBKDF2 (210k iterations — OWASP's current minimum).
The server decrypts the text for a moment to verify the password, then re-encrypts it at rest.
This is "I trust the server, I just don't want it sitting there in plaintext" — protects against a disk dump or a backup leak, not against the server operator.
True end-to-end encryption (the shield icon, or ) is a different thing entirely: the key is generated client-side and never sent to the server at all.
On the web it's WebCrypto AES-256-GCM with the key living in the link's fragment — browsers never send fragments to a server, by spec, so it physically can't leak that way.
On the CLI it's with a random passphrase printed on its own line, deliberately never appended to the URL.
Two independent implementations, neither required to interoperate with the other, both landing on the same guarantee: the server only ever sees ciphertext.
What actually makes this "zero dependency" has one line: .
No router package, no ORM, no crypto library beyond in the standard library, no frontend build step — the HTML/CSS/JS are Go string constants rendered with , and static assets like screenshots are ded straight into the binary.
The whole server is one file.
That's not a purity flex.
It means: You can read the entire thing in an afternoon.
No dependency tree to audit, no transitive CVE to track down at 2am. produces one static binary on .
No shell in the final image, no package manager, nothing to exploit even if something got in.
It doesn't rot.
There's no running against a pile of frontend packages six months from now.
A few other things it does QR code for the link — scan it with a phone camera, it opens and decrypts right in the browser.
Generated by a small dependency-free QR encoder that runs entirely client-side; nothing gets sent to a third party to render a