DiluxOne Offload – Media Storage
Move your media to cloud object storage and serve it from there. Replaces /uploads/ transparently, with no URL rewriting.
Solid choice
DiluxOne Offload – Media Storage is a solid plugin choice in 2026, with a few things worth checking first. Was last updated 4 days ago, and scores 64/100 on our health check.
- Actively developed — last update 4 days ago
- Tested with the latest WordPress (7.1)
- Small user base (<10 active installs)
- Very few reviews so far
How does it stack up?
Side-by-side on installs, updates, ratings & support
Daily downloads
Download spikes usually follow a new release — each site that auto-updates counts as a download.
Rankings
Where DiluxOne Offload stands todayWordPress.org search rankings
Live position in the plugin search, top 100| Keyword | Position |
|---|---|
| Azure | #93 |
| cloud storage | >100 |
| offload | #54 |
| s3 | >100 |
| uploads | >100 |
About DiluxOne Offload – Media Storage
From the official readme · v2.1.0Description
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_DEBUGoff and the Settings toggle off the plugin writes nothing to the PHP error log, at any level.WP_DEBUGturns 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:
- Service: Azure Blob Storage (https://azure.microsoft.com/services/storage/blobs/)
- Terms of Service: Microsoft Azure Legal Information (https://azure.microsoft.com/support/legal/), which links the Microsoft Products and Services Agreement and the Online Services Terms
- Privacy Policy: Microsoft Privacy Statement (https://www.microsoft.com/privacy/privacystatement)
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:
- Service: Amazon S3 (https://aws.amazon.com/s3/)
- Terms of Service: AWS Service Terms (https://aws.amazon.com/service-terms/)
- Privacy Policy: AWS Privacy Notice (https://aws.amazon.com/privacy/)
Cloudflare R2:
- Service: Cloudflare R2 (https://www.cloudflare.com/products/r2/)
- Terms of Service: Cloudflare Terms (https://www.cloudflare.com/terms/)
- Privacy Policy: Cloudflare Privacy Policy (https://www.cloudflare.com/privacypolicy/)
Backblaze B2:
- Service: Backblaze B2 (https://www.backblaze.com/cloud-storage)
- Terms of Service: Backblaze Terms of Service (https://www.backblaze.com/company/policy/terms-of-service)
- Privacy Policy: Backblaze Privacy Notice (https://www.backblaze.com/company/policy/privacy)
DigitalOcean Spaces:
- Service: DigitalOcean Spaces (https://www.digitalocean.com/products/spaces)
- Terms of Service: DigitalOcean Terms of Service (https://www.digitalocean.com/legal/terms-of-service-agreement)
- Privacy Policy: DigitalOcean Privacy Policy (https://www.digitalocean.com/legal/privacy-policy)
Wasabi:
- Service: Wasabi (https://wasabi.com/cloud-object-storage)
- Terms of Service: Wasabi Terms of Use (https://wasabi.com/legal/terms-of-use)
- Privacy Policy: Wasabi Privacy Policy (https://wasabi.com/legal/privacy-policy)
Google Cloud Storage:
- Service: Google Cloud Storage (https://cloud.google.com/storage)
- Terms of Service: Google Cloud Terms of Service (https://cloud.google.com/terms)
- Privacy Policy: Google Privacy Policy (https://policies.google.com/privacy)
Hetzner Object Storage:
- Service: Hetzner Object Storage (https://www.hetzner.com/storage/object-storage/)
- Terms of Service: Hetzner Terms and Conditions (https://www.hetzner.com/legal/terms-and-conditions/)
- Privacy Policy: Hetzner Privacy Policy (https://www.hetzner.com/legal/privacy-policy/)
Akamai (Linode) Object Storage:
- Service: Akamai Object Storage (https://www.linode.com/products/object-storage/)
- Terms of Service: Akamai Cloud Master Service Agreement (https://www.linode.com/legal/msa/)
- Privacy Policy: Akamai Privacy Statement (https://www.akamai.com/legal/privacy-statement)
Vultr Object Storage:
- Service: Vultr Object Storage (https://www.vultr.com/products/object-storage/)
- Terms of Service: Vultr Terms of Service (https://www.vultr.com/legal/tos/)
- Privacy Policy: Vultr Privacy Policy (https://www.vultr.com/legal/privacy/)
Scaleway Object Storage:
- Service: Scaleway Object Storage (https://www.scaleway.com/en/object-storage/)
- Terms of Service: Scaleway Contracts (https://www.scaleway.com/en/contracts/)
- Privacy Policy: Scaleway Privacy Policy (https://www.scaleway.com/en/privacy-policy/)
OVHcloud Object Storage:
- Service: OVHcloud Object Storage (https://www.ovhcloud.com/en/public-cloud/object-storage/)
- Terms of Service: OVHcloud Contracts (https://www.ovhcloud.com/en/terms-and-conditions/contracts/)
- Privacy Policy: OVHcloud Privacy Policy (https://www.ovhcloud.com/en/terms-and-conditions/privacy-policy/)
IDrive e2:
- Service: IDrive e2 (https://www.idrive.com/s3-storage-e2/)
- Terms of Service: IDrive e2 Terms (https://www.idrive.com/s3-storage-e2/terms)
- Privacy Policy: IDrive Privacy Policy (https://www.idrive.com/privacy)
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.
Installation
- Upload the
diluxone-offloadfolder to/wp-content/plugins/, or install via the WordPress Plugins screen. - Activate the plugin through the Plugins screen in WordPress.
- Open the new DiluxOne Offload menu in the admin sidebar.
- Go to Cloud Provider, select Microsoft Azure Blob Storage (enter the storage account, container and access key) or S3-compatible storage (pick the service, then enter the region, bucket, keys and, if it is not filled in, the public URL), and click Test Connection.
- Save the configuration.
- Go to Sync & Offloading, run the initial sync, and enable offloading when sync is complete.
Requirements
- WordPress 5.1 or higher.
- PHP 7.4 or higher.
ext-curlandext-opensslenabled.- A writable uploads directory only for Disconnect from Cloud, when your media is copied back. Transfers use the PHP temporary directory for their scratch files, never
uploads/. - An Azure Blob Storage account, a container whose public access level is Blob (anonymous read access for blobs, so browsers can load your media straight from it), and the account’s access key; or a bucket on an S3-compatible service that lets anyone read its objects, and an access key pair allowed to put, get, delete and list objects in it. Test Connection refuses a private container or bucket and says so.
Frequently asked questions
Does this plugin modify my existing media URLs in the database?
No. The stream wrapper intercepts filesystem calls transparently — your post content, the wp_posts table, and the wp_postmeta table are never rewritten.
What happens if the cloud is temporarily unreachable?
The plugin monitors connection health. While the cloud is unreachable, a new upload fails with WordPress’s own “could not be moved” error and nothing is saved anywhere, so you never end up with a file that looks uploaded but isn’t. A banner on the plugin’s admin pages explains the failure. Files already in the cloud keep being served from the storage account URL. The plugin re-checks the connection at most every five minutes and uploads resume on their own once it is back.
Does the plugin write any files to my server?
Not for itself: it has no cache, log or data files on disk; everything it needs lives in the WordPress options table and its own database table. Your media is written by WordPress core through the plugin’s stream wrapper to the cloud, passing through a temporary file in the PHP temp directory that is deleted right after the upload. The one operation that writes to the server is Sync & Offloading → Disconnect from Cloud. It copies your media back from the container to the exact uploads-directory paths WordPress has on record (resolved at runtime with wp_upload_dir()), so the Media Library…
What if the container or bucket already holds files?
Before the first sync, Sync & Offloading › Sync looks under this site’s folder in it (uploads/, or uploads/sites// for a site of a network). If something is there, from an earlier install or a staging copy, it says how many files and how much, and lets you continue with them, empty that folder (you type the container’s or bucket’s name to confirm) or connect another one. Emptying deletes only this site’s folder, never anything else in the container or bucket, and only before the first sync.
Can I move to another storage account or bucket later?
Yes, including from Azure to an S3-compatible service or back. Remove the current provider configuration from the admin, enter the new account, container or bucket, run a full resync, and the plugin starts serving from the new location. No URL rewriting required.
Will this work with WooCommerce / Elementor / image editors?
Yes. Because the stream wrapper operates at the filesystem layer, any plugin that reads or writes files under /uploads/ using standard PHP functions works unchanged.
Does the plugin delete my local files automatically?
Only if you explicitly opt in. After a successful sync you can click Delete Local Files in Sync & Offloading › Offloading. Until you do that, files are kept in both locations. A file that is empty (0 bytes) when the sync scans it is skipped: it is neither uploaded nor tracked, so Delete Local Files leaves it alone.
If I delete a file from the Media Library, is it deleted from the cloud too?
Yes, while offloading is active: the stream wrapper turns the deletion into a delete on your container, thumbnails included. If you have synced but not yet enabled offloading, WordPress deletes only the local copy; the copy already in your container is not removed automatically.
What happens when I uninstall the plugin?
Deleting the plugin from the Plugins screen removes everything it created in your database: its options (all prefixed diluxone_offload_), its transients and its file-tracking table (diluxone_offload_files, with your table prefix) — on every site of a network. Deactivating alone keeps all of that, so you can deactivate and reactivate without losing your configuration. Your media files are never touched by uninstalling: whatever is in /wp-content/uploads/ stays there, and whatever is in your container stays in your container. The only thing uninstalling cancels in the storage is an S3 multipart…
How do I enable verbose debug logging?
Go to DiluxOne Offload → Settings → Enable detailed debug logging. Logs are written to the standard PHP error_log destination. Disable it in production unless you are actively troubleshooting — it may impact performance. With that setting off and WP_DEBUG off, the plugin writes nothing to the PHP error log at all, at any level. With WP_DEBUG on it writes errors and warnings; the setting adds the rest.
Is the plugin multisite compatible?
Yes. It can be network-activated; each site then has its own Cloud Provider configuration and its own file-tracking table, so different sites can use different providers, containers or buckets — or share one: a site’s objects are stored under uploads/sites// (the main site under uploads/), and each site only ever lists, syncs and restores its own prefix.
How are my credentials stored?
The Azure access key and the S3 secret access key are encrypted with AES-256-GCM before they are written to the WordPress options table (the S3 access key ID, like a user name, is not a secret and is stored as it is). The encryption key is derived from your site’s WordPress salts (AUTH_KEY / SECURE_AUTH_KEY and the corresponding salts in wp-config.php), so as long as those salts are defined in wp-config.php (as WordPress recommends) a database dump on its own is not enough to recover the credentials — the attacker also needs filesystem access to wp-config.php. If you ever rotate the WordPress…
Changelog
First public release.
2.1.0
- Enable Offloading looks for files added since the last sync first: it says how many there are and uploads them before offloading is turned on. A file added between the end of the sync and enabling offloading used to stay off the cloud, a broken image once offloading was on. A synced library also offers Scan and Complete Sync on Sync & Offloading › Sync.
- Opening Sync & Offloading › Sync more than 90 seconds after a sync finished no longer resets the plugin to “configured”, which turned offloading off without a word.
- Complete Sync uploads the files added to uploads/ since the last sync; it used to report success and leave them out.
- Deleting an attachment while offloading is on removes its copies left on this server too, not only the objects in the cloud.
- Deactivating the plugin before the first sync keeps its state; it used to come back as “synced”.
- A site whose server path has a folder named cache, temp or tmp above
uploads/syncs its files; every file used to be skipped. Those folders insideuploads/are still left out. - Cloud Provider › Credentials shows the answer of Test Connection; it was written but stayed hidden.
- Clear List empties the failed files list on Sync & Offloading › Sync; it used to say so and leave the list as it was.
- A browser tab that lost the sync to another tab stops when the sync finishes, instead of asking the server again and again.
- The size of a file that is only in the cloud is its real size (the Media Library shows it for files without a stored size); it used to be 0.
- The DiluxOne Offload menu sits at the end of the admin menu, after Settings, where WordPress places a plugin’s menu by default.
- A sync or download request keeps to its time limit when the server’s clock is corrected while it runs. Before, a clock set back made the limit look untouched, and the request kept starting uploads past it.
- A delete or an upload the storage service asks to slow down (a 429; Google allows one change a second to the same file) is tried again after a second. Before, deleting an image right after editing it could leave its files stored, and billed, in the cloud.
- Uninstalling cancels the S3 multipart uploads a sync left unfinished, so the bucket stops billing parts nobody can complete any more.
- Before the first sync, Sync & Offloading › Sync checks this site’s folder in the container or bucket. If something is already there (an earlier install, a staging copy) it says how many files and how much, and lets you continue with them, empty that folder (typing the container’s or bucket’s name) or connect another one. Emptying never touches anything outside this site’s folder.
- A sync whose uploads go through ends a pause the connection health had recorded (a key that failed and was fixed since), instead of showing “Paused” for up to five more minutes.
- An upload, a delete or a check that meets a temporary error from the storage service (a 500 or 503, a dropped connection) is tried up to three times in all, instead of failing at once. Backblaze B2 answers that way to about one upload in a hundred, which could leave an image without one of its thumbnails.
- The initial sync uses every parallel upload from the start: a library that begins with large files used to send them one at a time, and now sends them alongside small ones, each upload starting as soon as another finishes.
- A large file’s parts (above 10 MB) now go up in parallel, like the other files, instead of one after another while the rest of the sync waited. A part that meets a temporary error from the storage service is sent again instead of failing the file. A very large file no longer has to go up within one request of the sync: the next one takes it up where it was left, sending only the parts the storage service does not have yet.
- The sync and Disconnect from Cloud reuse their connections to the storage service from one group of files to the next, instead of opening a new one, with its secure handshake, for every file.
- Status › Health names the storage service in use (Cloudflare R2, Amazon S3, …) and no longer shows a card that repeated the plugin’s state. Screens that speak of the storage say “container or bucket”, and a hostname too long for its card (Cloudflare R2’s public one) is shortened, with the whole name on hover.
- The Sync, Offloading and Disconnect screens and their windows are built on WordPress’ own buttons, notices and cards, and take the accent of your admin colour scheme. Offloading’s bar shows, in one full bar, the files only in the cloud and, striped, the ones that still have a copy on this server (the disk Delete Local Files can free). While a sync has files pending, the ones that already failed show as a red part of its bar. Messages these screens showed in English only are now translated.
- Six more services in the S3-compatible provider’s Service list: Hetzner Object Storage, Akamai (Linode) Object Storage, Vultr Object Storage, Scaleway Object Storage, OVHcloud Object Storage and IDrive e2. Each fills in the endpoint and, where the service has one, the public URL, and says where its keys come from and how to make the bucket readable.
- A file too large for the storage service’s limit on parts goes up in larger parts instead of failing: past about 5 GB on Scaleway (1,000 parts), past about 48 GB elsewhere.
- Settings › Serving › New uploads: browser caching, on by default, stores
Cache-Control: public, max-age=604800(one week, editable, or off) with every new upload, so browsers and CDNs keep your media instead of asking the storage again. And a storage class for new uploads: Standard, or the cheaper infrequent-access class (Azure’s Cool tier, STANDARD_IA on Amazon S3 and Cloudflare R2), which charges per read and bills a minimum of 30 days. Files already in the cloud keep what they were stored with. - The notices after saving settings, the provider or new credentials are translated.
- Settings › Transfers › Folders the initial sync leaves out: one folder per line under
wp-content/uploads/(backups, caches); the scan skips them and lists them on the Sync screen. Files uploaded through the site while offloading is on still go to the cloud. - An e-mail to the site’s administrator address when uploads pause (the storage failed three times in a row) and one more when they resume, never one per failure. On by default; Settings › Logging turns it off.
- Tools › Site Health has a test for the connection to your storage, critical with the reason when uploads are paused, and an Info section with the provider, the service, the state and the version (never a key).
2.0.0
- S3-compatible storage: besides Azure Blob Storage, the media can live on Amazon S3, Cloudflare R2, Backblaze B2, DigitalOcean Spaces, Wasabi, Google Cloud Storage (HMAC keys) or any server that speaks the S3 API, such as MinIO. Pick the service and the plugin fills in the endpoint and the public URL; the Public URL field is also where a CDN or a custom domain goes. Test Connection proves the keys can write to the bucket and that browsers can read what is stored, and refuses a private bucket. Large files go up in 5 MiB parts; the secret access key is encrypted like the Azure key. “Force HTTPS for cloud storage URLs” leaves alone a Public URL that is plain http on purpose, such as a server on a private network.
- Only a configuration that passed Test Connection can be saved, now checked on the server too: a key other than the tested one is refused.
- The admin is one menu with a screen per submenu (Overview, Cloud Provider, Sync & Offloading, Settings, Status) and tabs only where a screen needs a second level: Connection and Credentials; Sync, Offloading and Disconnect; Transfers, Serving and Logging; Health and System. Every screen is headed “DiluxOne Offload | Screen”, shows the site’s state at a glance in a column beside the content, and the open tab follows your admin colour scheme. Old links to the tabs keep working.
- Status › Health shows the connection health the plugin already recorded (status, last check, last success, consecutive failures) and how many files the tracking table knows, with a “Check now” button that asks the provider right away; Status › System shows the free disk.
- The screens say what is where: Sync shows how many files are synced, how many still have a local copy, how many live in the cloud only, the last upload made through the site and what the last scan left out (and why); Offloading shows where the media is served from, where the bytes are and since when; Disconnect shows what it would bring back and whether the disk has room; Cloud Provider shows since when it is connected.
- Files uploaded through the site while offloading is on are now counted like the ones the initial sync moved, and deleting the local copies no longer empties the plugin’s tracking table, so those figures stay right on the sites that use offloading. A very long list of failed files shows its first 50 rows and says how many there are.
- The Overview shows three state cards (the fourth repeated them); Cloud Provider › Connection offers “Rotate the key” and “Delete Cloud Provider” as buttons; every button with an icon has the icon and its label on one line, and the sync window’s buttons read at their size.
- The “Upload Timeout” setting is now “Transfer Timeout” and governs every upload request: the single upload, each block and its commit, and the sync’s parallel transfers. Before, block commits waited a fixed 300 seconds whatever the setting said. Downloads keep waiting at least the 300 seconds they always had; a higher setting raises that too.
- A transfer that runs past the timeout is reported as such: the connection-health banner says “Cloud Transfer Timed Out” and links to Settings, instead of showing a made-up error code.
- With debug logging on, every successful upload through the stream wrapper writes one line (path and size).
- The suites now prove what each setting does, not only that it is saved.
1.0.0
First public release.
- Azure Blob Storage provider with your own account and key; media served from
https://<account>.blob.core.windows.net. - Transparent PHP stream wrapper on
/wp-content/uploads/: no URL rewriting, no database migration. - Sync with cancel, resume and retry; optional deletion of the local copies once synced; Disconnect from Cloud brings everything back.
- Connection health: when the cloud is unreachable an upload fails with a clear error and nothing is written elsewhere.
- Streaming transfers: downloads go straight to disk and uploads go in 4 MiB blocks, so large files do not need large memory.
- “Force HTTPS for cloud storage URLs” option; multisite with per-site configuration; credentials encrypted at rest (AES-256-GCM, key derived from the site’s salts); quiet unless
WP_DEBUGor the debug toggle is on. - Uninstalling removes the plugin’s options, transients and table; media files are never touched.
Screenshots
For developers
Is this your plugin? Show off the numbers.
Add a live badge to your site, docs or GitHub README. It updates on its own — no account needed.
Best DiluxOne Offload alternatives
All Azure plugins →
FAQ
DiluxOne Offload – Media Storage: quick answers
Straight answers, pulled from live WordPress.org data.
Live data from WordPress.org · checked Oct 12, 2026
Is DiluxOne Offload – Media Storage free?
Yes. DiluxOne Offload – Media Storage is free to download and use from the official WordPress.org plugin directory.
Is DiluxOne Offload – Media Storage safe to use in 2026?
DiluxOne Offload – Media Storage is a solid plugin choice in 2026, with a few things worth checking first. Was last updated 4 days ago, and scores 64/100 on our health check.
How many websites use DiluxOne Offload – Media Storage?
DiluxOne Offload – Media Storage is active on <10 WordPress websites and has been downloaded 246 times since it launched in September 2026. It was downloaded 251 times in the last 30 days.
Does DiluxOne Offload – Media Storage work with WordPress 7.1?
Yes. The developer has tested DiluxOne Offload – Media Storage up to WordPress 7.1.3, the latest release. It requires WordPress 5.1 or newer.
What PHP version does DiluxOne Offload – Media Storage need?
DiluxOne Offload – Media Storage requires PHP 7.4 or higher. Most hosts run PHP 8.x today, so it works on any modern WordPress hosting.
When was DiluxOne Offload – Media Storage last updated?
The latest version, 2.1.0, was released on October 8, 2026 (4 days ago).
Who makes DiluxOne Offload – Media Storage?
DiluxOne Offload – Media Storage is developed and maintained by Pablo Di Loreto.
What are the best alternatives to DiluxOne Offload – Media Storage?
The most popular alternatives to DiluxOne Offload – Media Storage are miniOrange Embed Outlook Te… (300+ installs), Login with Microsoft Entra… (40+ installs) and Rafa Azure Simple Upload (20+ installs).
Powered by PageForge
Want thousands of pages that rank like these? Build them in an afternoon.
This directory runs on the same engine as PageForge. Turn any spreadsheet, CSV or API into thousands of fast, SEO-ready WordPress pages — with schema, internal links and AI-written copy baked in.
- CSV, Google Sheets & API data sources
- AI content, schema & internal links per page
- Works with Elementor, Gutenberg, Yoast & Rank Math
- Free on WordPress.org — no credit card
