Supported environments
API means the profile adapts origin API behavior. Infrastructure means the profile changes provisioned resources or documents a target-native alternative without promising an origin API endpoint. Check the operation and capability tables for the behavior your application depends on.
How the targets compare
Each row compares a capability of S3 with its adaptation on each target. A dash means this profile does not state the capability for that target.Cloud Adapter
On Azure
Blob Storage
S3 requests in the target environment
The application continues using the S3 API. The Tensor9 adapter runs in the target environment and sends object requests to Azure Blob Storage. It also serves bucket creation, deletion, listing, and configuration through a persistent bucket store. Azure Blob Storage stores the objects; Tensor9 operates the adapter and its bucket-management service.Request flow
Object requests use the target storage service. Bucket settings persist separately and are applied to the target resource.
Object requests
Azure Blob uses its own API, so the adapter translates S3 requests, headers, XML results and errors into Blob operations. It streams reads and writes, maps object tags to Blob Index Tags, and handles batch deletion as individual blob deletes. CopyObject downloads and uploads the object rather than using a server-side copy. Flat listing supports prefixes and pagination; delimiter/CommonPrefixes grouping is outside the listed mapping.Bucket creation and configuration
Each S3 bucket has a durable record containing its name, owner, requested configuration, and target reference. For a bucket namedbucket-name, the S3-facing identifier is arn:aws:s3:::bucket-name; the target resource is a Blob container in a selected storage account. ListBuckets returns the caller’s buckets, and configuration reads use the stored request state.
A configuration worker applies the stored settings to the target. CreateBucket waits for the target bucket to be ready before returning success, so an immediate object write does not race bucket creation. DeleteBucket waits for removal and returns BucketNotEmpty if objects prevent deletion. A lifecycle update also waits for target application. For other configuration changes, a successful read of the new setting describes stored configuration; it does not imply every target-side change has already completed.
Versions and multipart uploads
Multipart uploads store parts as Azure blocks and commit a block list at completion. Max retains the part checksums and S3 version metadata needed for composite multipart ETags, S3 version IDs and delete markers. The simpler request-translation path uses Azure’s native version and completion-ETag behavior instead. Single-part writes compute the content MD5 and persist it as Blob Content-MD5. Azure tag-character restrictions still apply, including rejection of @ and non-ASCII characters.Target configuration
The adapter stores per-bucket configuration and reconciles each bucket to a container. Several Azure settings belong to the storage account, including region, redundancy, native versioning and default encryption; a container cannot independently choose them. Shared-account configuration must be planned for all buckets using that account. S3 lifecycle settings use the supported target mappings, and unsupported conditions must not change retention behavior silently. Max supplies S3 metadata where native account-level behavior alone is insufficient.Placement and operation
Azure provides strong consistency. Its documented durability depends on redundancy: 11 nines for LRS, 12 for ZRS, and 16 for GRS or GZRS. Choose the account region and redundancy to meet the customer’s placement and recovery needs. A bucket’s S3 location field does not relocate the storage account. Tensor9 operates the adapter and persistent bucket state; Microsoft operates Blob Storage.Compatibility limits
Bucket policy remains unsupported. The listed object API still has copy-source conditional and hierarchical-listing limits, and suffix or multiple byte ranges use a full-download fallback. A single PutObject is limited to 5000 MiB on this path. Azure has no S3 Requester Pays or direct One Zone storage-class equivalent. Object retention and legal-hold capabilities must be evaluated separately from the runtime APIs this mapping serves.Migration and leaving the adapter
A newly provisioned target bucket starts empty. Copy existing objects and required versions with a migration tool or a coordinated dual-write, then verify object data and application reads before switching. Preserve version history through the S3 API when the application depends on S3 version identifiers or delete markers. Leaving the Max adapter requires moving bucket configuration as well as object data. Apply the retained settings to native target resources, resolve any S3-specific version metadata, and move clients to the target’s own API. Keep the adapter and its persistent state until the application no longer depends on those S3 behaviors.On DigitalOcean
DigitalOcean Spaces
S3 requests in the target environment
The application continues using the S3 API. The Tensor9 adapter runs in the target environment and sends object requests to DigitalOcean Spaces. It also serves bucket creation, deletion, listing, and configuration through a persistent bucket store. DigitalOcean Spaces stores the objects; Tensor9 operates the adapter and its bucket-management service.Request flow
Object requests use the target storage service. Bucket settings persist separately and are applied to the target resource.
Object requests
Spaces speaks the S3 protocol. The adapter changes the endpoint and signs with a Spaces access key, while the service handles objects, ranges, copies, batch deletion and paginated listing in both the v1 and v2 listing forms. The endpoint uses the selected region, such as nyc3.digitaloceanspaces.com. The adapter still provides the S3 endpoint expected by the application.Bucket creation and configuration
Each S3 bucket has a durable record containing its name, owner, requested configuration, and target reference. For a bucket namedbucket-name, the S3-facing identifier is arn:aws:s3:::bucket-name; the target resource is a DigitalOcean Spaces bucket. ListBuckets returns the caller’s buckets, and configuration reads use the stored request state.
A configuration worker applies the stored settings to the target. CreateBucket waits for the target bucket to be ready before returning success, so an immediate object write does not race bucket creation. DeleteBucket waits for removal and returns BucketNotEmpty if objects prevent deletion. A lifecycle update also waits for target application. For other configuration changes, a successful read of the new setting describes stored configuration; it does not imply every target-side change has already completed.
Versions and multipart uploads
Spaces supplies bucket versioning, ListObjectVersions and the full multipart set natively: CreateMultipartUpload, UploadPart, ListParts, ListMultipartUploads, CompleteMultipartUpload and AbortMultipartUpload. Max retains those provider behaviors and adds the persistent bucket-management service on top of them.Target configuration
The Max adapter stores bucket ownership and requested configuration, then reconciles that state to Spaces. Bucket creation, deletion and head already have native operations the adapter serves at the baseline tier; the persistent record gives the application the same management model used with the other targets.Placement and operation
DigitalOcean operates the object store; Tensor9 operates the S3 adapter and its persistent bucket-management service. The Spaces key pair is not the DigitalOcean API token: Spaces mints its own, and both the object and bucket planes sign with that same Spaces pair.Compatibility limits
Object tagging is unsupported upstream: GetObjectTagging, PutObjectTagging and DeleteObjectTagging return NotImplemented from Spaces, and object tagging is not served on this edge. Bucket versioning is the one configuration the adapter applies to Spaces; bucket tagging, lifecycle and encryption settings are held by the management service and answered from that record, and do not reach the provider. Read-after-write consistency is not documented by the provider. Bucket policy, CORS, website, notification and replication remain outside this mapping. The Max management service does not by itself remove these operation-level differences.Migration and leaving the adapter
A newly provisioned target bucket starts empty. Copy existing objects and required versions with a migration tool or a coordinated dual-write, then verify object data and application reads before switching. Preserve version history through the S3 API when the application depends on S3 version identifiers or delete markers. Leaving the Max adapter requires moving bucket configuration as well as object data. Apply the retained settings to native target resources, resolve any S3-specific version metadata, and move clients to the target’s own API. Keep the adapter and its persistent state until the application no longer depends on those S3 behaviors.On Google Cloud
Cloud Storage
S3 requests in the target environment
The application continues using the S3 API. The Tensor9 adapter runs in the target environment and sends object requests to Google Cloud Storage. It also serves bucket creation, deletion, listing, and configuration through a persistent bucket store. Google Cloud Storage stores the objects; Tensor9 operates the adapter and its bucket-management service.Request flow
Object requests use the target storage service. Bucket settings persist separately and are applied to the target resource.
Object requests
Core GetObject, HeadObject, PutObject, CopyObject, DeleteObject, and listing requests use GCS’s S3-interoperable XML endpoint with target credentials. Batch deletion sends per-object deletes and returns S3 Deleted/Error entries. Object tags are encoded in reserved GCS object metadata and reconstructed as S3 tagging documents. The object data stays in GCS; the bucket store does not hold object bodies.Bucket creation and configuration
Each S3 bucket has a durable record containing its name, owner, requested configuration, and target reference. For a bucket namedbucket-name, the S3-facing identifier is arn:aws:s3:::bucket-name; the target resource is a GCS bucket. ListBuckets returns the caller’s buckets, and configuration reads use the stored request state.
A configuration worker applies the stored settings to the target. CreateBucket waits for the target bucket to be ready before returning success, so an immediate object write does not race bucket creation. DeleteBucket waits for removal and returns BucketNotEmpty if objects prevent deletion. A lifecycle update also waits for target application. For other configuration changes, a successful read of the new setting describes stored configuration; it does not imply every target-side change has already completed.
Versions and multipart uploads
GCS multipart uploads use temporary objects for individual parts. Completion calls the GCS JSON compose API to form the final object. At Max, the adapter retains part checksums to supply S3’s composite multipart ETag and maintains the S3 version history and delete markers that differ from native GCS generations. A deployment that only forwards object requests instead exposes the native generation model and compose ETag. ListMultipartUploads and UploadPartCopy remain outside the listed mapping.Target configuration
Bucket versioning, tagging, lifecycle and encryption settings are managed through runtime S3 calls. Lifecycle translation supports the rules listed in the feature comparison: prefix-scoped, relative-age expiration and transitions to STANDARD_IA or ONEZONE_IA, both mapped to Nearline. Unsupported date, filter, noncurrent-version and archival-transition forms return an error rather than a different retention or cost policy. Encryption uses Google-managed keys, Cloud KMS customer-managed keys or customer-supplied keys as applicable; DSSE-KMS and S3 Bucket Keys have no direct equivalent.Placement and operation
GCS provides strong read-after-write consistency and designs for 99.999999999% annual durability. Region, dual-region or multi-region placement controls where the provider stores the data. Cross-bucket replication uses Storage Transfer Service rather than the S3 replication-rule engine. Object notifications go to Pub/Sub; routing to other destination types requires downstream integration. Tensor9 operates the bucket-management adapter, while Google operates object storage.Compatibility limits
Bucket policy is unsupported at every adaptation tier. Object ACL, retention/legal-hold, S3 Select and RestoreObject APIs remain outside the listed S3 endpoint. Native GCS features such as Bucket Lock, Requester Pays and Autoclass must be assessed with their own configuration and semantics; native availability does not turn them into unrestricted S3 API equivalents.Migration and leaving the adapter
A newly provisioned target bucket starts empty. Copy existing objects and required versions with a migration tool or a coordinated dual-write, then verify object data and application reads before switching. Preserve version history through the S3 API when the application depends on S3 version identifiers or delete markers. Leaving the Max adapter requires moving bucket configuration as well as object data. Apply the retained settings to native target resources, resolve any S3-specific version metadata, and move clients to the target’s own API. Keep the adapter and its persistent state until the application no longer depends on those S3 behaviors.On OCI
OCI Object Storage
S3 requests in the target environment
The application continues using the S3 API. The Tensor9 adapter runs in the target environment and sends object requests to OCI Object Storage. It also serves bucket creation, deletion, listing, and configuration through a persistent bucket store. OCI Object Storage stores the objects; Tensor9 operates the adapter and its bucket-management service.Request flow
Object requests use the target storage service. Bucket settings persist separately and are applied to the target resource.
Object requests
Object requests use OCI’s Amazon S3 Compatibility endpoint. The adapter changes the endpoint and signs with the customer’s OCI S3-compatible access and secret keys. Core reads, writes, copies, deletes and multipart uploads use the provider API. Object bodies remain in OCI Object Storage, while the adapter stores bucket configuration separately.Bucket creation and configuration
Each S3 bucket has a durable record containing its name, owner, requested configuration, and target reference. For a bucket namedbucket-name, the S3-facing identifier is arn:aws:s3:::bucket-name; the target resource is an OCI Object Storage bucket. ListBuckets returns the caller’s buckets, and configuration reads use the stored request state.
A configuration worker applies the stored settings to the target. CreateBucket waits for the target bucket to be ready before returning success, so an immediate object write does not race bucket creation. DeleteBucket waits for removal and returns BucketNotEmpty if objects prevent deletion. A lifecycle update also waits for target application. For other configuration changes, a successful read of the new setting describes stored configuration; it does not imply every target-side change has already completed.
Versions and multipart uploads
OCI provides native multipart uploads and accepts a versionId on object reads, metadata reads and deletion. Its compatibility endpoint does not provide the S3 version-listing behavior used by the application. At Max, the adapter retains the version and deletion metadata needed by S3-addressed object operations. ListObjectVersions remains outside this mapping; maintaining version metadata does not add that API. Native multipart operations retain the provider’s behavior.Target configuration
Runtime bucket configuration is stored by the adapter and applied through the target bucket-management design. Native OCI bucket settings provide lifecycle, encryption, replication and retention. Encryption can use provider-managed, Vault-managed or customer-supplied keys; DSSE-KMS and S3 Bucket Keys have no direct equivalent. OCI tags apply to buckets; object tagging is outside the listed mapping. Retention rules combine time-based retention with optional locking and do not provide an independent S3 legal-hold object.Placement and operation
OCI provides strong read-after-write consistency and designs for eleven-nines durability. It replicates across three availability domains, or three fault domains in a single-domain region. Cross-region replication targets a preexisting destination bucket. Object events use OCI Events. Tensor9 operates the bucket-management adapter, and Oracle operates the object store.Compatibility limits
Bucket policy is unsupported at every tier. OCI’s compatibility endpoint has no configurable CORS; its fixed response is not an S3 CORS rule set. Website hosting and Requester Pays have no direct OCI Object Storage equivalent. Presigned access uses OCI Pre-Authenticated Requests outside this S3 adapter path. The API table identifies operations that remain unavailable despite native storage features.Migration and leaving the adapter
A newly provisioned target bucket starts empty. Copy existing objects and required versions with a migration tool or a coordinated dual-write, then verify object data and application reads before switching. Preserve version history through the S3 API when the application depends on S3 version identifiers or delete markers. Leaving the Max adapter requires moving bucket configuration as well as object data. Apply the retained settings to native target resources, resolve any S3-specific version metadata, and move clients to the target’s own API. Keep the adapter and its persistent state until the application no longer depends on those S3 behaviors.On Private Kubernetes
MinIO Storage
S3 on the customer’s own storage
The application uses its S3 client to reach the Tensor9 adapter. The adapter signs requests with the customer’s MinIO credentials and forwards the supported operations to MinIO’s S3 endpoint. Tensor9 deploys and operates MinIO inside the Cloud Adapter deployment, including in disconnected environments. Objects remain on the customer’s disks.
Object operations
The adapter forwards the listed reads, writes, listings, deletes, server-side copies and multipart uploads. Versioned buckets also support version listing. Object tags are stored as MinIO object tags, so MinIO can use them in its lifecycle and access-policy conditions. MinIO’s broader API does not determine what this endpoint accepts. The adapter rejects object ACL requests, bucket-policy requests, S3 Select, Glacier restore and runtime retention or legal-hold calls. MinIO implements Object Lock, including GOVERNANCE and COMPLIANCE retention and independent legal holds; configure those features directly on MinIO.Consistency and recovery
MinIO provides strict read-after-write and list-after-write consistency. A completed write is visible to subsequent reads and listings. MinIO splits objects into data and parity shards across drives. Parity lets it reconstruct missing or damaged shards while enough drives remain available. Failure tolerance depends on the configured parity and the placement of drives across nodes. Read and write availability have separate quorum requirements: recovering data after an outage does not guarantee that writes can continue throughout it. MinIO checks reads with HighwayHash and can repair detected corruption from surviving shards. Tensor9 operates recovery and monitors the deployment; durability depends on its hardware and layout. There is no MinIO durability percentage or availability SLA to substitute for that design. See MinIO’s erasure-coding documentation for parity and quorum requirements.
Bucket configuration
Configure bucket features at deployment or directly on MinIO. The described adapter does not forward runtime S3 bucket-configuration requests. MinIO supports versioning, expiration of current and noncurrent objects, and cleanup of incomplete multipart uploads. Encryption supports SSE-S3, SSE-C and SSE-KMS through the KES key server; DSSE-KMS and S3 Bucket Keys have no equivalent in this mapping. Bucket replication copies objects between configured buckets. Site replication also replicates buckets and identity configuration, including users, groups and policies, across MinIO deployments. Choose the replication mode and recovery destinations for the application. MinIO can send object events to webhooks, Kafka, AMQP, NATS, Redis and several databases. Configure these destinations on MinIO; the adapter rejects PutBucketNotificationConfiguration.Storage and website limitations
MinIO’s STANDARD and REDUCED_REDUNDANCY classes select erasure-coding parity, not storage cost tiers. Lifecycle rules can move data to an external object store, but this mapping has no on-cluster Glacier-style class or Requester Pays billing mode. The Community server does not implement configurable CORS in this mapping; verify support in the MinIO edition deployed. MinIO also has no S3 index/error-document website mode. A web server or reverse proxy can serve static content from the bucket. S3 analytics, inventory, Intelligent-Tiering and metrics configurations are outside this mapping.Operations and migration
The customer supplies the disks and nodes, and Tensor9 operates the store as part of the Cloud Adapter deployment. Size usable capacity after accounting for parity and replication, and plan expansion and recovery around the actual drive and node layout. New buckets start empty. Copy existing S3 objects and required versions before switching clients, then verify reads and version-dependent behavior. MinIO site replication can seed another MinIO deployment, including its identity configuration. This adapter does not enforce S3 presigned-URL signatures and expiry. Use MinIO’s native presigning or mc share for time-limited direct access. Moving away from the adapter requires changing client endpoints and credentials and preserving the bucket settings the application uses.On Scaleway
Scaleway Object Storage
S3 requests in the target environment
The application continues using the S3 API. The Tensor9 adapter runs in the target environment and sends object requests to Scaleway Object Storage. It also serves bucket creation, deletion, listing, and configuration through a persistent bucket store. Scaleway Object Storage stores the objects; Tensor9 operates the adapter and its bucket-management service.Request flow
Object requests use the target storage service. Bucket settings persist separately and are applied to the target resource.
Object requests
Scaleway speaks the S3 protocol. The adapter changes the endpoint and signs with a Scaleway API key, while the service handles objects, ranges, conditional requests, copies, batch deletion and paginated listing. The endpoint uses the selected Scaleway region, such as s3.fr-par.scw.cloud. The adapter still provides the S3 endpoint expected by the application.Bucket creation and configuration
Each S3 bucket has a durable record containing its name, owner, requested configuration, and target reference. For a bucket namedbucket-name, the S3-facing identifier is arn:aws:s3:::bucket-name; the target resource is a Scaleway Object Storage bucket. ListBuckets returns the caller’s buckets, and configuration reads use the stored request state.
A configuration worker applies the stored settings to the target. CreateBucket waits for the target bucket to be ready before returning success, so an immediate object write does not race bucket creation. DeleteBucket waits for removal and returns BucketNotEmpty if objects prevent deletion. A lifecycle update also waits for target application. For other configuration changes, a successful read of the new setting describes stored configuration; it does not imply every target-side change has already completed.