A billing SaaS stores client PDFs in /var/www/uploads. At 200 GB, nightly backups exceed the allowed window, the VPS is saturated, and moving to a new instance means hours of file copying. Nobody planned for media to grow ten times faster than code.
Object storage (S3 and compatible APIs) exists for this decoupling: durable files, ephemeral web server. It is not a cloud fad—it answers a volume that no longer fits cleanly on local disk.
Why local disk eventually lies
On a VPS or shared host, uploads and code share one filesystem. Predictable problems:
- Backups — snapshotting 500 GB of PDFs with the database doubles time and cost.
- Horizontal scaling — two web servers do not share
/uploadswithout NFS or object storage. - Restore — rebuilding a server is not enough if files lived on the dead disk.
Object storage externalizes blobs with redundancy, versioning, and native retention policies.
| Criterion | Local disk | Object storage |
|---|---|---|
| Growth | VPS limit | Near unlimited (metered) |
| Multi-server | Complex | Uniform URL or SDK |
| Egress cost | Often included in VPS | Separate line—watch it |
| Permissions | Unix chmod | IAM / bucket policies |
Local disk wins on simplicity early. Object storage wins once media becomes its own asset.
Typical architecture for a web project
Private bucket + CDN or signed URLs. Objects stay private; CDN caches public media. Sensitive files use time-limited signed URLs.
Prefix per environment. prod/media/, staging/media/—never the same bucket without guardrails.
Lifecycle. Archive to cold tier after 90 days, delete temp files after 7 days. Automated at bucket level, not homemade cron.
Metadata in DB, blobs in object. The database keeps key, mime, size; the file lives in the bucket. Essential for search and permissions.
Hidden costs: egress and requests
The bill is not storage alone:
- Egress — outbound to Internet or another cloud region.
- GET/PUT requests — millions of tiny files = API cost.
- CDN in front of bucket — cuts origin egress, adds a CDN line.
Estimate with real traffic: a heavy media site may pay more for bandwidth than storage. Compare European offers in our directory.
Common integration mistakes
Public bucket by default. Bot scans + surprise bill. Private by default, public only if needed.
Hardcoded AWS region URLs. Changing provider = rewriting the whole database.
No versioning. Accidental delete becomes permanent.
Manual two-way sync. Prefer a single source of truth (object) and idempotent jobs.
The climax: object storage does not backup your database
This is the post-migration trap: "everything is on S3, we're safe." Pair with backup strategy and restore testing.
Decide and move forward without blind spots
- Threshold — define when you switch (e.g. 50 GB or +10 GB/month).
- Choose an EU provider with DPA if files contain personal data.
- Integrate SDK or plugin with private bucket + CDN.
- Enable versioning and lifecycle rules.
- Test object restore + database consistency.
Use the comparator to filter hosts with integrated object storage.
Frequently asked questions
Object storage or VPS disk — where to draw the line?
Once media exceeds a few tens of GB, grows fast, or must survive a server change. Under ~5 GB of uploads, local disk remains simpler.
Are object files public by default?
No. Configure private buckets and serve via signed URLs or CDN in front of the bucket.
Does S3-compatible mean identical to AWS?
The API is largely compatible, but egress, regions, SLA, and lifecycle vary by provider.
How do I migrate existing WordPress media?
Dedicated plugins or rsync to bucket + URL rewrite in the database. Test on staging; plan dual-write during cutover.
When uploads become heavier than deployment, object storage is no longer a "cloud option"—it is what keeps your server a server.