← Back to Blog

Media CDNs and External Storage

Design a media-delivery architecture that separates storage, origin, transformation and edge caching responsibilities.

Veyra Admin

4 min read

  • Guide
  • Intermediate
  • 4 minutes read
  • Reviewed August 5, 2026
  • WordPress media

A content delivery network and an external storage system solve related but different problems.

A CDN caches media closer to visitors. Object storage holds files outside the local WordPress server. An image service may also transform files by format, quality or dimensions.

Local Origin with a CDN

In a simple model, WordPress stores files locally and media URLs point to a CDN hostname or are intercepted by a caching layer.

Advantages include faster global delivery and reduced origin traffic. The local uploads directory remains the source of truth.

Offloaded Object Storage

An offload system copies or moves files to object storage and stores remote-location information with the attachment.

Questions to answer:

  • Are local files retained or removed?
  • Does WordPress generate sub-sizes before or after offload?
  • How are private files protected?
  • What happens if the plugin is disabled?
  • Can the library be restored to local storage?
  • Are attachment URLs stable?
  • How are backups performed?

URL Rewriting

Media URLs may be rewritten in HTML output, stored content, attachment metadata or at the network layer.

Prefer a reversible implementation that uses WordPress APIs and attachment IDs. Bulk replacing URLs directly in serialized data creates migration risk.

Image Transformation Services

A transformation CDN can create resized or converted variants on demand.

This may reduce local generated files, but introduces provider-specific URLs, billing, security rules and cache behaviour. Confirm how transformations interact with WordPress srcset, signed URLs and original-file retention.

Cache Invalidation

Replacing a file at the same URL can leave old content in browser and edge caches.

Use versioned URLs, explicit invalidation or a service with understood cache controls. Do not assume that clearing a WordPress page cache clears every media edge.

Privacy and Access Control

Public CDN URLs are unsuitable for confidential documents unless the system supports authorization, signed URLs and appropriate cache restrictions.

A private page does not automatically make its embedded media private.

Backups

A database backup does not include remote objects. A local-file backup may be incomplete after offload.

Document:

  • Which system contains originals.
  • Whether generated derivatives can be recreated.
  • How object versions are retained.
  • How credentials are restored.
  • How a full recovery is tested.

Provider Exit Plan

Before adopting a provider, test how to:

  1. Export all original and generated files.
  2. Restore attachment metadata.
  3. Rewrite URLs safely.
  4. Disable offload without breaking old content.
  5. Preserve redirects or aliases.
  6. Verify checksums and counts.

An exit plan is part of the architecture, not a future problem.

Applying Media CDNs and External Storage in a Real WordPress Project

Consider the source asset, WordPress attachment record, generated files and every public use of the media. Accessibility, licensing, storage, performance and deletion safety should be reviewed together.

A connected concept is Content Delivery Networks. Reading the two together helps separate the immediate task from the wider WordPress responsibility.

A useful implementation begins by writing down the current state, the intended outcome and the evidence that will prove the change worked. This prevents a configuration screen, plugin recommendation or code snippet from becoming the entire strategy.

A Practical Example

Imagine a team making this decision for a production WordPress site. The useful question is not only “Can WordPress do this?” but “Which layer owns it, who maintains it, what data does it affect and how will we verify it after an update?”

Write the answer in operational terms. Name the content, user, setting, file, API or service involved. Then identify what should remain true if the theme changes, a plugin is replaced or the site is migrated.

Questions to Ask

  • What user or system problem does this solve?
  • Which WordPress layer owns the behaviour?
  • What data is created or changed?
  • Who may perform the action?
  • What can fail, and how will that failure be visible?
  • How is the result tested after updates?
  • What is the migration or removal path?

Follow the Complete Media Lifecycle

A media decision begins with the source file and continues through upload, attachment metadata, generated derivatives, delivery, reuse, replacement and deletion.

Review visual quality, accessibility text, licensing, dimensions, file weight, cache behaviour and every place the asset is referenced. WordPress can track an attachment record, but it cannot always identify every use created by themes, custom fields or external systems.

Official Reference Context

The WordPress Media Library Documentation is the primary version-specific reference for this topic. Use the current documentation to verify interface labels, supported APIs and behaviour before applying instructions to a production site.

How to Verify the Result

  • Check the original file, generated sizes and frontend delivery.
  • Verify alternative text, captions, credits and direct-file visibility.
  • Search for references before replacing or deleting the attachment.

Sources and Further Reading

Continue Learning