Reading · Recent Questions - Software Engineering Stack Exchange

This page did not load. You can still read it on the original site — the toolbar below keeps your place in the directory.

We have a NestJS backend generating presigned GET/POST URLs for a private bucket on MinIO (S3-compatible). The S3 client is configured with the internal Docker service name as endpoint (e.g., http://minio:9000 ), so presigned URLs contain that internal hostname, the browser can't resolve it. Currently we work around this with a server-side proxy: the frontend (Nuxt) fetches presigned URLs from the…

We have a NestJS backend generating presigned GET/POST URLs for a private bucket on MinIO (S3-compatible). The S3 client is configured with the internal Docker service name as endpoint (e.g., http://minio:9000), so presigned URLs contain that internal hostname, the browser can't resolve it.

Currently we work around this with a server-side proxy: the frontend (Nuxt) fetches presigned URLs from the backend, then proxies the actual file requests through a Nuxt server route (/api/private-file?url=<presigned_url>) which rewrites the host to a public address.

Is this proxy approach an anti-pattern? What's the standard way to handle this? Options I'm considering:

Configure the backend with a separate STORAGE_PUBLIC_ENDPOINT so presigned URLs are generated with a browser-reachable hostname (while the S3 client still connects via internal endpoint)
Put a reverse proxy (Nginx) in front of MinIO with a consistent hostname resolvable both internally and externally
Accept the server-side proxy as-is

What do most production setups do?

Best practice for serving private S3-compatible bucket files to browsers when presigned URLs contain internal Docker hostnames?

Comments