> 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 think that speaks pretty highly of it.
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...
From my helicopter perspective, it adds extra complexity and size, which could maybe be ideal for a separate fork/project?
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.
What I would also love to see is a simple, single binary S3 server alternative to Minio. Maybe a small built in UI similar to DuckDB UI.
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.
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.
On the other hand S3 uses checksums only to verify expected upload (on the write from client -> server) ... and suprisingly you can do that in paralel after the upload - by checking the MD5 hash of blob to ETag (*with some caveats)
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.
> It runs on Node, Bun, Cloudflare Workers, and other edge platforms
It gets slower as the instance gets faster? I'm looking at ops/sec and time/op. How am I misreading this?
[0] https://github.com/good-lly/s3mini/blob/30a751cc866855f783a1... [1] https://github.com/good-lly/s3mini/blob/30a751cc866855f783a1...
Right now, I am testing/configuring Ceph ... but its open-source! Every talented weirdo with free time is welcomed to contribute!
What's your experience running it?
> 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.
What do you mean with a webapp?
but has anyone done a price comparison of edge-computing vs say your boring hetzner vps ?
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.
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
Source code: https://github.com/oven-sh/bun/tree/6ebad50543bf2c4107d4b4c2...
I want maximum ability to "move" my projects among services/vendors/providers
[0] https://bun.sh/docs/api/s3
[1] https://hono.dev/docs/getting-started/cloudflare-workers \ (https://bun.sh/docs/api/workers ?)
Rather ship oven/bun through docker and have a 90mb container vs using node.
