PiGallery2

Last reviewed Sep 13, 2026 · 936 words

If your photos already live in a folder tree you spent years curating, PiGallery2 is the gallery that respects it. It never moves, renames, or rewrites a file; it reads the directories, builds thumbnails and an SQLite index on the side, and serves what it finds. Immich and PhotoPrism both want to own the library. PiGallery2 wants to be a window onto one you already own, and on a Raspberry Pi with 512 MB spare that is exactly the right ambition.

Your folders are the albums, and nothing gets moved

The mental model is a read-only mount. Point the container at /srv/photos, and every directory becomes a gallery, every subdirectory a nested one, sorted by whatever the folder names say. There is no upload button, no "import" step that copies files into an opaque blob store, and no database you need to keep in sync with the disk. Delete a folder on the NAS and it vanishes from the gallery on the next index. The compose file is short:

services:
  pigallery2:
    image: bpatrik/pigallery2:latest
    environment:
      - NODE_ENV=production
    volumes:
      - ./config:/app/data/config
      - ./db:/app/data/db
      - /srv/photos:/app/data/images:ro
      - ./tmp:/app/data/tmp
    ports:
      - "8080:80"
    restart: unless-stopped

Note the :ro on the images mount. The project already promises not to write there; making it physically impossible costs nothing and means a bad update can never eat the originals. The tmp volume holds generated thumbnails and transcoded video, so give it a few GB on fast storage rather than the photo share itself. First login is admin / admin; change it before you forward a port.

Faces come from your tagger, not from PiGallery2

This is the point that trips up Google Photos refugees. PiGallery2 shows people and lets you search by them, but it does no face detection of its own. It reads the region tags that a desktop tool like digiKam, Lightroom, or Picasa's old XMP writes into the file metadata. If you have never tagged a face in your life, the People page will be empty and stay empty. The same goes for keywords and ratings: the gallery surfaces what is already in EXIF, IPTC, and XMP. Geolocation is the exception, because cameras and phones write GPS coordinates themselves, so the map view works out of the box for anything shot on a phone since about 2012.

Whether that is a limitation or a feature depends on where you want your metadata to live. I want it in the files, where any future tool can read it, and PiGallery2 is the only mainstream gallery whose design forces that discipline.

The search syntax is the reason to pick it over a plain file browser

The search box takes expressions, not just words. You can combine keywords, people, dates, ratings, and location with and, or, and negation, and then save the result as a virtual album that updates itself as new files land. A query for a person, restricted to a year range, excluding a keyword, is a one-liner. Random-photo endpoints let you feed a digital frame or a Home Assistant dashboard with a rotating slideshow from a saved search. For a family archive that is far more useful than a machine-learning "memories" feed, and it runs at the speed of an SQLite query rather than a GPU job.

Video plays too, transcoded through ffmpeg on demand, and the results cache in tmp. On a Pi 4 the first play of a 4K clip takes a while; on any x86 mini PC it is a non-event.

Sharing and the multi-user ceiling

Share links carry an optional password and an expiry, which covers the "send grandma the holiday folder" case cleanly. User management is thinner: there are roles and per-directory permissions, but it is not the kind of per-user library separation you get in Immich, and there is no mobile app doing automatic camera uploads. PiGallery2 is a viewer for a curated archive, not the place your phone dumps 3,000 screenshots. If you need that ingest pipeline, run it elsewhere and let this gallery read the output.

Where it loses to Immich

Be honest about the gap. Immich does phone backup, face clustering without prior tags, semantic "photo of a red bicycle" search, and shared albums with editing. It also needs more like 4 GB of RAM plus a Postgres instance, and it holds your library in its own structure. The Immich versus PhotoPrism comparison covers that end of the market. PiGallery2 sits at 2,276 stars precisely because it refuses to be that: MIT licensed, TypeScript, one container, a few hundred MB of memory, and files it will never rearrange. Pick it as your Google Photos replacement only if your source of truth is a folder tree and you are happy to keep it that way; the rest of the photos category covers the other shapes.

What I'd do

Run it read-only against the NAS share, generate thumbnails once on the fastest disk you have, and tag faces and keywords in digiKam before expecting them to show up. Pair it with Syncthing or a nightly rsync from the phone into a dated folder, and you have a gallery that will still work unchanged in ten years because the data never left the filesystem. If the phone-backup and automatic-faces experience matters more than that durability, go to Immich and do not look back; if it does not, PiGallery2 is the lightest honest answer in the category.