Safe to expose Museum and S3 URLs?

[teal comet]

Hi everyone, I'm trying to self-host ente and I was wondering if it was safe to publicly expose the musuem and s3 endpoints. I'm using cloudflare tunnels to forward all three main urls (the web app, museum and s3). If it is not safe to do so, how do you suggest I secure them?

[clever sage]

Analyzing your question, please wait...

[clear orchid]

What you are doing is a right way to do cloudfared tunnel will encrypt your traffic using https. But you need not to expose your s3 publicly s3 api keys are at server where you self hosted only the end points are only exposed, the web app at Port 3000 and the end points at Port 8080 are exposed publicly using cloudfared tunnel where you only can access with you account credentials.

[teal comet]

okay, so I can leave museum exposed with no risks and I can stop forwarding s3. Got it. Thank you so much!

[covert oak]

Interesting, I always exposed my Minio through path style urls (minio.domain.tld and the normal ente web on ente.domain.tld / api.domain.tld). If I change my museum endpoint back to endpoint: localhost:3200
The web interface tries to get the stuff from localhost:3200 and not ente api..

Can you share a snippet of your configuration? Also why wouldn't you expose minio? It's encrypted anyways and ente prod also does this (over aws tho)

[clear orchid]

Ultimately, it is a question of what you gain by exposing your MinIO instance to the internet for Ente Photos. Utilizing a public DNS forces your system through unnecessary DNS resolution and NAT Loopback, requiring your router to intercept and translate traffic that should never leave your machine. By switching to localhost, you bypass the external TCP/IP stack entirely, ensuring that data stays within the local loopback interface for maximum throughput. Regarding my own environment, I don't stick to a single configuration; I constantly rotate setups to test various tools, such as using rclone to emulate S3 or mounting Google Drive and OneDrive as S3-compatible backends. Your current architecture is a great setup and you should certainly continue with it, but my primary suggestion is to avoid public exposure of MinIO to maintain peak performance and security

[bronze kayak]

I don't understand the reason of the questioning, if you want to address Ente from outside your home you'd need an internet exposed S3 endpoint anyway, exposing only localhost is OK only if you only use Ente from localhost no ?

[teal comet]

I wasn't sure if exposing the api and minio publicly was secure, perhaps it was intended to only be accessible by the selfhosted server by means of tokens or similar auth

[clear orchid]

Ente server will use s3 from localhost and ente server will be exposed to public dns and server sends encrypted blobs from s3 to the authorized client.

[bronze kayak]

But client connects s3...

Directly

[clear orchid]

yes i mean to say you have both options the pre signed url way and the localhost method too so it is like what do you prefer. i prefer to use a vpn to pretend in local host instead of using s3 directly exposed to the public.

[waxen prism]

Would someone be kind enough to share a sanitized compose and museum that works publicly without exposing s3. I have tried changing my museum bucket endpoint from my https subdomain back to localhost:3200 and all public facing apps fail to reach s3 storage. I would like to remove public exposure of minio if possible but I have not been able to do it while maintaining complete functionality of apps accessing through public dns.

[bronze kayak]

But do you intend to share albums with your friends/family?

[waxen prism]

Yes, sharing with multiple people outside of the home where tailscale or vpn would not be optimal. In this scenario, would it be possible to have full use of the server through public DNS without exposing s3?

[pure inlet]

Picking up on this thought, binding web + api endpoints on localhost will work (for Hetzner S3 buckets, not local MinIO or alternative) for the native apps but using the web browser app, it wont upload photos, always timing out - Uploading notes and documents to the Locker app is working though..

I would appreciate some guidance on what needs to be exposed for the web app to work properly

[pure inlet]

I think Ducky already answered it #1472206530383188172 message - now same logic would apply for external S3 buckets, they need to be publicly accessible - if you could confirm.

[clever sage]

Ducky

Yes, you should reverse proxy MinIO. When you upload files to Ente, the web app receives credentials from the Museum server and then attempts to upload the file directly from your browser to the MinIO endpoint. If that endpoint is set to localhost:3200 in museum.yml, the browser will try to find MinIO on your local machine rather than the server, causing the upload to fail.

To fix this, you should expose MinIO via a domain (e.g., storage.mydomain.tld) through your NGINX reverse proxy.

1. Update museum.yml

Change the endpoint to your public storage domain:

s3:
  are_local_buckets: true
  b2-eu-cen:
    endpoint: https://storage.yourdomain.tld

2. Configure NGINX

Add a server block to proxy requests to the MinIO API port (usually 9000 in the default container setup, though your compose might map it to 3200):

server {
    server_name storage.yourdomain.tld;
    location / {
        proxy_pass http://localhost:3200;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

3. Configure CORS

Because the browser is making requests from your main domain to your storage domain, you must ensure MinIO CORS settings allow your Ente domain. If you do not configure this, the browser will block the upload. See the Ente Object Storage documentation for specific CORS configuration steps.

For more details on troubleshooting, you can refer to the Ente Upload Troubleshooting guide.
-# If your issue is resolved, use </solved:1410327008973557843> to mark this thread as solved. Use </docsearch:1378409618417647708> if you want to ask something else.

Feb 14, 2026, 12:23 PM

[pure inlet]

One way to to mitigate this would be a desktop Ente Photos app, then there would be no need to talk to S3 directly