Skip to main content
OneBucket puts one S3-compatible endpoint, and a native MCP server, in front of object storage spread across clouds, on-premises and edge. Applications and agents see one bucket. Underneath, policy decides where data lives, when it is replicated, cached or migrated, and when it is left where it is. The scenarios below are the patterns that come up most often. The first four are infrastructure patterns and build on each other: one endpoint in front of one backend, several backends behind the same endpoint, a policy that decides which backend holds which bucket, and one of those backends placed next to compute. The next three are AI and analytics patterns on top of that foundation. All of them are configuration: a policy and a key, no code written.

​
Combining patterns

Several patterns combine naturally:
  • Placement + replication when the copies must sit in specific jurisdictions.
  • Migration + placement when the move is a cloud exit for sovereignty reasons.
  • Token economics + agents whenever an agent is the consumer.

​
What stays the same in every scenario

  • OneBucket holds no data of its own. Bytes stream through it; the storage underneath is unchanged.
  • Backend credentials stay with you, held in the secure vault. Applications and agents get OneBucket keys or OAuth tokens, never raw cloud keys.
  • Placement is set per bucket by policy, not per object.
  • Every operation is an event, scoped to organization and key, available over the Events MCP.