Object storage / storage bucket
A giant flat drive in the cloud: you save a file under a key and fetch it back by URL. No folders, no filesystem, no server to run.
See it
What it is
A bucket is a flat store you write files into under a key and read back by key or URL. There are no real folders: a key like 'media/2026/hero.jpg' only looks like a path because slashes are legal characters. Amazon S3 set the shape and Cloudflare R2, Backblaze B2, and MinIO speak an S3-compatible API, so the same SDK usually works with a different endpoint; Google Cloud Storage and Azure Blob Storage are the same idea with their own APIs.
In hosting terms the bucket is your origin for anything big and static: user uploads, video, images, PDFs, build artifacts, backups. There is no server for you to manage, which is the honest version of 'no server': it is a managed service with plenty of machines behind it. The standard rig is browser uploads straight to the bucket via a presigned URL, keys plus metadata in your database, and a CDN in front of reads so the bucket gets hit once per file per region instead of once per visitor. That CDN layer is the usual default rather than a law: whether you need it depends on how often the same objects get read, what your provider charges for requests and egress, and how far your readers sit from the bucket. When reads repeat, it is what stops request charges and egress tracking your traffic one for one.
Gotchas: buckets get left public by accident, which is how private customer files end up in Google. Egress can cost more than storage, which is most of why teams move media to R2. Requests are billed too, so a hot asset served uncached is death by a million GETs. And renaming is really copy plus delete, so reorganizing a million keys is a migration, not a quick tidy-up.
Ask AI for it
Set up object storage as the origin for this app's media. Create a private S3-compatible bucket and do direct browser uploads with a presigned POST policy that pins the content type and sets a 'content-length-range' condition (or my provider's equivalent), because a plain presigned PUT lets the client send whatever size and content it likes and the backend cannot validate bytes it never sees. Upload into a 'pending/' prefix, then have the backend verify the stored object with a HEAD request plus content-type and malware checks before it publishes the object by moving it or flipping its status. Store only key, mime type, size, and owner in the database, with the key pattern 'uploads/{userId}/{uuid}.{ext}'. Block all public bucket access and make a CDN with signed access the only reader, sending 'public, max-age=31536000, immutable' on content-hashed assets and a short TTL on everything else. Add a lifecycle rule deleting anything left under 'pending/' or 'tmp/' after 24 hours.