Skip to main content
Federation is what OneBucket does at its core: it presents object storage you already own, across clouds, on-premises and edge, as one namespace behind one S3 endpoint and one MCP server. The backends stay where they are and keep their own credentials. OneBucket holds no data of its own; bytes stream through it.

​
What can be federated

Any object store OneBucket can reach over S3 or the Azure Blob protocol can be an endpoint: Platforms such as Snowflake and Databricks connect to OneBucket over S3 and read the whole namespace through one endpoint; see the Databricks and Snowflake walkthroughs.
OneBucket federates object storage. File shares over NFS or SMB are out of scope unless they are already exposed through an S3 gateway, and an endpoint must be reachable from wherever OneBucket runs.

​
One namespace

Clients see buckets and keys, never backends. A policy maps each OneBucket to its peer buckets, and every request resolves against it:
  • Listing a bucket merges what its peers hold into one view. Each object carries its locations, the backends that hold it.
  • Reads are served from a peer that holds the object, following the policy’s sequence, or from a cache peer when one is warm.
  • Writes land on the peers the policy names, with the quorum it sets.
  • locate reports which backends hold a given object, for audit or troubleshooting.
The namespace stays stable while backends change underneath it: adding, draining or retiring a backend is a policy edit, not a client change. See Move data behind a fixed endpoint.

​
Identity and credentials

Federation separates who a client is from what a backend needs. Backend credentials are never handed to clients, so an application or an agent can work across several clouds without holding a single cloud key. Revoking a OneBucket key or session cuts access everywhere at once, without rotating anything on the backends.

​
Organizations

An organization is the unit of isolation. Each has its own users, access keys, endpoints and policies, and every operation is scoped to one organization and one key; cross-organization access is not possible. Use separate organizations to keep environments or projects fully apart. Everything that defines a federation, from keys to backends to policies, can be set up in the console or through the management API, so the whole configuration can live in your own scripts and pipelines.

​
Regions and global endpoints

OneBucket runs in multiple regions, today us-ashburn-1, us-sanjose-1 and ap-singapore-1, with more coming online. Your policies are active in every region. The MCP endpoints follow the same pattern; the full list is in APIs.
The region a request lands on decides where it is processed, not where data is stored. Storage location is decided by the policy’s peer buckets. For data residency, set both: pin the region and place the peers in the jurisdiction.

​
Deployment

The same software runs as SaaS, in your VPC, on-premises, or fully air-gapped. It ships as a container image and a Helm chart for Kubernetes. Federation works identically in each: what changes is where OneBucket runs, not how backends are joined. A OneBucket deployment can also be an endpoint of another one, for example an on-premises deployment federated into a SaaS namespace. This works with no special configuration, but each request then passes through both, which doubles the traffic on the path.

​
Observing the federation

Every request produces events: one gateway event for the request as the client made it, and one backend event for each endpoint it reached, all sharing a request ID. Together they show which backends served what, for whom, and with what result. See Events.

Policies

Modes, permissions, quorum and how to change them while serving.

Architecture

Access interfaces, placement, caching and governance.