Photoview

Last reviewed Sep 13, 2026 · 846 words

Mount your existing photo folders read-only, start one container, and Photoview gives you a timeline, albums that mirror your directory structure, face recognition and RAW previews without moving, renaming or reorganising a single file. That is its entire pitch, and for the people it fits, a photographer with 20 years of 2014/Iceland/ folders on a NAS, it is the right answer. For everyone else, Immich is the bigger project and the safer choice, and I will be specific about why.

Your folders are the source of truth

Photoview scans one or more paths you give it and treats each directory as an album. It never writes into those paths; the container can and should mount them read-only. Thumbnails, transcoded video previews and the face model output go into a separate cache volume. Delete the container and the cache, and your library is exactly as you left it. This is the property that Immich and PhotoPrism only partially offer through their external-library modes, which still index into their own databases and, in Immich's case, still expect the app's own upload path for anything from a phone. If you have organised photos by hand for a decade and want the software to respect that, Photoview does it with no configuration.

The compose file

services:
  photoview:
    image: viktorstrate/photoview:2
    ports:
      - "8000:80"
    environment:
      - PHOTOVIEW_DATABASE_DRIVER=sqlite
      - PHOTOVIEW_SQLITE_PATH=/app/database/photoview.db
      - PHOTOVIEW_LISTEN_IP=photoview
      - PHOTOVIEW_LISTEN_PORT=80
      - PHOTOVIEW_MEDIA_CACHE=/app/cache
    volumes:
      - ./database:/app/database
      - ./cache:/app/cache
      - /mnt/photos:/photos:ro
    restart: unless-stopped

On first visit you create the initial admin user and point it at /photos. SQLite is fine for a single user with under 100,000 photos; the driver also supports MySQL, MariaDB and PostgreSQL if you already run one. Each additional user gets their own set of root paths, so two people can share a server with fully separate libraries, or overlapping ones. The Go backend idles around 100 MB and spikes during scanning; the 512 MB figure is a sensible floor because face detection and RAW decoding happen in the same process.

What it does well

The timeline view, albums and per-album sharing links via a public URL with optional password all work as you would expect. RAW support covers the common formats through a bundled decoder, and videos are transcoded once to a web-playable preview. Face recognition groups faces across the library and lets you name them, then search by person; it runs on CPU and is slow on a first pass over a large library, roughly overnight for 50,000 images on a modest x86 box, then incremental. Maps use EXIF GPS data. Periodic rescans can be scheduled in the admin settings, and a manual scan button exists for after a big import.

What it does not do, and why that matters

There is no mobile app and no phone backup. Photoview will not pull photos off an iPhone or Android device; you need another mechanism to get them onto the server, and then Photoview will display them. Immich's phone app, which backs up automatically like Google Photos does, is the single feature that decides most people's choice, and Photoview has no answer to it. There is also no editing, no duplicate detection, no object or scene search, no machine-learning tagging beyond faces, and the release cadence is slow; the project describes itself as a small team and it shows in the issue tracker. If your goal is to leave Google Photos, the Google Photos alternatives page and the Immich versus PhotoPrism comparison cover the tools that replicate the phone-first workflow. Photoview is not trying to.

Who actually runs Photoview

Three profiles, from what I see. Photographers with a DSLR workflow: photos come off an SD card into a dated folder tree, get culled in Darktable or Lightroom, and Photoview is the family-facing browser on top. Families with a legacy archive: a NAS full of Photos/2009/ that nobody wants to import into anything, and Photoview gives it a timeline in an afternoon. And people who tried Immich, disliked that it wanted its own upload directory and database as the canonical copy, and wanted their folders to remain the canonical copy. All three are good reasons. "I want something lighter than Immich" is a weaker one; Immich runs acceptably on 2 GB and the difference disappears once Photoview's face recognition kicks in.

What I'd do

If your photos arrive from a phone, run Immich and let it own the library; it is the more active project by a wide margin and its mobile app is the reason. If your photos arrive from a camera into folders you curate, run Photoview on top of those folders, read-only, with SQLite, and schedule a nightly rescan. Running both against the same folders is possible with Immich's external library feature, but pick one as the family's front door, and for a curated folder tree that door is Photoview.