LibrePhotos

Last reviewed Aug 26, 2026 · 884 words

LibrePhotos is the right choice for exactly one kind of person: you already keep photos in a folder tree you organised yourself, you are not willing to let software reorganise it, and you want Google Photos-style faces, objects and search over that tree. It reads your directory in place and writes nothing back into it. If what you actually want is your phone's camera roll backing itself up every night, stop here and install Immich, because LibrePhotos has no first-party mobile upload app, and that single gap decides the matter for most households.

Scan-in-place is the feature, not a limitation

You mount your existing photo directory into the backend container, ideally read-only, and LibrePhotos walks it, extracts EXIF, builds thumbnails into its own data directory, and records everything in Postgres. Your originals are never renamed, moved or rewritten. Delete the whole stack tomorrow and you lose thumbnails and metadata, both of which are regenerable, and nothing else. Immich works the other way round: uploads land in its own library layout and external folders are a secondary, read-only concept bolted on later. PhotoPrism also indexes an originals folder in place, which makes it the closer rival; the Immich vs PhotoPrism piece covers that split, and LibrePhotos sits on PhotoPrism's side of it with a more permissive MIT licence and a Python codebase you can actually read.

The 2 GB minimum is a floor, and the first scan takes days

Every smart feature is a machine-learning model that runs on your CPU: face detection and clustering, object and scene tagging, semantic text search over image content, plus geocoding for the map view. Those models load into memory when the backend starts and stay there, which is where the 2 GB goes before a single photo is processed. On 2 GB the stack runs but the scan swaps; 4 GB is comfortable for one user; 8 GB if the box also does other things. The first scan is CPU-bound and slow. My rough rule is a few seconds per photo on a 4-core mini PC once face and object detection are enabled, so a 50,000-image archive is measured in days, not hours. Later scans only touch new files. Plan the first one for a week where you do not need the machine for anything else, and do not judge the app by its speed until it finishes.

Setup is a git clone and one .env file

The supported deployment is the librephotos-docker repository from the project's GitHub, which is a Compose file plus an environment template. Clone it, copy the template to .env, and edit five lines: scanDirectory (your photo tree), data (where thumbnails and caches go, give it 10 to 20 percent of the size of the originals), dbLocation (the Postgres volume), httpPort (3000 by default), and adminUsername with adminPassword. Set a long random SECRET_KEY while you are there. docker compose up -d brings up the nginx proxy, the frontend, the Python backend and Postgres. Log in as admin, open the admin area, assign your own user a scan directory underneath the mounted root, and start the scan from the library page. The setup is fiddly mostly in the sense that the .env has a lot of lines and most of them can be left alone; the five above are the ones that matter.

Multi-user means separate trees, not one shared library

Each user is assigned their own scan directory by the admin, so a family maps to a folder per person under the mounted root. Photos and albums can be shared between users after the fact, but there is no single household library that everyone uploads into, because there is no uploading. That model suits an archive-keeper household well and a "everyone's phone dumps into one place" household poorly. If the second describes you, Immich's partner sharing is what you are looking for, and the Google Photos alternatives page lays out who each option suits.

Backups are cheaper than usual because the originals are already yours

The app owns two things: the Postgres database and the data directory. pg_dump the database nightly and copy the data directory when convenient, knowing that if it burns, a rescan rebuilds it at the cost of another few days of CPU. The originals sit in your folder tree, backed up however you already back up files, in a layout no application defined. That is the quiet advantage of scan-in-place: there is no export step to run when you leave, because the photos never entered the application in the first place.

What I'd do

If phone backup matters even slightly, Immich, with your old folder tree attached as an external library. If the tree is the point, photos arrive by card reader or camera sync, and you want faces and search without giving up your directory structure, LibrePhotos on a box with at least 4 GB, the photo mount read-only, the first scan started on a Friday night. Check it the following weekend, tag a few faces so the clustering has names to work with, and from then on it costs you almost nothing to run.