Open-source alternatives to Google Photos: 2 photo library tools compared
Moving a photo library off a hosted account means the originals, the index and the search all live on a machine you own, which also means somebody has to keep that machine on, back it up and prove the restore works. immich-app/immich is the one most readers should start with, because its mobile app does automatic background backup, which is the part a photo library has to get right.
What Google Photos does, and why people look elsewhere
Google Photos is hosted photo and video storage with automatic phone backup, face and object search, albums and sharing.
- storage counts against a paid Google account quota
- originals are held and analysed on Google's servers
- bulk export means a Takeout archive, not a live sync
The candidates at a glance
| Project | Licence | Maintenance | Language | GitHub stars | Install | Best for |
|---|---|---|---|---|---|---|
| immich-app/immich | AGPL-3.0Network copyleft: hosting a modified version means sharing source | Commits in the last dayLast push October 11, 2026 | TypeScript | 116,024 | See analysis | You have a phone full of photos and a machine that stays on, and you want automatic background backup plus a web library you can search. The feature table covers search by metadata, objects, faces and CLIP, facial recognition and clustering, Memories from past years, albums and shared albums, partner and public sharing, raw formats, LivePhoto and MotionPhoto backup, a global map, and multi-user support. |
| photoprism/photoprism | Custom licenceCustom licence: read the LICENSE file | Commits in the last six monthsLast push October 8, 2026 | Go | 40,278 | See analysis | You already have years of photos on disk and want them indexed, labelled and searchable rather than re-uploaded from a phone. The README describes a Go application that reads RAW images and video formats, a PWA you can install on the home screen, search filters over labels, location, resolution, colour, chroma and quality, automatic labelling by content and location, face recognition, Live Photos that play on hover, high-resolution world maps with a privacy-preserving geocoding service, and WebDAV access from Finder or Windows Explorer. |
Each alternative in detail
immich-app/immichHigh performance self-hosted photo and video management solution.
- Best for
- You have a phone full of photos and a machine that stays on, and you want automatic background backup plus a web library you can search. The feature table covers search by metadata, objects, faces and CLIP, facial recognition and clustering, Memories from past years, albums and shared albums, partner and public sharing, raw formats, LivePhoto and MotionPhoto backup, a global map, and multi-user support.
- What you give up
- Administration is web only, which our analysis of Immich names as the reason not to expect the phone app to cover it, and tags, 360 degree image display and API keys are also web only while offline support is mobile only. It is also not a managed service, and our analysis says not to adopt it if nobody will own backups: the README's own warning to follow a 3-2-1 backup plan is the first thing to read, not a footnote. AGPL-3.0 applies if you modify and expose it.
- Moving from Google Photos
- The README does not document a Google Photos import, so the practical route is to take your export and feed it in as a normal upload.
photoprism/photoprismAI-Powered Photos App 🌈💎✨
- Best for
- You already have years of photos on disk and want them indexed, labelled and searchable rather than re-uploaded from a phone. The README describes a Go application that reads RAW images and video formats, a PWA you can install on the home screen, search filters over labels, location, resolution, colour, chroma and quality, automatic labelling by content and location, face recognition, Live Photos that play on hover, high-resolution world maps with a privacy-preserving geocoding service, and WebDAV access from Finder or Windows Explorer.
- What you give up
- The repository's licence is one GitHub cannot classify, and our analysis of PhotoPrism tells you to check the AGPL terms in the LICENSE file against how you intend to expose the instance, so that is a file to read rather than a badge to skim. It is also not a permissively licensed codebase you can fork and redistribute without obligations, and the analysis warns against expecting the README alone to tell you how to run it in production: the installation instructions live on the documentation site. Some features sit behind a membership.
- Moving from Google Photos
- The README states that metadata can be extracted and merged from Exif, XMP and other sources such as Google Photos, so labels and locations from a Google Photos export can be carried across.
A phone backup app, a photo library, and why iCloud Photos is not on this list
Google Photos is hosted photo and video storage with automatic phone backup, face and object search, albums and sharing. People look elsewhere for three reasons. Storage counts against a Google account quota. Originals are held and analysed on Google's servers. And a bulk export means a Takeout archive rather than a live sync.
iCloud Photos is the other name in these searches and it is not here for the same reason: it is a hosted service tied to an Apple account, so the originals and their analysis sit on Apple's infrastructure. That is the third reason on the list, and it is the one that disqualifies it.
There is a fair case for staying on either. If your library fits the quota you have, and the automatic backup has never failed, and nobody will ever ask you to prove where a photo is stored, a hosted service is doing a genuinely hard job well. What changes when the reasons on the list apply is that the photo library becomes infrastructure, and infrastructure has an owner.
The two projects here are infrastructure in different shapes.
immich-app/immich is the phone-first one. It is an AGPL-3.0 TypeScript monorepo whose feature table is split into Mobile and Web columns, and reading that table is the fastest way to understand it. Upload and view, selective albums for backup, background backup, prevent duplication of assets, download to a local device, LivePhoto and MotionPhoto backup and playback, offline support and user-defined storage structure are all mobile. Administrative functions for user management, tags, 360 degree image display and API keys are web only. Search by metadata, objects, faces and CLIP, facial recognition and clustering, memories from past years, partner and public sharing, archive and favourites, a global map, stacked photos and folder view work on both.
photoprism/photoprism is the library-first one. It is a Go application whose README describes browsing RAW images and video formats without worrying about the format, an installable PWA for phone, tablet or desktop, search filters that combine over labels, location, resolution, colour, chroma and quality, automatic labelling based on content and location, face recognition for family and friends, Live Photos that start playing on hover, six high-resolution world maps with a privacy-preserving geocoding service, and WebDAV so Finder and Windows Explorer can open, edit and delete files as if they were local.
Left out, and worth saying why: the photo editors, which are tools that happen to store files rather than libraries that hold a lifetime of them, and the object storage buckets people improvise with. Both exist; neither is a replacement for automatic backup plus a searchable index.
Choosing by scenario: one person's phone, a family archive, a company with data residency rules
The question that separates these two is where the photos are today.
One person whose photos live on a phone and want them backed up off the phone should look at immich-app/immich. Background backup when the app is opened, automatic backup, selective albums for backup, duplicate prevention and download to a local device are all in the mobile column, and the machine on the other end is one you control. What you give up is a managed service, and the backup obligation that comes with it.
A family with twenty years of photos already on a disk, or exported from somewhere, should look at photoprism/photoprism. Its pitch is indexing what you have, not re-uploading from a phone: RAW formats, metadata merged from Exif and XMP, automatic labelling, faces, quality filters and WebDAV access from a desktop file manager. The WebDAV point is the one people underestimate, because it means your existing desktop workflow keeps working.
A company with data residency requirements can run either, and the decision is operational rather than legal. Both keep originals and their derived index on infrastructure you choose. The difference is the shape: Immich is a mobile client talking to a server, so you need a reachable endpoint and a device backup story; PhotoPrism is a server that indexes a library, so you need storage and a place to put the originals.
A developer who wants to build on a photo library should note that both expose an API, and that Immich's API keys are web only, which is consistent with administration being a server-side concern in both. Neither is a component you embed in another product, and neither is meant to be.
One scenario neither covers well is a shared family library where several people each want their own private space with easy sharing. Both support multiple users and sharing, and both make the administration a web task, so the person who owns the server is a role somebody has to agree to take.
What each one asks you to run
The install commands on this page are both Docker, and the difference is in what has to exist before you run them.
immich-app/immich shows a directory being created, a comment telling you to fetch the compose file and the .env for your release from the documentation site, and then docker compose up -d. That comment is the whole operational story: the configuration is versioned with the release, so an upgrade is a matter of taking the new compose file and the new environment file, which is a good property, because it means your configuration is not silently drifting.
photoprism/photoprism shows docker compose up -d, and the README supplies the surrounding detail. It needs a web browser and Docker, it is available for Mac, Linux and Windows, the image is multi-arch for 64-bit AMD, Intel and ARM, and Raspberry Pi and Apple Silicon users are told they get the same functionality through the same installation steps. It also offers tar.gz packages for people who do not want Docker.
Underneath, the storage question is the same for both and it is the one that decides whether this works for you. A library of phone photos with video is large, it grows every week, and the index is a database. Our analysis of Immich asks you to verify that your host meets the requirements listed in the installation documentation, that your backup routine actually restores, and that the server endpoint URL your phone will use is reachable from outside your home network if you need remote access. That last one is the step people miss, and it is a networking task rather than a PhotoPrism or Immich task.
The other operational point is the one the Immich README leads with. It warns you to follow a 3-2-1 backup plan for your photos and videos, and our analysis calls that bluntness appropriate rather than alarmist. Moving your library onto a machine you own does not by itself protect it, because now the single machine holds everything. The archive you migrated away from was replicated by someone else; this one is not, unless you make it so.
Licences: AGPL-3.0, and a repository that needs the LICENSE file read
Two projects, one clean licence and one that needs a file opened.
immich-app/immich is AGPL-3.0, and it is worth being clear about what that means for a personal library as opposed to a company one. For a household running it on a home server with nobody modifying the source, the licence is not a live consideration at all. For a company that modifies it and lets users reach the modified instance over a network, the source obligation applies, and our analysis of Immich names AGPL-3.0 among the things to check before you modify and expose it.
photoprism/photoprism is the one that needs reading. The repository is a custom licence as far as GitHub is concerned, while the project documentation points at its AGPL terms, and our analysis of PhotoPrism tells you to check the AGPL terms in the LICENSE file against how you intend to expose the instance. Two signals that are consistent in practice but ambiguous in metadata is a reason to open the file. The analysis also frames the thing that matters most about this project commercially: it is self-funded and independent, with some features behind a membership, so what you are evaluating is a community edition whose feature set may not be the feature set you need.
One point applies to both. Neither licence has anything to say about the photographs. Your images are yours regardless of which of these two you run, which is the actual reason most people make this move, and it is the reason none of these tools is going to make the decision for you.
Bottom line
Pick immich-app/immich if the photos are on a phone today and you want automatic background backup against storage you control, and photoprism/photoprism if you have a large library already on disk and want it indexed, searchable and reachable over WebDAV, including metadata carried across from a Google Photos export. Before committing, confirm your host meets the documented requirements, set up a 3-2-1 backup and test that it restores, work out whether your phone can reach the server endpoint from outside your home network, and read the PhotoPrism LICENSE file rather than relying on the badge.