Immich is an amazing piece of software, but because it holds such personal data I have only ever felt comfortable accessing it via VPN or mTLS. This meant that I could never share any photos, which had been really bugging me.

So I built a self-hosted app, Immich Public Proxy, which allows you to share individual files or full galleries to the public without ever exposing your Immich instance. This uses Immich’s existing sharing functionality, so other than the initial configuration everything else is handled within Immich.

Why not just expose Immich publicly with Traefik / Caddy / etc?

To share from Immich, you need to allow public access to your /api/ path, which opens you up to potential vulnerabilities. It’s up to you whether you are comfortable with that in your threat model.

This proxy provides a barrier of security between the public and Immich. It doesn’t forward traffic to Immich, it validates incoming requests and responds only to valid requests without needing privileged access to Immich.

Demo

You can see a live demo here, which is serving a gallery straight out of my own Immich instance.

Features

  • Supports sharing photos and videos.
  • Supports password-protected shares.
  • Creating and managing shares happens through Immich as normal, so there’s no change to your workflow.

Install

Setup takes about 30 seconds:

  1. Take a copy of the docker-compose.yml file and change the address for your Immich instance.

  2. Start the container: docker-compose up -d

  3. Set the “External domain” in your Immich Server Settings to be whatever domain you use to publicly serve Immich Public Proxy. Now whenever you share an image or gallery through Immich, it will automatically create the correct public path for you.

For more detail on the steps, see the docs on Github.

@alan@feddit.org
creator
link
fedilink
English
8
edit-2
1M

The security of which URLS are accessible without authentication would be up to immich.

This is exactly the risk I’m wanting to mitigate. Immich is under heavy active development, and I want to abstract away from needing to worry whether the no-auth API URLs are safe to expose publicly.

At the end of the day I feel safer knowing that there is zero public access to any part of my Immich instance, which for me is what really matters.

@markstos@lemmy.world
link
fedilink
English
51M

Immich has a whole set of end-to-end automated tests to ensure they don’t accidentally make public any URLs they went to be private:

https://github.com/immich-app/immich/tree/main/e2e/src/api/specs

As a popular open source project, that would be e glaring security hole.

Using this proxy puts the trust in a far less popular project with fewer eyeballs on it, and introduces new risks that the author’s Github account is hacked or there’s vulnerability in he supply chain of this docker container.

It’s also not true that you “never need to touch it again” . It’s based on Node whose security update expire every two years. New image should be built at least every two years to keep to update with the latest Node security updates, which have often been in their HTTP/HTTPS protocol implementations, so they affect a range of Node apps directly exposed to the internet.

@alan@feddit.org
creator
link
fedilink
English
3
edit-2
1M

All good points, and Apple has some of the most skilled engineers in the world and The Fappening still happened.

It’s not possible for me to audit everything that’s happening security-wise in Immich, but I can fully understand what’s happening in this small codebase to my own satisfaction. At the end of the day I feel safer knowing that there is no public access to any part of my Immich instance.

It’s also not true that you “never need to touch it again”

I meant that you don’t need to use it to share photos, not that you never need to update your docker containers! 😱 Thanks, I have clarified that.

Create a post

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:

  1. Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

  • 1 user online
  • 252 users / day
  • 488 users / week
  • 1.09K users / month
  • 3.79K users / 6 months
  • 1 subscriber
  • 3.91K Posts
  • 79.2K Comments
  • Modlog