> ## Documentation Index > Fetch the complete documentation index at: https://docs.onebucket.io/llms.txt > Use this file to discover all available pages before exploring further. # Federation > How OneBucket presents object stores across clouds, on-prem and edge as one namespace, and where identity, credentials and regions fit. 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](https://docs.onebucket.io/setup.md#add-an-endpoint): | Kind | Examples | | - | - | | Public cloud | AWS S3, Azure Blob Storage, Google Cloud Storage | | Cloud object storage | Wasabi, Akave, Seagate Lyve Cloud and other S3-compatible services | | On-premises | Dell object storage, Seagate Exos, or any S3-compatible store | | Edge and air-gapped | S3-compatible stores at edge sites or in isolated networks | Platforms such as Snowflake and Databricks connect to OneBucket over S3 and read the whole namespace through one endpoint; see the [Databricks](https://www.onebucket.io/see-it-work/databricks) and [Snowflake](https://www.onebucket.io/see-it-work/snowflake) walkthroughs. > [!NOTE] > > 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](https://docs.onebucket.io/concepts/policies.md) 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](https://docs.onebucket.io/scenarios/migration.md). ## Identity and credentials Federation separates who a client is from what a backend needs. | Layer | Credential | Held by | | - | - | - | | Client over S3 | OneBucket access key, SigV4 | The client | | Client over MCP | OAuth 2.1 token with PKCE, bound to one audience | The MCP client | | OneBucket to backend | The endpoint's own key or account | OneBucket's vault only | 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](https://docs.onebucket.io/reference/apis.md#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. | Endpoint | Behavior | | - | - | | `https://s3.onebucket.io` | Global. Each request is routed to the live region nearest the caller. | | `https://s3..onebucket.io` | Pinned to one region, for example `https://s3.us-ashburn-1.onebucket.io`, for when requests must land in a specific place. | The MCP endpoints follow the same pattern; the full list is in [APIs](https://docs.onebucket.io/reference/apis.md#endpoints). > [!NOTE] > > 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](https://docs.onebucket.io/mcp/overview.md#events). ## Related > **[Policies](https://docs.onebucket.io/concepts/policies.md)** > > Modes, permissions, quorum and how to change them while serving. > **[Architecture](https://docs.onebucket.io/concepts/architecture.md)** > > Access interfaces, placement, caching and governance. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.