How to Create a Storage Bucket in Walrus?
@Walrus 🦭/acc If you come to Walrus with years of “bucket” habits from S3 on Amazon Web Services, the first few minutes can feel disorienting. You expect to name a bucket, set permissions, and move on. Walrus doesn’t begin there. It begins with a simpler promise: store a blob of data, get an identifier, and later prove that the same bytes are still available.
That shift is a big reason Walrus is showing up in conversations now. Recent years have made teams more cautious about lock-in and the quiet fragility of “it’s in the cloud, so it’s fine.” At the same time, AI work has turned data into a first-class asset. Training sets, evaluation corpora, and model artifacts get moved around, versioned, and reused, and people often want to know what they’re actually pointing to. Walrus frames storage as something you can verify, not just rent.
So when someone asks how to “create a storage bucket in Walrus,” it helps to translate the request. In Walrus itself, there isn’t a bucket you create up front. The system is intentionally flat: blobs go in, blob IDs come out. Storage is measured in epochs, time windows that define how long a blob stays available unless you extend it. The CLI exposes details like the current epoch and blob size limits, and the HTTP API lets you store and retrieve blobs with straightforward HTTP requests.
But humans don’t think in blob IDs. We think in projects, clients, releases, and the folder everyone keeps linking. This is where your “bucket” becomes an organizing layer on top of Walrus, not a built-in object you click into existence. One clean option is to use Walrus “quilts,” which bundle multiple blobs together and let you assign readable identifiers within that bundle. It feels close to a bucket-and-objects relationship, except the underlying system stays content-addressed and proof-oriented.
If you want the bucket experience more literally, you can reach for a wrapper. A small but telling example is an open-source tool called SuiS3. It adds an S3-style command set on top of Walrus, including an “mb” command to create a bucket name you can list and reuse. Under the hood it’s still Walrus blobs plus metadata stored via Sui, but the workflow stops fighting your instincts. This is how infrastructure becomes usable: not by forcing everyone to adopt a new mental model overnight, but by meeting people where they are.
Integrations like Yotta Labs bring bucket language back.
The timing isn’t accidental. Mature ecosystems also shed earlier convenience layers. Walrus’s docs include a migration guide because Tusky began shutting down on December 19, 2025. Transitions like that make “where is my bucket?” a practical question. If your bucket is just a web app’s UI, you need an exit plan. If your bucket is a stable convention over verifiable blobs, you can change tools without losing your footing.
Creating a storage bucket in Walrus, then, is less a single step and more a choice about where organization lives. For some teams it’s a quilt per project. For others it’s an S3-shaped wrapper. The healthiest mental model is to treat that bucket layer as a promise you’re making to future-you: a naming scheme you’ll still understand when you’re tired and in a hurry. Either way, the durable center is the same: store the data, keep the identifiers, and treat proof of availability as part of what “safe” means in your own workflow.