How to Offload Static Assets to DigitalOcean Spaces

Question

Serving static files directly from your Droplet or App Platform works… until it doesn’t. Disk fills up, containers restart, deploys get slower, and suddenly your app is doing work it shouldn’t be doing.

DigitalOcean Spaces is a simple way to offload static assets like images, videos, PDFs, and downloads without redesigning your architecture.

This mini tutorial shows how to move static content to Spaces and serve it via CDN.

alexdo · Accepted Answer

Heya all, How to Offload Static Assets to DigitalOcean Spaces (and Keep Your App Fast) DigitalOcean Spaces is a simple way to offload static assets like images, videos, PDFs, and downloads without redesigning your architecture. This tutorial shows how to move static content to Spaces and serve it via CDN. What you should offload to Spaces Spaces is ideal for: User-uploaded images and media Public downloads (PDFs, ZIPs, audio, video) Static frontend assets that rarely change Backup artifacts It is not a shared filesystem or a replacement for your database. Step 1: Create a Space From the DigitalOcean control panel: Create a new Space Pick a region close to your app Choose Public if assets are user-facing Enable the CDN if files will be accessed frequently Your Space endpoint will look like: https://my-space.fra1.digitaloceanspaces.com With CDN enabled: https://my-space.fra1.cdn.digitaloceanspaces.com Step 2: Create an access key Create a Spaces access key with: Read access (for serving files) Write access (for uploads) No Droplet or account-wide permissions are required. Store these as environment variables: SPACES_KEY=xxx SPACES_SECRET=xxx SPACES_REGION=fra1 SPACES_BUCKET=my-space SPACES_ENDPOINT=https://fra1.digitaloceanspaces.com Step 3: Upload static files to Spaces You can upload files using: The DigitalOcean UI (good for one-off uploads) aws s3 CLI Your application code Example using CLI: aws s3 cp ./images s3://my-space/images \ --recursive \ --endpoint-url https://fra1.digitaloceanspaces.com Files will immediately be available via the CDN URL. Step 4: Serve assets from Spaces instead of your app Update your app to reference assets from Spaces instead of local disk. Example: <img src="https://my-space.fra1.cdn.digitaloceanspaces.com/images/logo.png" /> For frameworks: Django → set STATIC_URL or MEDIA_URL to the CDN Laravel → configure filesystem disk to Spaces Next.js → use Spaces CDN as your image host At this point, your app no longer needs to serve these files. Step 5: Upload new files directly to Spaces For user uploads, don’t proxy files through your backend if you can avoid it. Better pattern: Frontend uploads directly to Spaces Backend stores the object key or URL Clients load files from the CDN This reduces: App memory usage Request latency Timeouts under load Step 6: Cache behavior and invalidation Spaces CDN caches aggressively. Good practices: Use versioned filenames (image.v2.jpg) Avoid overwriting files in-place Set long cache headers for static assets If you must replace a file, change the filename. Common mistakes Serving static assets from your app “because it’s easy” Using Spaces as a shared filesystem Storing temporary or session data in Spaces Assuming CDN errors mean data loss (they don’t) Why this setup works well Your app focuses on logic Spaces handles durability and delivery CDN absorbs traffic spikes Deploys get faster Disk usage stays predictable This is one of the simplest wins you can make when moving beyond a single-server setup. Final thoughts If your Droplet disappears tomorrow and your static assets are still available, you’ve done it right.

Bobby · Answer

Hi there,

This is a great pattern and something I’d strongly recommend for most apps.

Keeping large static files on the Droplet or inside containers almost always becomes a problem over time, as you mentioned: disk pressure, slower deploys, and unnecessary load on the app layer.

Using DigitalOcean Spaces for assets is usually the cleanest solution: