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.

  • davad@lemmy.world
    link
    fedilink
    English
    arrow-up
    5
    ·
    11 days ago

    Yup, also some APIs use GET for everything. It’s a pain. And it means that filtering by verb only helps if you’re intimately familiar with the API. And even then, only if you keep up with changes as they happen. So really, only if you’re developing the API yourself.

    • davad@lemmy.world
      link
      fedilink
      English
      arrow-up
      4
      ·
      edit-2
      10 days ago

      (another pet peeve of mine is “rest” APIs that use 200 response codes for everything)

      • Atemu@lemmy.ml
        link
        fedilink
        English
        arrow-up
        2
        ·
        11 days ago

        Ahhhhh whyyyyy, you’ve got all of these standard response codes made for you, why would you blatantly ignore them like that?!

        • davad@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          10 days ago

          The only one I think is reasonable is GraphQL. But that isn’t rest, and HTTP is just one of the transport layers it supports.

          For anything claiming to be RESTful, it’s a crime.