Why would you think you can't share albums? You definitely can.
this post was submitted on 28 Jun 2026
26 points (96.4% liked)
Selfhosted
60210 readers
947 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil.
-
No spam.
-
Posts are to be related to self-hosting.
-
Don't duplicate the full text of your blog or readme if you're providing a link.
-
Submission headline should match the article title.
-
No trolling.
-
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 3 years ago
MODERATORS
only if immich is publicly accessible (reverse proxy to domain, etc.). If it's on a closed network like tailscale, albums aren't accessible from outside the network afaik
You can share Immich albums.
There is also this: https://github.com/alangrainger/immich-public-proxy
I think your immich gallery can even be private ( though the public proxy would need to be able access it ).
I have no experience with it though.
You definitely can if you put Immich behind a reverse proxy like Caddy and open it up to the rest of the world. I also protect my instance against bots with Crowdsec. That's how share albums with family and friends.
Isn't this 'sharing an album'?
It is but it requires public internet access to the Immich instance, or everyone involved being on our VPN. Reusing someone else's publicly facing service to share photos from a private Immich instance is a clever workaround.
Using a reverse proxy / ingress, you can configure only share links to be publicly available, while keeping the rest of immich exclusive to your private-network. Optionally combine with something like Cloudflare Tunnel if you're worried about leaking your server's IP.
~~this right here. If you have immich setup behind a reverse proxy, just route any requests that use the /share/ and /s/ (the custom link version) on the proxy manager to route to the immich instance, and have it 403 on anything else when the request is not via the vpn~~
~~Just be aware that immich uses links like share-* as well so be sure to have that trailing / to make it so only shared links and albums can be.~~
~~edit: Actually looking into this route further, it looks like immich as a whole needs more than just the /share/ and the /s/ endpoints exposed to function correctly. I will update this in a little when i figured out more on what is actually needed~~
update: So it seems immich will not support this style setup without quite a bit of hands on. You need to give at minimum /share/, /s/, /_app/ and /api/ in order to actually go this route. and at that point since you've given /api/ you've essentially publicly opened the instance anyway. While you can go through and individually do each endpoint. It requires access to /api/albums /api/assets and a few other endpoints, these endpoints do seem to need auth or some form of verification tho
for anyone wanting to still go through with it. You can reverse proxy it by allowing the endpoints
- api/
- server/
- config: shows basic infomation about the server
- media-types: shows what media types the server supports
- features: discloses what features the server supports
- shared-links/me: 401, 403's or shows what links the user account can sign into
- albums/: 403's on any album endpoint that doesn't also include the album's public slug in the URL
- timeline/
- buckets: displays timeline buckets. 401 or 403's on no auth
- bucket/: displays timeline info on the requested resource. 401 or 403's on info unless info is provided about what its trying to access
- assets/: 401 or 403's on any request that doesn't contain a public slug in the url
- server/
The nginx location regex I used for my testing(although not very read friendly) was
location ~ /(api/(server/(config|media-types|features)|shared-links/me|albums/|timeline/(bucket|buckets)|assets/)|(share|s)|_app/){
proxy_pass *immich instance*;
}
note: this was found just by basic testing using NPM on my environment, I may have missed some more specific calls especially regarding videos as I don't really do any video photography to allow for testing.
Afaik immich is generally safe to publicly expose. Otherwise, I'd just use http basic auth. Supported by every server and client, should be secure enough to hold off attacks in case immich's login/auth mechanisms fail, and I don't see a usecase where this wouldn't work.
If you don't have a public IP or need IPv4, get a 4€/Month VPS (cheaper than even a Pi's energy usage I suppose) and put headscale on it.
If you plan to make a diy solution, you might've seen one or two CLIs for uploading to Google Photos. Just FYI, you can also leverage rclone to create Google Photos albums and uploads photos/videos there.
Coud probably be done. Find publicly shared Immich albums -> sync to Google Photos -> share publicly -> write the public Google Photos URL to the metadata of the Immich album.
Another could be an insulated public facing Immich instance that gets publicly shared albums pushed to it, the same way as with the other scheme. No reverse access to the private Immich instance. Then if that gets hacked, only those photos leak, attacker can't get their hands on other server data. Assuming it's really well isolated. A public VPS would probably be best for this.
IMHO you should look/ask for such a feature in a google group because big g may have a business case for such a feature: it would pull back in those users who try to escape.
and that should not be an immich feature but a google one.
as a self-hoster I prefer to have control on my data; a solution to feed my data to google through a third party (that may do whatever it wants while performing the transfer) is the exact opposite of what i'm trying to achieve and would have little to no value for me.