DigitalOcean Spaces
DigitalOcean Spaces puts the region in the hostname and accepts nothing else: path-style addressing is unsupported, so S3 Explorer locks the toggle to virtual-hosted. Credentials come from a dedicated Spaces section, not from the general-purpose API token you may already have.
Connection settings
- Endpoint
- https://{region}.digitaloceanspaces.com
- Default region
- nyc3
- Addressing
- Virtual-hosted (enforced)
- Temporary credentials
- Not applicable
A filled-in example
Every value below is fabricated — they are shaped like real DigitalOcean Spaces credentials so you can recognise yours, and they authenticate nothing.
- Endpoint
- https://fra1.digitaloceanspaces.com
- Region
- fra1
- Access key
- DOEXAMPLEACCESSKEY001
- Secret key
- EXAMPLEdoSpacesSecretKeyDoNotUse0123456789a
- Addressing
- Virtual-hosted (locked)
The region code appears twice — in the endpoint and in the region field — and the two have to match.
Where each value comes from
Endpoint
Format: https://{region}.digitaloceanspaces.com — e.g., https://nyc3.digitaloceanspaces.com
Credentials
In DigitalOcean Console → API → Spaces Keys, generate a new key pair.
Notes
Virtual-hosted style is mandatory — path-style is not supported. The region is part of the endpoint URL.
What usually goes wrong
Spaces keys are not API tokens
The personal access token used for the DigitalOcean API will not authenticate here. Generate a key pair under API → Spaces Keys; it is the only credential type Spaces accepts.
Path-style simply does not answer
Forcing path-style produces a connection that resolves and then fails on every listing. If you are porting a configuration from MinIO, where path-style is mandatory, this is the setting that has to be inverted.
The CDN endpoint is a different hostname
Spaces can front a bucket with a CDN on a *.cdn.digitaloceanspaces.com hostname. That endpoint serves content but is not the S3 API — point the client at the origin endpoint.
Regions available in the app
nyc3ams3sgp1sfo3fra1syd1