Host a static site on DigitalOcean Spaces with S3 API website config and CDN
Use Spaces with static website hosting and CDN for low-cost SPA hosting. Configure the bucket website settings, CORS and a custom domain with HTTPS, and be aware of eventual consistency, bucket naming and 5TB limits.
14 Nov 2025, 01:55 UTC

Use DigitalOcean Spaces with static website hosting enabled and the Spaces CDN in front for cheap, globally cached hosting of single-page applications and web assets. The useful takeaway is to treat Spaces as an object store with a website endpoint, not a web server, and configure the bucket website settings, CORS, and a custom domain with HTTPS up front.
What Spaces website hosting actually does
Spaces is an S3-compatible object storage service. Each bucket holds objects with keys and metadata. When website hosting is enabled on a bucket, DigitalOcean exposes a website endpoint for that bucket that serves objects as static files. The endpoint can serve an IndexDocument for directory requests and an ErrorDocument for missing keys. Spaces does not support server-side processing, redirects are limited to the website configuration, and there is no compute.
For global delivery you can attach DigitalOcean's CDN to the bucket. The CDN fronts the Spaces endpoint with HTTP and HTTPS endpoints and caches objects at edge locations. The origin remains S3-compatible, so uploads and management continue via the S3 API.
Mechanism with one worked configuration
The website configuration is stored on the bucket. It can be set in the control panel or via the S3 API. The API call requires a Spaces access key with write permissions for the bucket and is run from a terminal where the key is available via environment variables. Do not commit access keys to version control.
Example request to enable website hosting with index.html. Replace placeholders with your values. The region in the hostname must match the bucket region, e.g. nyc3.
curl -X PUT 'https://nyc3.digitaloceanspaces.com/BUCKET_NAME?website-enabled=true' -H 'Content-Type: application/xml' -H 'Authorization: AWS4-HMAC-SHA256 Credential=ACCESS_KEY/20200101/nyc3/s3/aws4_request,SignedHeaders=host;x-amz-date,Signature=...' -d '<WebsiteConfiguration><IndexDocument><Suffix>index.html</Suffix></IndexDocument></WebsiteConfiguration>'Risk: the request overwrites the existing website configuration for the bucket. A PUT with no body or a different suffix will change which file is served for root requests. Bucket names must be globally unique across all DigitalOcean customers, so choose a name you can keep.
After the configuration is in place, upload objects with the S3 API or control panel. Set the object ACL or bucket policy to public read for the files you want served. For a single-page application, upload index.html to the bucket root and place assets under a prefix such as /assets/. Because Spaces has eventual consistency for object listing operations, a newly uploaded object may not appear in listings immediately, though GET by key is typically fast.
Common CORS mistake when serving web assets from a different origin. If your SPA loads fonts, images or API calls from another domain, the browser will require CORS headers. Set a CORS rule on the bucket for the allowed origin, methods and headers. Without it, browsers block the requests even though the objects are publicly readable.
Limits and practical checks
Size and naming limits. Spaces enforces a 5TB per bucket size limit. Large datasets require multiple buckets. Bucket names are global, so creation can fail if the name is taken.
HTTPS and custom domains. The native Spaces website endpoint provides HTTP and HTTPS. For a branded domain you need to add a custom domain and configure HTTPS through DigitalOcean. Static website hosting requires HTTPS configuration through custom domains for production use.
Consistency and caching. Object listing is eventually consistent. Verify uploads by fetching the object directly by key rather than relying on listing. For CDN, check propagation with dig or nslookup for the CDN endpoint domain to confirm the CNAME points to the Spaces CDN.
Practical verification you can do without assuming current pricing. Create a test bucket in the control panel and enable website hosting. Upload a test HTML file and verify the public website endpoint serves content correctly. Review the Spaces pricing page for current storage and bandwidth costs before committing to production traffic.
Operational hygiene. Rotate Spaces access keys regularly and never commit them to version control systems. Use least-privilege IAM policies for upload and read roles. Remember Spaces serves only static files from configured endpoints, so dynamic routing, server-side rendering and redirects beyond the website configuration are not supported.
0 replies
A thoughtful contribution can make all the difference. Be the first to share one.