Buckets and objects

Storage uses a simple two-level model: workspace-scoped buckets that hold objects. This page explains what each one is and how it behaves. It stays conceptual; the API reference is where the exact fields, methods, and limits live.

Buckets

A bucket is a container for objects. Every bucket belongs to one workspace and is provisioned on a cloud provider. It has a human-readable name that is unique within its workspace, an optional description, and a default storage class, a reference to one of the storage classes available to it.

On qibdo’s own engine, a bucket lives in a single region, chosen when you create it and fixed afterward, and supports versioning. With versioning on, the service keeps prior copies of an object instead of discarding them when it changes, so you can recover an earlier one. See Object versioning below.

A bucket must be empty before it can be deleted. The service refuses to delete a bucket that still holds objects, so remove its objects first.

Objects

An object is a single piece of stored data, for example an image, an archive, or a backup, together with the metadata that describes it. Each object is identified by a key within its bucket, a path-like string such as images/2026/logo.png. The key looks like a file path, but objects live in a flat namespace: the slashes are part of the name, not real folders. You can still list objects by a shared prefix to browse them as if they were directories.

Along with its bytes, every object carries metadata you can read without downloading the body:

• its size,
• a content type, the MIME type such as image/png,
• a checksum that fingerprints the stored content,
• the last-modified time,
• an optional set of user metadata key-value pairs you attach yourself,
• the storage class the object is stored in,
• and, when the bucket has versioning on, a version identifier.

Object versioning

Versioning is a per-bucket setting. While it is off, writing to an existing key replaces the object in place. While it is on, each write preserves the previous content as a distinct version, and every version is addressable by its own version identifier, so you can recover or roll back to an earlier copy. Turning versioning off again stops new versions from being created but leaves existing ones intact.

Object integrity

Every object carries a checksum derived from its content. Because identical content always yields the same checksum, you can compare the value the service reports against one you compute locally to confirm an upload or download arrived intact. Objects assembled from several parts use a checksum computed from those parts, so treat it as an identifier for that specific assembly rather than a plain digest of the whole.

Related concepts

• Storage classes: how a bucket’s default storage class selects the tier objects are stored in.
• Create a bucket.