Show HN: Bucket – Encrypted file sharing for people who live in the terminal

[bucket_]

I built this because I am perpetually drowning in file transfer hell.

As a systems engineer, I am constantly moving massive files. Whether it's getting new releases of custom ISOs to clients, downloading entire filesystems to spin up clones, or uploading massive support packages to L3.

I always have to get something to somebody. Usually, it's something large that lives on a headless server. I can't tell you how many times I've modified my 'clone' script to tar most of a filesystem over ssh ("hello --exclude, my old friend...") just to get 10GB that someone will need for two days.

Tedious is an understatement.

And the truth is, whatever I am sending, it is ephemeral. I download it, I upload it, I delete it. They download it only to delete soon after.

I kept wondering - why isn't there a simpler tool that works where I spend 90% of my time -- the terminal? I wanted something that I could install quickly on whatever server I was currently connected to, and run a simple command to push to the cloud.

Enter Bucket – a secure, encrypted file sharing platform that works the way I do. I upload from the CLI, share with a link and unique secret, done. No browser required (unless you want it). The people you're sharing with can simply click the link you share to download, no need for them to make an account (unless they want it).

What makes it different:

- CLI-first: Built for terminal workflows first, web UI second

- Encryption: End-to-end AES-256 encryption. We never see your files or your secrets. The secret generated during a push is required for the pull, keeping your data private even from us. If you lose the secret, you can't access the file.

- Simple scalability: Free tier for trying it out, plans up to 250GB for serious use, enterprise coming soon.

- File retention: Bucket is designed for ephemeral storage. Upload things that people need now. Free tier keeps files for 3 days (email notifications are sent to you before they are deleted, in case you need to upload again)

Colleagues I have introduced this to tell me they use it every day. I know that I do.

Free tier gives you 3 GB to try it out - enough for most one-off transfers.

Here's the workflow:

    $ bucket push api.bin
    Verifying upload...
     Upload complete!

    bID: bkdf1e848ea23e
    bURL: api.bucketlabs.org/d/bkdf1e848ea23e
    Secret: 9b1e15167403a88cadb7d0f4d2890856
    Expires: 2026-01-28T03:15:18.277988Z
 

Now you have a link for your browser-dwellers to simply click, paste the Secret and download. (go ahead, try on the link above to download the readme.md)

... but if the person you're sharing with has bucket installed they simply run:

    $ bucket pull bkdf1e848ea23e
    Enter secret: 
    ⠇ Downloading...
    Downloaded: api.bin

Check your file:

    $ bucket list 
    ID               Filename             Size         Expires
    ----------------------------------------------------------------------
    bkdf1e848ea23e api.bin              204.2 MB      2026-01-28T03:15:18.277988Z

    $ bucket account 
    Account Info
    ------------
    Subscription: free
    Used: 204.2 MB
    Quota: 3.00 GB

    To increase storage limits, visit:
    https://bucketlabs.org/auth

Everyone you needed to pull have the file? Go ahead and delete:

    $ bucket del bkdf1e848ea23e
    Deleted: bkdf1e848ea23e

Built in Go. Single static binary, works anywhere. Download at bucketlabs.org

[bucket_]

Update: Just squashed a race condition in the OTP worker that was affecting some early logins. If you had trouble an hour ago, try again! Source has also been updated on Git repo to align with the latest release - thanks to mdmelo for reporting that.

[cbenson0707]

How does this compare to something like magic-wormhole?

Is the CLI able to write to stdout (to pipe into other commands, like tar/ssh) ?

[bucket_]

Great question. Magic-wormhole is perfect for live 'hand-off' sharing, and there are plenty of use cases where that’s exactly what you need. I've used it too many times to count.

The difference here is mainly architectural. Wormhole follows a more traditional P2P sharing workflow and is strictly synchronous — it requires the receiver to be connected at the same time to complete the handshake. Bucket is completely asynchronous and state-agnostic: recipients don’t have to be online or even install anything to receive a file. They can simply click the link your CLI generates and enter the secret key (within the file expiration period).

Your question about writing to stdout is also a good one. Currently, the CLI (client.go) forces a write to disk, but I am actively working on stdin/stdout support. It will land in a release soon. The intent is to support commands like:

    $ bucket pull --secret "$SECRET" bkdf1e848ea23e | ssh rocky@10.10.10.2 "cat > redhat92_minimal.iso"

    $ ssh rocky@10.10.10.2 "tar zcvf - /var/ /etc/ /usr/" | bucket push --filename="10.10.10.2_backup.tgz"

[dripNripple]

Love it!! Easily helped me move some large files! Super easy to use as well.

[breadhat91]

how are you handling the encryption keys? is it encrypted client-side before upload or handled on the backend?

basically, if your db gets breached can someone access my decrypted files?

[bucket_]

A database breach wouldn't compromise your files because we never store the secrets needed to access them.

When you start an upload, the API generates a unique bID and secret, then provides a short-lived presigned URL. Your file transfers directly from your terminal to S3—it never passes through our servers. Once the upload completes, the bID and secret are returned to your CLI.

The secret is immediately discarded by our backend. Only its cryptographic hash is stored in our database.

[lurkersince2013]

Wait, but where’s the file encryption happening?

[bucket_]

In the current release, files rely on S3's server-side encryption. The bID + secret function as access control mechanisms rather than encryption keys. The zero-knowledge aspect refers to us never storing the secrets themselves - only cryptographic hashes - so we can't authorize downloads even if our database is compromised.

I've been actively working on adding client-side encryption to the CLI so files are encrypted by the binary before upload. The CLI implementation is ready, but I'm working through aligning the web dashboard with these changes. Should have it deployed in the next few days.

[Svan16]

Timesaver and easy to use