Skip to main content
OneBucket speaks the standard S3 API with AWS SigV4 authentication. Any S3 client or SDK works — just point it at your endpoint:
Copy the exact host and an access key / secret key pair from your OneBucket console.
Because it’s standard S3, the same endpoint and keys work with AWS SDKs in any language, the AWS CLI, s3cmd, rclone, and most S3-compatible tools. See the Quickstart for AWS CLI and boto3 examples.

​
Authentication

  • AWS Signature Version 4 (SigV4) request signing, exactly as with AWS S3.
  • Credentials are the access key / secret key pairs from your console; manage them with onebucket keys in the CLI.
  • Region: use us-east-1. The region in your credential scope is used for signature derivation (as SigV4 requires), not for routing — the endpoint determines routing. The gateway is currently lenient about the region value, but don’t rely on arbitrary names: configure us-east-1 (empty and auto also resolve to it), and future releases may reject other values.

​
Addressing styles

Both S3 addressing styles are supported. The gateway first looks for a bucket prefix in the hostname, then falls back to the first path segment:
Virtual-hosted style requires DNS resolution of bucket subdomains. If your environment can’t resolve them, configure your client for path-style addressing (e.g. s3.addressing_style = path in boto3).

​
Supported features

​
OneBucket-specific behavior

Behind the standard API, requests resolve against the Adaptive Data Fabric:
  • A bucket is logical — its objects may be held by different backends (AWS S3, Azure Blob, GCS, Wasabi, Akave, on-prem, edge, air-gapped) while clients see one namespace.
  • Cross-backend copy, move, and migrate operations are asynchronous: they return once queued, and the destination may not be readable immediately.
  • Repeat reads of hot objects are served from the edge cache; prefetching keeps first reads fast too.
  • All activity is emitted as storage events, queryable over the events MCP endpoint.

​
Errors

The gateway returns standard S3 XML error responses (e.g. NoSuchBucket, NoSuchKey, AccessDenied), so existing SDK error handling works unchanged.