Why is the temporaryUrl() method not supported using MinIO (it works flawlessly for me)

[nicolus]

The docs about file storage say

Generating temporary storage URLs via the temporaryUrl method is not supported when using MinIO.

I decided to try it anyway to see what would happen, and it seems to work flawlessly on my MinIO cluster, it generates a URL that does work and does expire after the specified time.

So I'm wondering if it's just "not supported" because it has not been thoroughly tested by the Laravel team but actually works fine, or if there's a specific issue, limitation or bug with it that I'm not aware of.

The documentation also says

In order for Laravel's Flysystem integration to generate proper URLs when using MinIO, you should define the AWS_URL environment variable so that it matches your application's local URL and includes the bucket name in the URL path

but I didn't need to : All I had to do was to specify the endpoint (eg: https://minio.mydomain.com), and the whenever I use the url method the bucket name is automatically appended : Storage::disk('mybucket')->file('myfile.jpg') will return https://minio.mydomain.com/mybucket/myfile.jpg

So I wonder if maybe the documentation is outdated and newer releases of Laravel/Minio actually work better than expected.

[vorban]

I'm interested in getting Minio temporary urls to work locally in a dev environment.
My understanding is that the notice you mentioned is actually located at laravel.com/docs/11.x/sail, and is useful in the context of using laravel/sail for local development:

Generating temporary storage URLs via the temporaryUrl method is not supported when using MinIO.

The Storage::temporaryUrl() function uses the .env AWS_ENDPOINT, which supposedly needs to be the minio address inside the docker network (most likely http://minio:9000). This means that the generated URL will be something like http://minio:9000/{path}/{signature}. Of course, your web browser cannot access a container by name so this won't be found. If you manually change minio to localhost in the output url, the signature won't match.

You'd think changing the .env to specify AWS_ENDPOINT=http://localhost:9000 would work, but actually localhost has no meaning inside docker so this doesn't work for uploading files.

I'm using the laravel/vapor npm package to handle clientside upload, so the upload itself (through the browser) works because the localhost url is resolved. However, Storage::move() returns false indicating it could not run successfully (because it cannot access localhost).

The Docker docs mention using host.docker.internal as a domain name that will resolve to the host machine. My intent was to use this as the AWS_ENDPOINT, and alias this domain name in my /etc/hosts. However, this does not seem to work (Storage::move() still fails) on MacOS with Docker Desktop 4.26.1.

All in all, MinIO temporary urls don't seem to be supported in sail so this part of the docs looks pretty accurate to me.

That being said, I agree that the AWS_URL doesn't need to have the bucket name appended, it works fine as-is.

I'm working on something that requires temporary urls, so my workaround is to use an actual S3 bucket and try to stick to the free-tier plan.

[nicolus]

@vorban :

My understanding is that the notice you mentioned is actually located at laravel.com/docs/11.x/sail, and is useful in the context of using laravel/sail for local development:

Yeah that makes sense, what confuses me is that the exact same warning is also in the main "file storage" section (https://laravel.com/docs/11.x/filesystem#minio), and as you said is sounds like it's specifically a Sail issue, and not a Laravel or MinIO issue.

Also when I posted this message I was using MinIO in production and on my WSL2 based dev environment. I've been moving to Docker and it does make things a bit more complicated, but I got everything working (including https everywhere) with Docker. I just pushed it to github in case you're interested : https://github.com/nicolus/laravel-minio-example

[vorban]

I checked it out, I think it's the use of a reverse proxy as a gateway to both the app and minio that makes it work.

I'm unsure why there isn't a reverse proxy in the default sail stack, my guess is that is was deemed both unnecessary and over-engineered at the time. I don't know how early they added minio as a sail service.

[NWBY]

This is possible if you're using Orbstack as an alternative to Docker Desktop for Mac by using Orbstack's container domain names.

By specifying your container domain name as the value for AWS_ENDPOINT you can use Minio in a Sail project to store objects and generate presigned URLs for the browser to use. The format follows: http://<service>.<project>.orb.local, <project> is usually just the name of the directory where your compose file is located. So for me this worked out as: AWS_ENDPOINT=http://minio.viz.orb.local:9000,