KAZCODE

Technical article

How to Offload WordPress Media to Cloudflare R2

A practical guide to using Cloudflare R2 for WordPress media offload without losing the native Media Library workflow.

By KAZCODE Published Updated
  • WordPress
  • Cloudflare R2
  • Media Offload
  • Object Storage

Cloudflare R2 can be a strong storage target for WordPress media when the site needs to move uploads away from local hosting disk while keeping the normal WordPress Media Library experience. The important part is not only copying files into a bucket; it is preserving attachment records, generated image sizes, restore paths, and a safe way to verify that remote objects are really present before local files are removed.

KAZCODE Universal Storage is built around that safety model. WordPress remains the source of truth for attachment metadata, while media binaries can live in Cloudflare R2 or another supported S3-compatible provider. The Free plugin is available on WordPress.org, and the Universal Storage landing page has the current Free and Pro feature overview.

What offloading should preserve

A WordPress media offload workflow should keep these parts intact:

  • attachment posts, titles, alt text, captions, and metadata
  • generated image sizes, not only the original upload
  • Media Library grid/list views, media modal, Featured Image, and editor workflows
  • a way to restore files back to wp-content/uploads
  • verification before local cleanup

If a setup only changes URLs or only uploads the original file, it can leave WordPress in a fragile state. The Media Library may still appear to work until an image size, editor flow, restore operation, or migration path needs data that was never tracked.

Basic Cloudflare R2 setup path

The usual setup flow is:

  1. Create a Cloudflare R2 bucket.
  2. Create an API token or S3-compatible access credentials for that bucket.
  3. Configure the bucket, account endpoint, region behavior, and credentials in the WordPress storage profile.
  4. Test the connection from WordPress.
  5. Enable offload for new uploads.
  6. Upload a new media item and confirm that the original plus generated sizes are present in R2.
  7. Migrate existing media in batches only after the new-upload path is verified.

The product docs cover the provider-specific setup path in Cloudflare R2 storage provider documentation.

Why verification matters

Removing local files is the risky part of any media offload workflow. A successful upload request is not the same as a durable, readable object that matches the file WordPress expects. KAZCODE Universal Storage treats verification as a separate safety step and keeps local files unless the remote object can be confirmed.

Temporary provider errors should not be treated as proof that a file is missing. In a safe workflow, timeouts, throttling, authentication failures, and provider outages are classified as unknown/provider errors rather than confirmed missing media. That prevents cleanup or repair tooling from making destructive decisions based on incomplete evidence.

For operational details, see the docs on verifying media and local cleanup.

When R2 becomes part of a migration

Some sites start fresh with R2. Others already use Amazon S3 or another provider and want to move existing media to R2. In that case, the safest migration path is a verified cutover:

  1. Keep the source provider serving media.
  2. Copy objects to the R2 destination profile.
  3. Verify destination objects.
  4. Switch delivery only after verification succeeds.
  5. Delete source objects only after the destination is proven and the operator chooses to do so.

That cross-provider migration workflow is a KAZCODE Universal Storage Pro capability. The implementation-level docs are available in cross-provider migration and Amazon S3 to Cloudflare R2 migration. Teams planning provider-to-provider moves can review Universal Storage Pro pricing after confirming the migration workflow matches their operational needs. For a deeper migration runbook, see Move WordPress Media from Amazon S3 to Cloudflare R2 Safely.

A practical first milestone

Before migrating an entire Media Library, prove the smallest complete path:

  • one working R2 storage profile
  • one new uploaded image
  • every generated size visible in the object inventory
  • delivery URLs resolving from the configured profile
  • restore tested on a non-critical attachment
  • local cleanup tested only after verification

That small milestone catches most credential, endpoint, permission, URL, and generated image-size issues before they become batch migration problems.

Start with the KAZCODE Universal Storage landing page or the getting started docs when you are ready to connect WordPress to Cloudflare R2.