HO

HomeGallery

Self-hosted browsable photo and video gallery with similarity search

Photo Management ★ 1.2k stars Medium setup MIT

HomeGallery is a self-hosted web gallery that indexes photos and videos and offers fast browsing, similarity search, and face detection. It builds an offline-capable database from your existing media folders.

Key features

  • Similarity search
  • Face detection
  • Video support
  • Offline-capable database

Pros & cons

Strengths

  • Fast browsing
  • Reads existing folders

Trade-offs

  • Indexing can be slow
  • No upload from app

HomeGallery replaces

Last reviewed Sep 13, 2026 · 839 words

HomeGallery is the gallery you run when your photos already live in folders you refuse to reorganise. It never moves, renames, or uploads a file; it reads your directories, writes previews and a database to a separate storage folder, and serves a browser app that keeps working after you disconnect. The price is the first index: on a 40,000-image library expect the initial run to take many hours, most of it spent generating previews and machine-learning embeddings, and expect the 1 GB RAM floor to be a real floor rather than a suggestion.

The folder-first model is the whole point

Immich and PhotoPrism want to own the library: uploads, mobile backups, their own directory structures. HomeGallery wants nothing. Point it at /mnt/photos, mount the source read-only, and it builds an index of file hashes, extracts EXIF and video metadata, generates resized previews, and stores everything under its own storage directory. Delete that directory and your originals are untouched. That makes it a good fit for people who already sync photos with Syncthing or rclone and just want a fast way to look at them, and a poor fit for anyone who wants to back up a phone. There is no upload from the web app at all, and the mobile experience is the offline-capable web app, not a native client.

Indexing is slow because it is doing real work

Three things happen per file: a hash to detect duplicates and moved files, a preview pipeline (several sizes for images, a short transcoded clip plus poster frame for videos), and a machine-learning pass that produces embeddings for similarity search plus face and object detection. Video previews are the expensive bit; transcoding a few thousand phone videos on a low-power box takes days, not hours. Two mitigations matter. First, the ML step calls an API server that you can run as its own container (the project offers a public one as the default), so the gallery box itself does not need TensorFlow. Second, incremental runs only touch new or changed files, so the pain is front-loaded. Plan the first index for a weekend and let it finish.

Similarity search is better than expected, organisation is thin

The headline feature: click a photo of a beach and get every beach photo you own, without ever writing a tag. It works through embeddings rather than labels, so it finds visual neighbours that keyword search misses. Object detection adds coarse searchable terms ("dog", "car"), and face detection groups similar faces but does not ask you to name them. Beyond that, organisation is minimal. Tags exist and are stored in an append-only events file, but there is no album model comparable to Immich's, no sharing links, and no per-user libraries. Single household, one library, browse and search: that is the scope.

Run it as one long-lived container

The Docker image bundles the CLI, and the interactive run command handles import, extraction, and serving in one process on port 3000. A minimal setup mounts your photo root read-only and a writable storage path:

services:
  gallery:
    image: xemle/home-gallery
    command: run
    ports:
      - "3000:3000"
    volumes:
      - /mnt/photos:/data/photos:ro
      - ./gallery-storage:/data/storage
    restart: unless-stopped

Configuration lives in a gallery.config.yml you generate on first run; the sources list, the storage path, and the API server URL are the lines you will touch. Put a reverse proxy in front and treat the gallery as a read-only viewer: it needs no database server and its state is just files, so backing it up means backing up the storage folder, and even that is reproducible from the originals.

Where it loses to the bigger projects

At 1,181 stars and effectively one maintainer, HomeGallery is a niche tool next to Immich and PhotoPrism, and you should be clear-eyed about it. It has no mobile backup, no sharing, no multi-user separation, and a JavaScript ML pipeline that is slower than Immich's. What it has is a lighter operational footprint (no Postgres, no Redis, no ML containers unless you want them local) and total indifference to how your folders are arranged. If the goal is replacing Google Photos for a family, read the Immich versus PhotoPrism comparison instead; that is the photos category answer for most people.

What I'd do

If my photos already sat in a folder tree I curate by hand, I would run HomeGallery as a viewer, mount the source read-only, host the API server as a second container so embeddings stay local, and accept a slow first weekend of indexing. I would not pick it as the primary photo system for a household with phones to back up; that is Immich's job, and HomeGallery makes no attempt to compete there. One container, no database, your folders left exactly as they were: that is a narrow promise, and it keeps it.

Compare HomeGallery

21 head-to-head comparisons.

Similar photo management apps