DigitalOcean Spaces CDN Guide 2026 — Speed Up Your Website

A practical guide to configuring DigitalOcean Spaces CDN endpoints, custom subdomains, and cache purge/TTL management for faster static asset delivery.

DigitalOcean Spaces comes with a built-in CDN that can be enabled instantly without relying on external services. It helps reduce load times for static files like images, videos, and downloads for users worldwide. This article dives deep into CDN features—from enabling endpoints and binding custom subdomains with SSL to managing cache purge and TTL settings that many developers often misconfigure.

What is Spaces CDN and How Does It Work with Object Storage?

Spaces is DigitalOcean's Object Storage service that is compatible with the S3 API, used for storing static files such as images, videos, backups, or downloadable files. Every Space created automatically includes a built-in CDN that can be enabled without additional cost beyond the standard Spaces pricing. This differs from some providers that charge separately for CDN service or require third-party integration like Cloudflare or Fastly. The way it works is: when you enable CDN, DigitalOcean creates a new endpoint in the format your-space.region.cdn.digitaloceanspaces.com, which is different from the origin endpoint (origin) at your-space.region.digitaloceanspaces.com. When a file is requested through the CDN endpoint, the system first checks if it's cached on an edge server near the user. If it's cached (cache hit), the file is returned immediately without fetching from the origin Space. If it's not cached (cache miss), the system fetches the file from the origin, stores it at the edge, and then delivers it to the user. On subsequent requests for the same file from nearby regions, it will result in a cache hit immediately. The main benefit of this architecture is reduced latency for users far from the origin region. For example, if your Space is in sgp1 (Singapore), users in Europe requesting files through the CDN will get them from a closer edge location instead of waiting across regions. It also reduces the bandwidth load on the origin Space since most requests after caching won't reach it directly. It's important to understand that Spaces CDN works as a pull-based cache, not a push CDN. The system doesn't copy all files in advance; instead, it pulls and caches files only when they're actually requested (lazy caching). This suits websites with many files that aren't accessed equally, since you don't need to preload everything. Since Spaces uses the same S3-compatible API, enabling CDN doesn't affect existing code that uploads or manages files—you just need to change the URL reference from the origin endpoint to the CDN endpoint.

• CDN is built into every Space and can be enabled directly from the control panel
• CDN endpoint is separate from the origin endpoint (contains 'cdn.' before the region)
• Works as a pull-based cache, fetching files from origin only when actually requested
• Uses the same S3-compatible API; no need to change how you upload files
• Reduces latency and bandwidth load on the origin Space with no additional cost

Pricing Starting at $5/Month (CDN Included)

DigitalOcean Spaces starts at $5 per month, and the CDN feature is included in this tier with no additional separate charges. This differs from some services that charge for CDN usage separately based on bandwidth consumption, making budget forecasting simpler for teams with limited budgets (as of July 2026—check the latest pricing and storage/bandwidth quotas on DigitalOcean's official pricing page, as quota details may change). For new users, DigitalOcean offers a $200 free trial credit valid for 60 days after signup (requires credit card or PayPal verification). This is enough to test enabling a Space with CDN and experiment with upload/cache purge workflows before committing to long-term usage. If interested, you can get started at Get $200 Free Credit → One cost consideration is overage charges. If you use storage or bandwidth beyond what's included in the $5/month plan, you'll be charged for the excess. For high-traffic websites or large media files (like HD videos), you should monitor usage through the Billing Dashboard regularly to avoid unexpected charges. Compare this with alternatives like running storage on a Droplet yourself (which has no built-in CDN and requires additional setup with Cloudflare or a separate CDN service). In terms of comparison, Spaces CDN suits teams wanting simplicity—no separate origin server setup, no manual cache layer management, and combined storage/CDN billing. This reduces complexity compared to integrating third-party CDN with storage from different providers.

• Spaces starts at $5/month with CDN included; no separate CDN charges
• New users receive $200 free trial credit valid for 60 days after signup
• Always verify latest pricing on DigitalOcean's official page as quotas may change

Enabling the CDN Endpoint

Enabling CDN for a Space is straightforward through DigitalOcean's control panel. Navigate to Spaces, select your Space, go to the Settings tab, and you'll find the option to enable CDN. Once enabled, the system immediately creates a new endpoint in the format your-space.region.cdn.digitaloceanspaces.com. You can copy this URL and use it instead of the original origin endpoint in your website or application code right away. For those preferring command line management, you can use doctl, DigitalOcean's official CLI. After authenticating with a Personal Access Token, basic CDN endpoint commands are under doctl compute cdn, such as doctl compute cdn create --origin your-space.sgp1.digitaloceanspaces.com --ttl 3600, which creates a CDN endpoint linked to the specified origin with an initial TTL setting. This approach works well for teams wanting infrastructure as code or automation in their deployment pipeline. After creating the endpoint, you can list all CDN endpoints in your account with doctl compute cdn list, which displays the ID, origin, endpoint URL, and current TTL value. The ID is necessary for future commands like updating TTL, binding custom domains, or purging cache. One thing to note: the CDN endpoint covers the entire Space—you can't enable CDN for just certain paths or specific objects. If you need different caching behavior for different file types, consider separating them into different Spaces (one for long-lived static assets, another for frequently-updated files). Also, before enabling CDN, ensure the objects you want accessible through CDN have their permissions set to public-read; otherwise, the CDN will return errors instead of files even if the endpoint is created successfully.

1. Enable CDN from Spaces → select your Space → Settings tab in the control panel
2. Create endpoint via CLI using doctl compute cdn create --origin ... --ttl ...
3. List existing endpoints with doctl compute cdn list
4. CDN covers the entire Space; you cannot enable it for specific paths only

Setting Up Custom Subdomain + SSL

By default, the CDN endpoint DigitalOcean creates uses the format your-space.region.cdn.digitaloceanspaces.com, which works immediately with DigitalOcean's SSL certificate. However, for websites wanting brand consistency (such as having static file URLs start with your own domain like cdn.yourdomain.com), you can bind a custom subdomain to the CDN endpoint. Start by logging into your DNS provider (whether DigitalOcean DNS or another service) and create a CNAME record pointing from your desired subdomain (e.g., cdn) to your CDN endpoint, like cdn.yourdomain.com CNAME your-space.sgp1.cdn.digitaloceanspaces.com. Then return to your Space's Settings page, find the CDN section, enter the custom subdomain, and select an SSL certificate. For SSL, you have two main options: use a Let's Encrypt certificate that DigitalOcean automatically issues through its Certificate Manager (with automatic renewal), or upload your own certificate if you already have one from another provider. You must select one of these during custom subdomain setup to use HTTPS correctly. Skipping this step will result in a certificate error when accessing via HTTPS on the custom domain, since the certificate won't cover the bound domain. Via CLI, you can update an existing CDN endpoint to bind a custom domain and certificate using doctl compute cdn update <cdn-id> --domain cdn.yourdomain.com --certificate-id <certificate-id>, where the certificate-id must be a certificate already uploaded or issued in your account through the Certificates menu. Common mistakes include forgetting to wait for DNS to propagate, or creating a CNAME pointing to the origin endpoint instead of the CDN endpoint, which defeats the caching benefit.

1. Create a CNAME record pointing your subdomain to the CDN endpoint before binding in control panel
2. Choose between a Let's Encrypt certificate (auto-renewed) or upload your own
3. Update via CLI using doctl compute cdn update with domain and certificate-id flags
4. Wait for DNS propagation and select a certificate first, or HTTPS will error

Cache Purge and TTL Management

TTL (Time To Live) is how long a file stays in edge cache before the system checks the origin Space again for changes. You set this value when creating the CDN endpoint via the --ttl parameter (in seconds) and can adjust it later through both the control panel and doctl compute cdn update commands. Generally, set longer TTLs for rarely-changing files like logos, fonts, or fixed-version libraries to maximize cache hits, and shorter TTLs for frequently-updated content. When you update a file at the origin Space but the edge cache still holds the old version (because TTL hasn't expired), users may see stale content until cache expires. The fix is to purge the cache—DigitalOcean calls this flush—either from the control panel by selecting your Space, going to the CDN section, and clicking flush, or via CLI using doctl compute cdn flush <cdn-id> --files "*" to clear everything, or --files "images/logo.png" to purge only specific files without affecting well-cached content elsewhere. Flushing everything too often reduces cache hit ratio temporarily, because every request after a flush becomes a cache miss, fetching from origin again. This increases origin load and may temporarily slow responses for some users while cache rebuilds. A better approach is to purge only files that actually changed, rather than flushing the entire Space with each update. Another technique that reduces frequent purges is cache-busting through filename versioning. Instead of using style.css, change filenames to style.a1b2c3.css with each update. The new URL won't match old cache automatically, eliminating the need for purge commands, and also avoids browser-side cache issues where client browsers might ignore CDN TTL.

• Set TTL when creating the endpoint via --ttl and update later through panel or CLI
• Purge/flush cache from control panel or using doctl compute cdn flush
• Specify specific file paths in flush commands to avoid impacting other cached files

When to Use This Feature (Real-World Use Cases)

Spaces CDN works well when your website or application needs to deliver many static files to geographically distributed users. The most common example is WordPress or e-commerce sites with many product images. Moving all media files to Spaces and enabling CDN reduces disk I/O and bandwidth load on the Droplet running WordPress directly, speeding up the site for both the server and end-users. Another scenario is applications involving user uploads/downloads, like file-sharing platforms, document management systems, or apps with user-generated content such as profile pictures and short videos. Using Spaces as primary storage with CDN means files don't need to pass through the application server every time they're viewed, reducing backend load and enabling easier scaling as user numbers grow. For software development teams distributing downloads (installers, firmware) or static web app assets (JavaScript bundles, fonts, CSS), using CDN endpoints instead of having a single Droplet serve all files reduces the risk of server overload during simultaneous downloads, like when releasing a new version. Conversely, Spaces CDN isn't ideal for real-time, constantly-changing content like live API responses or dynamically-rendered pages personalized per user. These should stay on your Droplet or App Platform as normal; use CDN only for static assets. Also, if you need advanced features like edge computing, built-in WAF, or automatic image optimization, you may want to add Cloudflare or a specialized CDN in front of Spaces.

• WordPress/e-commerce with many product images; reduces Droplet load
• Apps with user-generated content like profile pictures, short videos, attachments
• Distributing downloads like installers, firmware, or web app static assets
• Not suitable for dynamic/real-time content needing latest data on every request
• Need advanced features like WAF or image optimization? Add Cloudflare in front

Common Mistakes and How to Fix Them

In practice, the most common mistake is forgetting to set object permissions to public-read before uploading. Even if the CDN endpoint is created successfully and the URL looks correct, requesting a file returns an error instead of the actual file. To fix this, check the ACL of each object in the control panel, or set default permissions to public-read during upload via API/SDK so you don't have to adjust every file afterward. Another frequent confusion is mixing up the origin endpoint with the CDN endpoint. Some development teams keep referencing your-space.region.digitaloceanspaces.com in application code even though they intend to use CDN, so every request goes straight to origin without benefiting from caching at all. Always verify that your config or environment variables storing the base URL for static files point to the endpoint containing cdn.. Cache not updating after file changes is another common issue, especially for teams editing CSS/JS with the same filename and forgetting to purge. Users see stale content longer than expected. Short-term fix: purge cache for only the changed files. Long-term fix: update your deployment workflow to use cache-busting filenames automatically. Testing a custom subdomain without waiting for DNS propagation first makes people think configuration failed when it hasn't. DNS can take minutes to hours to spread globally (depending on the old DNS record's TTL), so check with dig or nslookup before concluding there's a DigitalOcean-side problem. Finally, not setting up CORS headers when files in Spaces are fetched from different domains causes problems. For example, if your main website calls fonts or JavaScript from the CDN endpoint on a different domain, browsers will block them with CORS errors unless you configure CORS policy at the Space level, even though the files are publicly accessible when opened directly.

• Forgot to set object permission to public-read, resulting in CDN errors instead of files
• Reference origin endpoint instead of CDN endpoint in code, missing caching benefits entirely
• Update files but forget to purge cache, leaving users seeing stale versions for too long
• Test custom subdomain before DNS propagates, incorrectly concluding setup failed

Best Practices

To use Spaces CDN efficiently and avoid the common mistakes above, follow several best practices from the start. First, separate Spaces by use case: one Space for static website assets (long cache TTL), another for user-uploaded files or frequently-changed content. This lets you configure TTL and permissions appropriately per group without conflicts. Second, make cache-busting filenames the standard for frequently-updated static files like CSS/JS bundles. Add content hash or build numbers to filenames so you don't rely on manual purges, and avoid browser cache issues on the client side too. This is the standard practice that modern build tools like Webpack and Vite already support. Third, set TTL appropriately per file type instead of using one value everywhere. Files that rarely change (fonts, icons) should have longer TTLs to maximize cache hits, while updateable files should have shorter TTLs or use cache-busting. Test actual caching behavior by checking response headers after fetching files through the CDN to confirm settings work as expected. Fourth, manage permissions and CORS policy systematically at the Space level from the start, not file-by-file later. Set default ACL and CORS rules covering all domains that will actually use them, and restrict to necessary domains only rather than allowing wildcards for security. Finally, monitor bandwidth and storage usage regularly via the Billing Dashboard, especially during traffic spikes (promotions, viral content) to stay within plan quotas. If you want infrastructure-as-code, manage CDN endpoint creation/updates through Terraform's official DigitalOcean provider instead of manual panel configuration, so settings are version-controlled and reproducible when recreating environments.

• Separate Spaces by use case to set appropriate TTL/permissions per group
• Use cache-busting filenames (content hash) instead of manual purges
• Set TTL appropriate to file type and test response headers to verify behavior
• Configure default ACL/CORS policy at Space level early; restrict to necessary domains only
• Monitor bandwidth/storage via Billing Dashboard; use Terraform for infrastructure-as-code management

Get $200 Free Credit →