Amazon S3 is the default place to store files, but its pricing, with separate charges for storage, requests, and bandwidth, surprises small projects as they grow. Several alternatives offer simpler pricing, generous free tiers, or self-hosted control. Choosing well depends on what your project actually stores and how often it serves those files to the public.

Cloudflare R2 is the most popular alternative for small projects because it charges for storage without the usual egress fees, which matters enormously if your files are downloaded often. Its free tier covers a useful amount of storage and requests, making it a strong default for public assets. Backblaze B2 offers very low storage prices with a free daily download allowance, and it suits backups and archives well. Supabase Storage and similar platform storage options bundle file hosting with the rest of a backend, which is convenient when you already use that platform. For pure experimentation, several providers offer small free buckets with no card required.

Self-hosting is the other path. MinIO is an open-source, S3-compatible server that runs in a single container and speaks the same API as S3, so existing tools and libraries work unchanged. It suits teams that already run a server and want full control over their data and costs. The trade-off is responsibility: you handle backups, availability, and scaling yourself. For a project with modest traffic and a reliable server, that trade is often worth it, and the monthly cost is just the disk space you already pay for.

Compare four things before committing. First, egress pricing, because serving popular files can cost more than storing them. Second, the free tier's real limits, including request counts and daily bandwidth caps that only appear in the fine print. Third, API compatibility, since S3-compatible storage lets you switch providers later without rewriting code. Fourth, durability and backup behaviour, because a cheap bucket that loses files is not cheap at all.

Migration is easier than it looks if you plan it. Upload files to the new bucket, verify a sample, then switch your application's storage configuration and keep the old bucket readable for a transition period. Update any hard-coded URLs, and set up lifecycle rules to clean up old versions. Because most alternatives speak the S3 API, the code change is often a few lines of configuration rather than a rewrite.

Start by measuring your real usage: how much you store, how often files are downloaded, and how much you currently pay. Then pick the option whose pricing matches that pattern, not the one with the biggest headline discount. For most small projects, a free tier with no egress fees or a self-hosted MinIO instance beats S3 on cost, and either one leaves you free to move again when the project grows.

Storage bills grow from files nobody looks at anymore. Old versions, abandoned uploads, and logs accumulate silently, and on a pay-per-gigabyte plan they add up month after month. Lifecycle rules fix this automatically: move older files to cheaper storage classes, delete incomplete uploads after a few days, and expire old versions after a set period. Most providers support these rules in a few clicks, and they are the difference between a storage bill that stays flat and one that creeps upward forever.

Also separate your buckets by purpose. One bucket for public assets, one for user uploads, and one for backups keeps permissions simple and makes cost analysis possible: you can see exactly which kind of data costs what. Mixing everything into one bucket saves five minutes at setup and costs hours later, when you cannot tell which files are safe to delete. Good bucket hygiene is boring work, but it is the work that keeps a cheap storage choice cheap.