BYO storage: provider recipes
Exact endpoint / region / credential settings for the providers we see most. Field meanings, the minimal IAM policy, verification, and troubleshooting are all in BYO storage: setup — this page is just the per-provider specifics.
AWS S3
| Field | Value |
|---|---|
| Endpoint | https://s3.<region>.amazonaws.com (e.g. https://s3.eu-west-1.amazonaws.com) |
| Region | The bucket's region — must match (e.g. eu-west-1). |
| Force path-style | Either works. |
Credentials: create a dedicated IAM user with programmatic access and attach the minimal policy scoped to your bucket. Use that user's access key pair — never root keys.
Common failure: leaving Region blank for a non-us-east-1 bucket. Blank is
signed as us-east-1 and AWS rejects the request with a region error.
Cloudflare R2
| Field | Value |
|---|---|
| Endpoint | https://<account-id>.r2.cloudflarestorage.com (shown on the R2 overview page) |
| Region | auto |
| Force path-style | On (the default). |
Credentials: R2 → Manage R2 API Tokens → create a token with Object Read & Write, scoped to the one bucket. Cloudflare shows an S3-style Access Key ID and Secret Access Key for the token — those are what go in the form. R2 tokens don't use IAM JSON; the bucket scoping on the token is the equivalent of the minimal policy.
R2 has no storage-class or region gotchas; it's the lowest-friction option.
Backblaze B2
| Field | Value |
|---|---|
| Endpoint | https://s3.<region>.backblazeb2.com — copy it from the bucket details page (e.g. https://s3.us-west-004.backblazeb2.com) |
| Region | The region embedded in the endpoint (e.g. us-west-004). |
| Force path-style | Either works. |
Credentials: App Keys → create an application key scoped to the one bucket with read and write. The keyID goes in Access key ID and the applicationKey in Secret access key.
Note: the B2 master key does not work with the S3-compatible API — you must use a bucket-scoped application key. Keys created before B2's S3-compatible API launch (May 2020) also won't work; create a fresh one.
MinIO (self-hosted)
| Field | Value |
|---|---|
| Endpoint | https://minio.example.com or https://minio.example.com:9000 — your public MinIO S3 endpoint |
| Region | Whatever your server is configured with; blank works for a default MinIO install. |
| Force path-style | On (required for most MinIO installs). |
Reachability is the hard requirement. TRaX connects to your endpoint from its servers, and private/LAN addresses are rejected outright (see endpoint requirements). Your MinIO must have:
- a public DNS name (not
192.168.x.x, notminio.local, not a bare hostname) that resolves to a public IP — a public name resolving to a private IP is blocked at connection time, - a valid TLS certificate on that name (Let's Encrypt is fine; TRaX will not connect over plain HTTP),
- inbound access from the internet to the S3 API port.
Credentials: create a dedicated user and a policy equivalent to the minimal policy:
mc admin user add myminio trax-user 'GENERATED-SECRET'
mc admin policy create myminio trax-policy ./trax-policy.json
mc admin policy attach myminio trax-policy --user trax-user
where trax-policy.json is the minimal policy JSON with your bucket name.
Don't use the MinIO root credentials.
If the verification probe fails with an invalid-credentials error and the keys are definitely right, check the server clock — a skewed clock breaks S3 request signing.
Anything else S3-compatible
Other S3-compatible stores (Garage, Ceph RGW, Wasabi, DigitalOcean Spaces, …) generally work with the same three questions: what's the HTTPS endpoint, what region string does it sign with, and does it want path-style addressing? Verification tells you immediately whether the combination works — the probe does a real write/read/delete round-trip.