Why I Test MinIO from the Application Container, Not Only the Browser

After starting MinIO, I could open its web console in the browser. At first this looked like enough proof: the container was running, the port responded, and MinIO was accessible.

But Laravel does not reach MinIO through the same network path as the browser.

The browser runs on the host machine while PHP executes inside a container.

As I covered separately, localhost inside a container means that container itself.

So when verifying storage, I want to test not merely whether MinIO exists, but whether the exact application path to it works.

Both routes end at MinIO, but they pass through different network boundaries.

In the first case Docker exposes a port to the host machine.

In the second case two containers communicate through the internal Docker network.

Success on the first path therefore does not verify the second.

If http://localhost:9001 opens in the browser, I have learned several useful things:

• the MinIO container is running;
• the web console is listening;
• its port is exposed to the host;
• the browser-to-host-port route works.

I still do not know whether the application container can resolve minio, reach port 9000, or access the S3-compatible API.

The important part is running this command from the same container environment that Laravel will use.

The minio:9000 address exercises the internal service name and the S3-compatible API port.

The /minio/health/live endpoint provides a simple check that the service is alive and reachable through that network path.

A successful response proves much more for the application than an accessible web console.

The application container resolved minio, connected to port 9000, and received a response from MinIO.

The basic network prerequisite for Laravel Filesystem is therefore satisfied.

This limitation matters.

A 200 OK from /minio/health/live does not mean Laravel has correct credentials or access to the expected bucket.

The health check answers the network question only: can the required environment reach MinIO?

I verify Laravel Storage separately as the next layer.

Once the network path is confirmed, I move to the next layer: connecting MinIO through the standard S3 disk.

This verifies credentials, bucket configuration, the S3 setup, and an actual object operation.

This order keeps a networking problem separate from a Laravel Filesystem problem.

I like this sequence because every failure narrows the search area.

If the minio name does not resolve, changing S3 credentials is unlikely to help.

If /minio/health/live responds but Storage::put() fails, networking is already a much less likely cause.

Debugging becomes a sequence of isolated checks instead of random configuration changes.

If this command cannot resolve minio, the problem occurs before HTTP is involved.

I check whether both containers share the expected Docker network and whether the service is actually named minio.

Only after that does it make sense to test the port itself.

Another situation is possible: minio resolves correctly, but port 9000 is not reachable.

Then I check whether the service is running, which port it listens on, and whether I am using the internal container port rather than a host-only port mapping.

Name resolution and port connectivity are separate checks too.

If Laravel runs in one container while I execute curl on the host, I am once again testing a different route.

The most useful diagnostic command therefore runs from the environment where PHP will actually run.

This rule is useful beyond MinIO as well. It applies to Redis, databases, mail services, and other Docker dependencies.

I do not stop using the web console.

It is useful for confirming that MinIO is running, opening buckets, inspecting objects, and reviewing local configuration.

I simply do not treat it as proof that Laravel already has a working path to the S3 API.

My short checklist:

• Is the MinIO container running?
• Does the web console open from the host?
• Can the application container resolve minio?
• Do both services share a Docker network?
• Am I using the internal port 9000?
• Does /minio/health/live respond from the application container?
• Is Laravel using the correct AWS_ENDPOINT?
• Are the credentials and bucket correct?
• Does an actual write through Storage::disk('s3') work?

Opening MinIO in the browser is useful, but it is not enough to verify Laravel connectivity.

The browser and the application container reach MinIO through different network paths.

I therefore run http://minio:9000/minio/health/live from the application environment itself.

If it succeeds, I know service-name resolution, the Docker network, and the port are working.

I can then move to the next layer and test credentials, the bucket, and Laravel Filesystem.

A useful connectivity check follows the path the real code will use rather than merely proving that a service is reachable from somewhere.