DigitalOcean Spaces are object storage, not a filesystem, and the CDN is a caching layer in front of it, not a replacement for the storage itself.
Let’s see what this looks like in practice.
Imagine you have a website with a lot of static assets: images, CSS files, JavaScript. Instead of serving these directly from your web server (which adds load and can be slow for users far away), you can offload them to DigitalOcean Spaces and serve them through their CDN.
First, you create a Space. Let’s call it my-awesome-app-assets. You pick a region, say nyc3. This gives you a unique endpoint like my-awesome-app-assets.nyc3.digitaloceanspaces.com.
Then, you upload your files. A logo.png might go to the root of your Space.
doctl compute object-storage object-create --space-name my-awesome-app-assets --key logo.png --file ./logo.png
Now, you enable the CDN for this Space. You’ll get a new CDN endpoint, something like abc123xyz.cdn.digitaloceanspaces.com.
To serve your logo.png through the CDN, you’d update your website’s HTML to reference this new URL:
<img src="https://abc123xyz.cdn.digitaloceanspaces.com/logo.png" alt="My App Logo">
When a user requests this image, their browser hits the CDN endpoint. If the CDN has a cached copy (because someone else requested it recently, or you pushed it there), it serves it directly. This is incredibly fast, as the CDN edge server is geographically close to the user. If it’s not cached, the CDN fetches it from your Space (my-awesome-app-assets.nyc3.digitaloceanspaces.com), caches it, and then serves it to the user. Subsequent requests for the same file will then hit the cache.
The core problem this solves is scaling static asset delivery. As your user base grows, serving millions of images from your single web server becomes a bottleneck. By using Spaces and a CDN, you decouple static asset serving from your application’s compute. The CDN handles the high volume of requests and the geographical distribution, while Spaces provide durable, cost-effective storage.
Internally, Spaces use S3-compatible APIs. This means you can use standard tools like aws-cli (configured for DigitalOcean) or doctl to interact with them. The CDN is a separate network of servers that mirrors (caches) your Space’s content. You control which Space gets a CDN, and you can set cache expiration rules (TTL - Time To Live). A common TTL is 24 hours, meaning the CDN will check for updates to a file at least once a day.
The key levers you control are:
- Space Name: A unique identifier for your storage bucket.
- Region: Where your data is physically stored. This affects latency for direct Space access.
- CDN Endpoint: The URL for serving content via the CDN.
- File Paths (Keys): How your files are organized within the Space.
- Cache TTL: How long the CDN holds onto a copy of your files before checking the Space for updates.
When you upload a file to a Space that has CDN enabled, the CDN doesn’t automatically ingest it. The first request for that new file will trigger the CDN to fetch it from the Space. If you need to pre-warm the CDN cache with new files, you’d typically do this by making a programmatic request to the CDN URL for each new file, or by using a tool that can push content directly to the CDN (though this is less common with DigitalOcean’s offering, which relies on on-demand fetching).
The next concept you’ll run into is invalidating or purging the CDN cache when you update a file in your Space, to ensure users get the latest version immediately.