Choosing a photo library
There are three ways to get out of Google Photos, and they are usually presented as if they were one choice. They are not, and picking the wrong one is why so many people abandon the project halfway through.
Cloud — Google Photos, iCloud, Dropbox. Someone else's computer, someone else's rules, and a bill that grows with your library.
Self-hosted — Immich, PhotoPrism, LibrePhotos and friends. Your computer, your rules, and a server you now own and have to operate. The software is excellent. The operational work is real: Docker, an always-on machine, backups of the database as well as the photos, and an upgrade that occasionally goes sideways at 11pm.
Desktop — digiKam, PhotoStructure, Smriti. No server, no containers, no always-on machine. The library lives in a program on whichever computer you happen to be using, pointed at drives you already own.
Most "alternatives to Google Photos" articles cover the first two. This page is about the third, and about the question underneath it: do you actually want to run a server?
You want the self-hosted option if:
You want the desktop option if:
Neither answer is better. A desktop application cannot back up your camera roll while you sleep, and a server cannot be carried to your parents' house in a backpack.
Take Smriti as the example, since it is the one this project maintains. It is a desktop application for Linux, Windows and macOS, free and Apache-2.0. It indexes photographs where they already are, extracts the EXIF metadata, generates thumbnails, and can recognise faces on-device. No account, no cloud, no server.
The design decision that separates it from the server-based projects is where the database goes. Smriti writes its catalog — paths, dates, albums, tags, face groupings, thumbnails — to a folder on the photo drive itself:
/media/you/MyPhotos/.photovault/photovault.dbWhich means the library is not a service you keep running. It is a property of the disk. Unplug the drive and the library leaves with it. Plug it into another machine with Smriti installed, and the albums, faces and tags are all still there — no sync, no export, no re-index. Back up the photo folder and you have backed up your organising as well.
That is also the honest limitation: if you delete
.photovault, you lose the catalog and have to re-index.
| Cloud | Self-hosted server | Desktop (Smriti) | |
|---|---|---|---|
| Where the library lives | Their servers | Your server | Your drive, catalog included |
| Setup | Sign in | Docker, storage, backups | Install a package, pick a folder |
| Phone access | Native | Native or web | Not supported |
| Offline use | Limited | Depends on the network | Complete |
| Runs when your computer is off | n/a | Yes | No |
| Ongoing maintenance | None | Real | None |
| Multi-user | Yes | Yes | One machine at a time |
| Cost | Subscription | Hardware and electricity | Free |
If the "phone access" row is the one that matters to you, use Immich or Ente — genuinely, that is what they are for. If the "runs when your computer is off" row matters, the same answer. Smriti is not trying to win that comparison; it is trying to serve people whose photos are on drives, not on a phone.
Portability. Hand someone a drive and they have the entire organised library — not a folder of files. For family archives, that is the difference between a usable collection and a pile.
Backups that mean something. Copying the photo folder copies the albums, tags and face groupings along with the originals. There is no separate database backup to forget.
No sync conflicts. There is one copy of the library and it is on the disk. Nothing to reconcile.
Smriti is tested at 250,000 photographs per drive, and the 1.0 series documents that as the current limit. If your library is larger than that, a server-based project with a proper database server behind it is the more sensible choice — it is a real architectural limit, not a marketing one.
Apache-2.0 · Free · No account, no server