Show HN: S3mini – Tiny and fast S3-compatible client, no-deps, edge-ready
(github.com)257 points by neon_me 5 days ago
257 points by neon_me 5 days ago
Somewhat related, I just came across s5cmd[1] which is mainly focused on performance and fast upload/download and sync of s3 buckets.
> 32x faster than s3cmd and 12x faster than aws-cli. For downloads, s5cmd can saturate a 40Gbps link (~4.3 GB/s), whereas s3cmd and aws-cli can only reach 85 MB/s and 375 MB/s respectively.
I prefer s5cmd as well because it has a better CLI interface than s3cmd, especially if you need to talk with non-AWS S3-compatible servers. It does few things and does them well, whereas s3cmd is a tool with a billion options, configuration files, badly documented env variables, and its default mode of operation assumes you are talking with AWS.
For the time I worked at AWS, pretty much everyone inside the company used s5cmd for its speed.
I think that speaks pretty highly of it.
s5cmd is built into the rsync.net platform. See:
I've built an S3 client with similar goals like TFA, but supports pre-signing:
https://github.com/nikeee/lean-s3
Pre-signing is about 30 times faster than the AWS SDK and is not async.
You can read about why it looks like it does here: https://github.com/nikeee/lean-s3/blob/main/DESIGN_DECISIONS...
FYI, you can add browser support by using noble-hashes[1] for SHA256/HMAC - it's a well-done library, and gives you performance that is indistinguishable from native crypto on any scale relevant to S3 operations. We use it for our in-house S3 client.
SHA256 and HMAC are widely available in the browser APIs: https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt...
For now, unfortunately, no - no signed URLs are supported. It wasn't my focus (use case), but if you find a simple/minimalistic way to implement it, I can help you with that to integrate it.
From my helicopter perspective, it adds extra complexity and size, which could maybe be ideal for a separate fork/project?
Signed URLs are great because it allows you to allow third parties access to a file without them having to authenticate against AWS.
Our primary use case is browser-based uploads. You don't want people uploading anything and everything, like the wordpress upload folder. And it's timed, so you don't have to worry about someone recycling the URL.
I use presigned urls as part of a federation layer on top of an s3 bucket. Users make authenticated requests to my api which checks their permissions (if they have access to read/write to the specified slice of the s3 bucket), my api sends a presigned url back to allow read/write/delete to that specific portion of the bucket.
> What I would also love to see is a simple, single binary S3 server alternative to Minio
Garage[1] lacks a web UI but I believe it meets your requirements. It's an S3 implementation that compiles to a single static binary, and it's specifically designed for use cases where nodes do not necessarily have identical hardware (i.e. different CPUs, different RAM, different storage sizes, etc.). Overall, Garage is my go-to solution for object storage at "home server scale" and for quickly setting up a real S3 server.
There seems to be an unofficial Web UI[2] for Garage, but you're no longer running a single binary if you use this. Not as convenient as a built-in web UI.
Presumably smaller and quicker because it's not doing any checksumming
checksumming does make sense because it ensures that the file you've transferred is complete and what was expected. if the checksum of the file you've downloaded differs from the server gave you, you should not process the file further and throw an error (worst case would probably be a man in the middle attack, not so worse cases being packet loss i guess)
> checksumming does make sense because it ensures that the file you've transferred is complete and what was expected.
TCP has a checksum for packet loss, and TLS protects against MITM.
I've always found this aspect of S3's design questionable. Sending both a content-md5 AND a x-amz-content-sha256 header and taking up gobs of compute in the process, sheesh...
It's also part of the reason why running minio in its single node single drive mode is a resource hog.
You need the checksum only if the file is big and you're downloading it to disk, or if you're paranoid that some malware with root access might be altering the contents of your memory.
for Node.
These are nice projects. I had a few rounds with Rust S3 libraries and having a simple low or no dep client is much needed. The problem is that you start to support certain features (async, http2, etc.) and your nice nodep project is starting to grow.
I had the same issue recently and used https://crates.io/crates/rusty-s3
> https://raw.githubusercontent.com/good-lly/s3mini/dev/perfor...
It gets slower as the instance gets faster? I'm looking at ops/sec and time/op. How am I misreading this?
It measures PutObject[0] performance across different object sizes (1, 8, 100MiB)[1]. Seems to be an odd screenshot of text in the terminal.
[0] https://github.com/good-lly/s3mini/blob/30a751cc866855f783a1... [1] https://github.com/good-lly/s3mini/blob/30a751cc866855f783a1...
Personally, I don't like AWS that much. I tried to set it up, but found it "terribly tedious" and drop the idea and instead focus on other platforms.
Right now, I am testing/configuring Ceph ... but its open-source! Every talented weirdo with free time is welcomed to contribute!
You know what would be really awesome? Making a fuse-based drop-in replacement for mapping a folder to a bucket, like goofys. Maybe a node.js process can watch files for instance and backup, or even better it can back the folder and not actually take up space on the local machine (except for a cache).
You mean like https://github.com/s3fs-fuse/s3fs-fuse ? It‘s so old that even debian has precompiled packages ;)
How does this compare to obstore? [1]
I found the words used to describe this jarring - to me it makes sense to have an s3 client on my computer, but less so client side on a webapp. On further reading, it makes sense, but highlighting what problem this package solves in the first few lines of the readme would be valuable for people like me at least
I think if you asked the average IT person what those buzzwords mean, you’ll find the answer unclear…
I was responding to this:
> to me it makes sense to have an s3 client on my computer, but less so client side on a webapp
The relevant audience in this situation is not the average IT person, but a person who might mistake this for client-side web app functionality.
If you think that something might run in the browser, then “no browser support!” is not complicated jargon that you won’t understand.
I have a good suspicion this has been written with help from an LLM. The heavy use of emojis and strong hyper confident language is the giveaway. Proof: my own repos look like this after they’ve had the touch of cursor / windsurf etc. still doesn’t take away if the code is useful or good.
> to me it makes sense to have an s3 client on my computer, but less so client side on a webapp
What do you mean with a webapp?
This is good to have. A few months ago I was testing a S3 alternative but running into issues getting it to work. Turned out it was because AWS made changes to the tool that had the effect of blocking non-first-party clients. Just sheer chance on my end, but I imagine that was infuriating for folks who have to rely on that client. There is an obvious need for a compatible client like this that AWS doesn’t manage.
Tangibly related: Bun has a built-in S3-compatible client. Bun is a gift, if you're using npm consider making the switch.
I tried to go this route of using Bun for everything (Bun.serve, Bun.s3 etc), but was forced back to switch back to NodeJS proper and Express/aws-sdk due to Bun not fully implementing Nodes APIs.
The worst thing is issues without any visibility.
The other day I was toying with the MCP server (https://github.com/modelcontextprotocol/typescript-sdk). I default to bun these days and the http based server simply did not register in claude or any other client. No error logs, nothing.
After fiddling with my code I simply tried node and it just worked.
It definitely works in bun just fine. I have a production built mcp server with auth running under bun.
Now if you convert the request / response types to native bun server, it can be finicky.
But it works fine using express under bun with the official protocol implementation for typescript.
Actually writing a book about this too and will be using bun for it https://leanpub.com/creatingmcpserverswithoauth
Not sure about the specific underlying apis, but as of my last attempt, Bun still doesn't support PDF.js (pdfjs-dist), ssh2, or playwright.
localAddress is unsupported on sockets, meaning you can not specify an outgoing interface, which is useful if you have multiple network cards.
Can someone explain the advantage of this?
If I want S3 access, I can just use NPM
If I don't want S3 access, I don't want it integrated into my runtime
No. It's implemented in native code (Zig) inside bun itself and just exposed to developers as a JavaScript API.
Source code: https://github.com/oven-sh/bun/tree/6ebad50543bf2c4107d4b4c2...
libcurl also has AWS auth with --aws-sigv4 which gives you a fully compatible S3 cliënt without installing anything! (You probably already have curl installed)