What object storage (S3) is, and when your app actually needs it

User uploads stored on the server disk disappear on the first redeploy — or on the second replica. Object storage solves exactly that, and buying it without understanding the problem is pointless.

One of the first architectural decisions a growing application runs into is this: where do user-uploaded files live? The obvious answer is the server disk. That answer breaks silently in two situations.

First break: the redeploy

Your application is rebuilt on every release. Code comes from the repository, dependencies are installed, a new box is produced. Anything you wrote into the code directory is gone at that moment, because that directory is generated from code and is temporary by design.

That is why the upload folder belongs on a persistent disk. Persistent disks survive redeploys, and for many applications this is the correct answer.

Second break: the second replica

When you run two or three replicas, each one has its own disk. A user uploads a file, the request lands on replica one, the file is written there. When the same user asks for the file and the request lands on replica two, the file is not there.

The result is a system that never throws an error but is wrong: the file is sometimes visible and sometimes not. A persistent disk does not fix this, because the problem is not persistence — it is that the disk is not shared.

What object storage does

Object storage separates files from the server entirely. Files live in a shared area reached through an endpoint and a key pair. Whichever replica asks, it sees the same file; the application can be redeployed and the files stay where they are.

Access uses the S3 protocol. That is a standard: Laravel, Django, Next.js, WordPress and almost every tool you can think of already speak it. In most cases all you add is a few configuration lines.

AWS_ENDPOINT=...
AWS_DEFAULT_REGION=...
AWS_BUCKET=...
AWS_ACCESS_KEY_ID=...
AWS_SECRET_ACCESS_KEY=...
AWS_USE_PATH_STYLE_ENDPOINT=true

When you do not need it

Not every application needs this. For a single-replica site with no user uploads, or one whose files already live in the repository, a persistent disk is more than enough. Adding an unnecessary component creates more problems than it solves.

The need starts in three situations: you run more than one replica, your user uploads keep growing, or you want your files to outlive the application itself.

Limits are stated openly

Storage plans carry two numbers: stored space and monthly download allowance. The second one is usually buried in fine print; we write it on the plan page, because in a storage service the download side is what actually drives cost.

Other posts