XeroWP
DiluxOne Offload – Media Storage
DiluxOne Offload – Media Storage

DiluxOne Offload – Media Storage

0/5 (0 ratings) — active installs Updated Oct 8, 2026
Azurecloud storageoffloads3uploads
Download v2.1.0 Plugin Website
Overview: provider configured, media synced, offloading active.

Overview: provider configured, media synced, offloading active.

DiluxOne Offload moves your WordPress media library to Azure Blob Storage or to any S3-compatible service (Amazon S3, Cloudflare R2, Backblaze B2, DigitalOcean Spaces, Wasabi, Google Cloud Storage, Hetzner, Akamai (Linode), Vultr, Scaleway, OVHcloud, IDrive e2, MinIO) and serves files directly from the cloud — without breaking the Media Library UI, plugins, or existing content.

The plugin uses a custom PHP stream wrapper to intercept every read and write to /wp-content/uploads/, so WordPress, WooCommerce, page builders, image editors, and any plugin that calls standard filesystem functions (fopen, file_get_contents, unlink, etc.) keep working unchanged.

Key features

  • Azure Blob Storage or S3-compatible storage — bring your own storage account or bucket; nothing is shared with anyone else. For S3-compatible services, pick the service and the plugin fills in the endpoint and the public URL; a CDN or a custom domain goes in the Public URL field.
  • Transparent stream wrapper — no URL rewriting, no regex on post content, no database migration required for URLs.
  • Sync with resumable state machine — start, cancel, resume after an interruption, retry failed files, resync from scratch.
  • Offloading mode — after a successful sync you can delete the local copies to free disk space; the stream wrapper keeps everything working.
  • Connection health monitoring — when the cloud is unreachable, new uploads are refused with a clear error instead of landing somewhere else, and a banner on the plugin’s admin pages says why until it recovers.
  • No plugin data on disk — no cache, log or data files anywhere on the server. The one time the plugin writes to the uploads directory is when you disconnect, to copy your own media back to where WordPress expects it.
  • Large files don’t need large memory — a download goes straight to disk, and an upload is sent in blocks (4 MiB on Azure, 5 MiB parts on S3-compatible services, larger only for a file too big for the service’s limit on parts, past about 5 GB on Scaleway or 48 GB elsewhere), so PHP never holds more than one block of a file at a time and a video does not trip memory_limit.
  • Multisite aware — network activation supported; each site keeps its own configuration and file tracking, and its objects live under their own prefix in the container or bucket (uploads/ for the main site, uploads/sites/<id>/ for the others, the same layout WordPress uses on disk), so several sites can share one container or bucket without ever sharing a key.
  • Quiet by default — with WP_DEBUG off and the Settings toggle off the plugin writes nothing to the PHP error log, at any level. WP_DEBUG turns on errors and warnings; the toggle adds the informational lines.

Why a stream wrapper instead of URL rewriting

Most offload plugins rewrite media URLs in post content, which breaks when you switch providers, move domains, or restore from a backup. DiluxOne Offload leaves URLs alone and rewrites reads/writes at the filesystem layer, so your content stays portable.

Known limitations

  • The media must be publicly readable where it is stored: on Azure, a container whose public access level is Blob; on S3-compatible services, a bucket that lets anyone read its objects. Test Connection checks it and refuses a private one.
  • The initial sync runs in your browser tab and stops if you close it; it resumes where it left off. Nothing runs in the background or via cron.
  • Files above the Maximum File Size setting (20 MB by default, up to 500 MB) are skipped by the initial sync.
  • While the cloud is unreachable, new uploads fail. There is deliberately no local fallback.
  • On Azure, media is served from the storage account’s URL; on S3-compatible services the Public URL field is where a CDN or custom domain goes.
  • Disconnect from Cloud needs a writable uploads directory and enough disk for your media.

External services

This plugin connects to one cloud storage service, the one you choose: Azure Blob Storage, or an S3-compatible service (Amazon S3, Cloudflare R2, Backblaze B2, DigitalOcean Spaces, Wasabi, Google Cloud Storage, Hetzner Object Storage, Akamai (Linode) Object Storage, Vultr Object Storage, Scaleway Object Storage, OVHcloud Object Storage, IDrive e2, or a server whose address you type). It uses it to store and serve your media files. Nothing is sent anywhere until you configure it yourself in the Cloud Provider tab, with an account and credentials you supply. The plugin contacts no other service: it sends no telemetry, no usage data and no licence check to the author or to anyone else.

Azure Blob Storage

What it is used for: storing your WordPress media files outside your server and serving them from the cloud.

Where requests go: the Azure Blob REST API at blob.core.windows.net — specifically your own account’s host, https://ACCOUNT.blob.core.windows.net, where ACCOUNT is the storage account name you enter in the settings.

What data is sent: your media files themselves, together with their relative path, size and MIME type. The storage account key you entered never leaves your server — it is used locally to compute the signature that authenticates each request. No personal data about your visitors or your site’s users is sent, and nothing at all about your site reaches the plugin’s author.

When requests happen:

  • During the initial sync — uploading existing files from /wp-content/uploads/ to your container.
  • On every new media upload — writing the file to the cloud through the stream wrapper.
  • On read or delete — when WordPress, or any plugin using filesystem APIs against /uploads/, reads or deletes a file. This is also the only front-end traffic: a form or a review that uploads a file goes through the same stream wrapper.
  • When the plugin lists your container — for the Overview statistics (cached for five minutes) and for the scan that precedes Disconnect from Cloud.
  • A connection-health check — a small GET for your container’s properties — when you open one of the plugin’s admin pages, at most once every 5 minutes, and again from a write that follows three consecutive failures, so uploads resume on their own when the cloud is back. Nothing runs via cron.
  • During Disconnect from Cloud — downloading your files back to the server.

This is your own Azure account, under your own agreement with Microsoft. Neither DiluxOne nor the plugin’s author is a party to it and neither has any access to your data. Your use of the service is subject to Microsoft’s terms:

S3-compatible storage

What it is used for: the same as above, on the S3-compatible service you choose.

Where requests go: the endpoint of the service you chose, which the form fills in for each service and you can change: Amazon S3 at https://s3.REGION.amazonaws.com (requests address https://BUCKET.s3.REGION.amazonaws.com), Cloudflare R2 at https://ACCOUNT_ID.r2.cloudflarestorage.com, Backblaze B2 at https://s3.REGION.backblazeb2.com, DigitalOcean Spaces at https://REGION.digitaloceanspaces.com, Wasabi at https://s3.REGION.wasabisys.com, Google Cloud Storage at https://storage.googleapis.com, Hetzner Object Storage at https://REGION.your-objectstorage.com, Akamai (Linode) Object Storage at https://REGION.linodeobjects.com, Vultr Object Storage at https://REGION.vultrobjects.com, Scaleway Object Storage at https://s3.REGION.scw.cloud, OVHcloud Object Storage at https://s3.REGION.io.cloud.ovh.net, IDrive e2 at https://s3.REGION.idrivee2.com (or the endpoint of your own its dashboard shows), or the address you type under Custom. Browsers load your media from the Public URL you set, which can be the service’s own address, a CDN or a custom domain.

What data is sent: your media files themselves, together with their relative path (the object key), size and MIME type, and a signature of each request computed from your secret access key. The secret itself never leaves your server. No personal data about your visitors or your site’s users is sent, and nothing at all about your site reaches the plugin’s author.

When requests happen: the same moments as for Azure above. The connection check is different: when you press Test Connection, and at most every five minutes while you browse the plugin’s admin pages, the plugin writes a 32-byte probe object under your site’s prefix, reads it back from the Public URL without credentials (to prove browsers can load your media) and deletes it.

This is your own account with that service, under your own agreement with its provider. Neither DiluxOne nor the plugin’s author is a party to it and neither has any access to your data. Your use of the service is subject to its provider’s terms:

Amazon S3:

Cloudflare R2:

Backblaze B2:

DigitalOcean Spaces:

Wasabi:

Google Cloud Storage:

Hetzner Object Storage:

Akamai (Linode) Object Storage:

Vultr Object Storage:

Scaleway Object Storage:

OVHcloud Object Storage:

IDrive e2:

Custom endpoint: the plugin talks only to the server whose address you typed (MinIO, Ceph or any other that speaks the S3 API). No third party is involved unless that server belongs to one you chose.