Offload Media hosting when the uploads folder is not yours.
Moving the media library to object storage solves disk and solves delivery. It also means every image on the site now depends on a rewrite rule being right.
Two places, one library.
Once uploads live off the server, most media problems become questions about which copy a URL points to.
Rewrites that hold through a migration
Media URLs are rewritten to the bucket at render time, and those rules are the first thing a site move breaks. Migration handles them deliberately rather than as a database search and replace.
Private files that stay private
Object storage is public by default and that default has leaked more customer documents than any exploit. Restricted media is delivered with signed, expiring URLs rather than obscure ones.
The first offload run finishes
Moving an existing library of a hundred thousand files is a long job. It runs as a resumable batch, so the initial migration completes rather than stalling half way through the media table.
A local copy worth keeping
Deleting local files reclaims disk and removes your fallback. The trade-off is set deliberately per site, and backups cover the library either way.
Uploads processed before they leave
Derivative sizes are generated on the server and offloaded together, so a page never asks the bucket for a size that was never created.
The rewrite is the whole feature.
Nothing about object storage is fragile. What breaks is the layer that decides whether an image URL points at the server or at the bucket, and it breaks quietly.
- Rewrite rules preserved through migration
- Private media delivered with expiring URLs
- Initial offload runs as a resumable batch
- Derivatives generated before offloading
Images that never touch the server.
The reason to offload is that media stops competing with the application for disk and bandwidth. That only holds if every URL actually points away.
What we change for offloaded media
Every row is about the seam between the site and the bucket, because that seam is where offloading fails.
| Setting | What we do | Why |
|---|---|---|
| URL rewriting | Preserved explicitly through any migration | Media URLs are rewritten at render time, and a blunt database replace during a site move points every image at a bucket path that no longer applies. |
| Private media | Delivered with signed, expiring URLs | Object storage is public unless told otherwise, and an unguessable filename has never been an access control. |
| Initial offload | Resumable batches with progress kept | Moving an existing library of a hundred thousand files takes far longer than any request allows, and a stalled run leaves the library split between two places. |
| Local copies | Retention decided per site rather than defaulted | Removing local files reclaims disk and removes the fallback at the same time, which is a trade worth making on purpose. |
| Derivative generation | Completed on the server before offloading | A page requesting a size that was never generated gets a missing image from the bucket rather than a resize, because nothing there can create one. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
What breaks when I migrate a site with offloaded media?
Can I keep private files private in a bucket?
Why did my first offload never finish?
Should I delete local copies after offloading?
Point every URL at the right place.
Move the site across. Migration is free, media rewrites checked.