Direct S3 Uploads: Why Large Files Do Not Need to Pass Through PHP

In the previous article I covered temporary URLs for private files for reading a private object.

An upload can follow a very similar model, only the data travels in the opposite direction.

Laravel authorizes the operation, chooses the future object path, and generates short-lived upload permission.

The browser then sends the large file directly to S3-compatible storage.

For a small file this can be perfectly reasonable.

With a large video, however, PHP becomes a proxy for a large data stream even though application code usually does not need to inspect every byte.

The request occupies a worker longer and passes through HTTP body limits, execution-time limits, and temporary server-side upload handling.

temporaryUploadUrl() returns the upload URL and headers the client should include with the request.

This is not permanent write access to the bucket.

The URL targets a specific object path and has a limited lifetime.

I do not let the client arbitrarily choose any S3 object key.

The application decides which storage area may be written to and generates a safe object name.

This prevents the client from overwriting another object or choosing a path outside the intended area.

Being authenticated does not mean a user may upload a file in every context.

The application authorizes the specific operation before creating signed upload permission.

Once the URL is issued, storage does not ask Laravel about the user role. It validates the signature.

The server does not have the actual file yet, but the client can send its name, declared size, and content type.

Those values help reject clearly invalid upload attempts before issuing a signed URL.

Browser-supplied metadata is not final proof, however. The stored object should be verified after upload.

In this request the large video body travels directly from the browser to S3-compatible storage.

A PHP worker no longer waits while hundreds of megabytes pass through the application.

Laravel was needed to decide whether the upload was allowed and where it should go, not to relay the bytes themselves.

I keep the private S3 storage model.

Temporary permission to write one object does not mean that object should receive a permanent public URL afterward.

The uploaded object can remain private, with separate short-lived access generated when it needs to be read.

With direct upload, the browser calls the storage HTTP endpoint directly, so CORS becomes part of the working flow.

I allow only the required origins, methods, and headers.

I also verify the generated host: Laravel inside Docker may reach minio:9000, while the user browser does not live inside that Docker network.

Storage may accept the file successfully, but the application still needs to learn that the operation completed.

I do not persist a final ready-file state merely when the URL is issued because the user may never perform the upload.

After a successful PUT, the client notifies the application and the server verifies the object.

Before issuing the URL, I only had metadata declared by the client.

After upload I can verify that the object exists, inspect its actual size, and read the stored MIME type.

Only after that verification do I move the application record into a ready-file state.

A user may receive permission, close the tab, lose the network, or abort the upload.

The intermediate application record should not remain indefinitely as though a ready file exists.

These states need an expiration or cleanup strategy.

If storage contains objects that were never finalized by the application, there should also be a safe way to remove them.

If an existing file is being replaced, I do not delete the old object when the new upload URL is issued.

The new upload may never complete.

I verify the replacement first, update application state successfully, and only then clean up the previous object.

I do not use direct upload merely because it is technically possible.

For small avatars or simple attachments, a normal PHP upload may remain much simpler.

The direct flow becomes especially useful for large files, long uploads, or situations where PHP should not remain between the browser and storage throughout the data transfer.

My short checklist:

• Is this upload operation authorized for the user?
• Does the server generate the object path?
• Are declared size and type checked before permission is issued?
• Does temporaryUploadUrl() have a short lifetime?
• Does the browser send all required signed headers?
• Does CORS allow only the required flow?
• Is the storage URL reachable by the browser, not only the Docker container?
• Does the file remain private after upload?
• Does the application verify the real stored object afterward?
• Can abandoned uploads be cleaned up?
• Is the old file kept until replacement succeeds?

For large files I like separating control from data transfer.

Laravel authenticates the user, authorizes the operation, chooses the object path, validates declared metadata, and issues short-lived permission.

The browser then transfers the large file directly to S3-compatible storage.

After the upload completes, Laravel becomes involved again to verify the real object and persist the final state.

PHP remains the owner of application rules without becoming the transport for hundreds of megabytes of data.

Direct upload does not bypass the application. It only removes the application from the part of the path where it does not need to sit between the browser and storage.