Hugging Face Storage Buckets launch: persistent storage on the Hub

Hugging Face launched Storage Buckets on the Hub this week, introducing first-party object storage that sits alongside repositories and profiles. The feature provides a place to store model weights, dataset files and other artifacts with programmatic access via an S3-compatible API and Hub integrations.

Storage Buckets appear in the Hub as a dedicated storage location attached to repositories and organizations, enabling teams to keep artifacts near code, model cards and metadata. The rollout focuses on developer workflows: uploads through the web UI, the Hub CLI and SDKs, and read/write access controlled by repository permissions.

How Storage Buckets work

Storage Buckets expose object storage semantics inside the Hub, meaning files are treated as discrete objects that can be listed, downloaded and referenced by URL. The implementation provides multiple access paths: the Hub UI for manual uploads, the Hub CLI for scripted workflows and an S3-compatible endpoint for tools and third-party integrations. Objects stored in a bucket can be referenced from model cards, dataset entries and inference endpoints, allowing models to load weights and auxiliary files directly from the same platform used to host the repository.

Access control follows Hub permission models. A bucket inherits visibility and collaborator controls from its associated repository or organization, so public repos map to public objects and private repos keep artifacts restricted to authorized users. The service also supports presigned URLs for temporary, scoped access to specific objects without exposing credentials.

Storage Buckets are designed to coexist with existing Hub features. Model and dataset pages can reference bucket objects, and the CLI and SDK include commands to upload, download and list bucket contents. That integration intends to simplify common tasks, such as bundling model weights with a transformer card or attaching large evaluation sets to a dataset entry without inflating the Git-based repository itself.

Developer controls and integrations

The feature targets developers and teams that need durable object storage but prefer to keep assets next to Hub metadata and discovery tools. Programmatic access through S3-compatible APIs allows existing tooling to operate with minimal changes, while native Hub commands aim to reduce friction for users already working in the Hub ecosystem.

Storage Buckets also aim to reduce ad hoc workarounds for large files. Instead of splitting large artifacts into Git LFS pointers or external cloud buckets with separate access rules, teams can centralize files under the Hub’s identity and permission system. The new storage can be used for model checkpoints, tokenizer files, evaluation datasets and other binary artifacts that do not fit well into a Git workflow.

Hugging Face documents suggest the feature will be maintained as a first-class part of the Hub experience, with the company positioning buckets as complementary to the existing repository model rather than a replacement for Git-managed code and metadata.

Why it matters

Storage Buckets reduce friction for teams that want to keep models, datasets and artifacts together with Hub metadata and discovery. For developers, the S3-compatible API and native Hub integrations make migrating existing pipelines simpler, while repository-based access control centralizes permissions. The change shifts more of the model development lifecycle onto the Hub, affecting how teams store, share and deploy model assets.