Private S3 Storage from the Start: Do Not Make Files Public Just for Convenience

When I kept the same S3 configuration model across local and production, I wanted to preserve not only the technical contract but also the meaning of file access.

If a file must be private in production, it should not become public locally merely because that makes browser testing easier.

Otherwise the local environment stops exercising the flow that will actually exist after deployment.

During local development it is tempting to make the bucket public.

Testing becomes easy: copy the object URL and open it in the browser.

But if production access requires user authorization, this local flow bypasses the most important part of the behavior.

For a private file, knowing the object path should not be enough to gain access.

A user may know the filename or even the full object key, but that should not make anonymous access possible.

This is the behavior I want to exercise locally as well.

I still store the object through Laravel's standard S3 disk.

Privacy does not mean the application needs another driver or a separate PrivateMinioService.

It means the storage service should not expose permanent anonymous access to that object.

If the system says a file is private, I do not pass public merely because I want to open it quickly through a direct URL.

Otherwise the test succeeds precisely because I removed the restriction I was supposed to verify.

An especially risky shortcut is making the whole local bucket public just to avoid thinking about access to individual files.

The local system can then no longer reveal that some screen accidentally depends on a permanent public URL.

I prefer keeping the bucket private and making the application use the intended access mechanism from the beginning.

These two layers should remain separate.

A private bucket protects the object from permanent anonymous access.

The application decides whether a particular user is allowed to receive that file at all.

Private storage therefore does not replace authorization.

When a file is always available through a permanent URL locally, that assumption easily spreads through the system.

The URL gets stored in the database, returned from APIs, or inserted directly into the interface.

Once production storage becomes private, it becomes clear that the code depended on a property that should never have been part of the contract.

For private storage, it is enough to know where the object lives.

The access mechanism can be determined when access is actually requested.

This avoids coupling database state to a permanently accessible public URL.

One possible mechanism is a temporary signed URL.

Its important property is that access does not become permanent.

The application can authorize the user first and then issue short-lived access to one object.

I cover that mechanism separately later in this series.

A useful local environment does not test only successful paths.

For a private file, I also want the correct failure: an anonymous direct request should not return the object.

That failed access attempt is often evidence that the privacy model is actually working.

A local environment does not need to copy every production setting literally.

But I try to preserve rules that materially affect application behavior.

File privacy is one of those rules.

If it is disabled locally, we are no longer testing simpler infrastructure. We are testing a different access flow.

My short checklist:

• Is this file genuinely public by product rules?
• Am I exposing it only to simplify local testing?
• Will the production file be private?
• Has a direct URL accidentally become part of the API contract?
• Do I store the object key rather than assume a permanent public URL?
• Does the application authorize the user before granting access?
• Does direct anonymous access fail correctly?
• Does the local access model match the production model?

Making a local bucket public is easy.

But if production storage is private, that convenience can hide incorrect assumptions in application code.

The interface starts depending on direct URLs, APIs return permanent object addresses, and authorization is effectively bypassed.

I would rather discover those problems locally.

Private files therefore remain private during development, and access follows the same controlled model required after deployment.

A local environment may be simpler than production, but it should not change the security semantics of the file.