The Storj S3-compatible Gateway supports a RESTful API that is compatible with the basic data access model of the Amazon S3 API.
The Storj S3 Gateway is well-suited for many application architectures, but the S3 standard was designed for centralized storage and there are a few areas where a decentralized architecture requires a different approach.
Storj offers two options for S3 compatibility:
Storj-hosted S3 Compatible Gateway: Storj hosted S3 Compatible Service
Self-hosted S3 Compatible Gateway: Self-hosted S3 Compatible Binary (run your own S3 endpoint)
The latest compatibility can be found in the compatibility table for GatewayST in our GitHub repo.
If you have an existing application that is using an S3-compatible object storage service and you want to switch to Storj, the easiest way to switch is to use the hosted S3-compatible service. The main design decision you need to be aware of is that Gateway-MT uses Design Decision - Server-side Encryption. You can learn about the supported commands and endpoints for S3 compatibility under the SDK & Reference section for the Storj-hosted S3 Compatible Gateway.
If you have an hybrid cloud architecture, are working with on-premise data, or have other needs to host your own S3-compatible object storage service you may want to use the self-hosted GatewayST. The two main design decisions you need to be aware of are that:
GatewayST uses Design Decision - End-to-end Encryption.
When you host your own Gateway, that gateway is handling the erasure coding and direct peer-to-peer transfer of data to storage nodes. You will need to account for the upstream bandwidth associated with the File Redundancy the data and any associated overhead related to concurrent connections with storage nodes related to parallel transfers.
You can learn about the supported commands and endpoints for S3 compatibility under the SDK & Reference section for the Storj-hosted S3 Compatible Gateway.