MinIO in Laradock: Local S3-Compatible Storage for Laravel

When a Laravel project uses only a local disk, file storage looks simple: files are written into storage and read from the same filesystem.

Production storage often behaves differently. Files may live in S3 or another S3-compatible object store, remain private, upload directly from the browser, and be accessed through temporary URLs.

If local development uses only the local disk, some important production behavior is never exercised.

This is where MinIO became useful for me.

My goal is not to reproduce all of AWS on a laptop.

I need an environment where Laravel talks to object storage through an S3-compatible API instead of a local directory.

This allows me to exercise behavior that differs from a normal local disk:

• private files;
• buckets instead of local directories;
• temporary URLs;
• direct uploads;
• S3 endpoints;
• Laravel Filesystem using the s3 driver.

Technically, a local project could connect directly to AWS.

I do not want that for everyday development.

Local tests should not create accidental files in a real bucket, depend on internet access, or require production-like credentials just to verify an ordinary upload flow.

MinIO keeps that entire cycle inside the Docker environment.

My first step was not to write a new Dockerfile or another Compose service.

I inspected Laradock first.

It already contained a minio service with its own compose.yml and defaults.env.

This is a useful practical rule: before adding another container, check whether the environment already provides the integration.

In our Laradock setup, the MinIO API runs on port 9000 and the web console on 9001.

The ports have different purposes.

Laravel talks to the S3-compatible API on 9000.

Port 9001 is useful for development: opening the console, inspecting buckets, checking objects, and reviewing configuration.

This is an easy detail to miss.

In a browser on my host machine, localhost:9001 refers to the exposed MinIO port.

Inside the PHP container, however, localhost means the PHP container itself.

The application therefore reaches MinIO through the Docker service name:

http://minio:9000

Because the service already exists in Laradock, I do not need a separate stack just for MinIO.

It runs alongside the other local services and uses the same Docker network.

An accessible web console does not prove that the Laravel container can reach MinIO.

I therefore also checked http://minio:9000/minio/health/live from the PHP environment.

A 200 OK response confirms the same network path the application will later use.

One reason I like this approach is that I do not create a separate MinIO filesystem implementation.

Laravel already works with S3 through Filesystem. For the local environment, credentials, bucket, and endpoint change.

Application code can keep using Storage without knowing whether MinIO or an external S3-compatible service is behind it.

For local MinIO I use AWS_USE_PATH_STYLE_ENDPOINT=true.

The bucket then appears in the request path, which works well with a local endpoint based on the Docker service name.

This avoids requiring separate local DNS names for every bucket.

If files are not meant to be public, I do not make the bucket public merely to simplify local development.

Doing so would hide an important part of production behavior.

A private bucket forces the application to model file access correctly from the beginning.

For a simple Storage::put(), both options may look almost identical.

Behavior diverges as soon as storage requirements become more advanced.

Object storage introduces endpoints, buckets, HTTP access, visibility rules, and signed URL mechanisms.

That is why I want this model present during local development.

The MinIO container alone does not solve application file handling.

But it gives me a local foundation for testing Laravel Filesystem, private access, temporaryUrl(), direct uploads, and other S3 workflows separately.

Those next steps are what I want to cover in the rest of the series.

My basic checklist:

• Does Laradock already contain a MinIO service?
• Is the container running?
• Is the web console available on port 9001?
• Can the PHP container reach http://minio:9000?
• Does the health check pass?
• Does the required bucket exist?
• Does Laravel use the S3 driver rather than a separate MinIO implementation?
• Does the Docker-side endpoint use the service name instead of localhost?
• Do private files remain private?

MinIO itself is not the goal.

Its value is that a local Laravel project can work with the same storage model required by S3-compatible production storage.

I can develop without depending on real AWS while still avoiding the oversimplification of a plain local directory.

Laradock makes the first step especially convenient because MinIO is already available as one of its services.

For me, local MinIO is not a replacement for AWS. It is a way to exercise S3 behavior before the code reaches production.