Immich Is More Than a Photo Gallery
Immich is a self-hosted photo and video management system. The useful question is not simply whether its timeline looks polished, but what has to happen behind that timeline for a personal archive to remain findable, shareable, and recoverable. This opening establishes that broader subject and the judgment this series supports: a self-hosted archive should be evaluated by the way it manages an asset’s whole life, from capture and upload to processing, storage, search, sharing, and restoration.
That distinction matters because personal media rarely arrives in one clean batch. A library may include phone photos, videos copied from an older computer, camera files, assets uploaded through a browser, and material that remains on a separate disk. People also expect more than a file browser. They want to search for a place or a person, remove duplicates, view a video on a device that did not create it, share a selection with relatives, and continue using the collection after a disk or server fails. Immich’s feature set reflects that breadth. Its own project description includes mobile backup, web access, albums, multi-user support, metadata and map views, contextual and face-based search, public sharing, user-defined storage, and background processing. Those are not isolated conveniences. Together, they create a system that must preserve relationships around the original files.
A gallery is the visible edge of an archive
A gallery encourages a simple mental model: files go in, pictures appear, and the application is mainly a window onto them. That model breaks as soon as the archive needs identity and continuity. If the same image arrives from a phone and later from a command-line upload, the system needs a way to recognize that they are the same asset. If a video needs a compatible playback version, that version is derived from an original rather than replacing it. If a user adds a description or places an image in an album, that information has to be connected to a person, an account, and a particular asset. If a search for “children at the beach” returns results, the answer may depend on a learned index rather than words embedded in the filename.
Immich is therefore closer to a small information system than to a static gallery. Its clients include mobile and web applications and a command-line utility. Those clients communicate with server APIs, while other services perform work in the background. A database holds system relationships such as users, assets, albums, authorization, and sharing settings. A filesystem holds original and generated media. A queue coordinates work that would be too slow or too resource-intensive to perform during an interactive request. A separate machine-learning service can build indexes for contextual search and facial recognition.
The separation is important because the user sees one product even when the system is doing several different kinds of work. Opening a timeline is an interactive request. Generating previews for a large import is a batch workload. Searching for a visual concept depends on an index that may be built after the original upload. Restoring a collection after a failure is a consistency problem involving both records and files. Treating all of these as “the gallery” hides the conditions under which the gallery remains trustworthy.
Self-hosting makes those conditions part of the user’s responsibility. The operator chooses where the media and database live, how the services are exposed, whether machine learning runs locally, and how copies are made. Immich prominently recommends a 3-2-1 backup strategy, but the recommendation is not the same as an automatic backup service. A system can be convenient every day and still be fragile if its database is not copied, if its original media is not protected, or if nobody has checked that a restore works.
This is the central tension: self-hosting can give an operator more control over personal media, but control also means inheriting the boundaries that a hosted service might otherwise hide. The archive is valuable not because it has a particular screen, but because the system can preserve enough structure around the originals to make them useful later.
One asset, several layers
The easiest way to see the difference between a gallery and an archive is to follow one asset conceptually. Start with an original photo on a phone. The original is the irreplaceable content. Immich may then associate it with an account, a path, timestamps, an album, location metadata, and sharing permissions. Background jobs may create small, large, blurred, and face previews, or an encoded version of a video. Machine-learning work may add a contextual representation or face embeddings so the asset can be found through a concept or a person. Each layer serves a different purpose and can become ready at a different time.
The original and its surrounding layers should not be confused. A thumbnail is useful for quickly drawing a timeline, but it is not a substitute for the original. A face embedding can help cluster similar faces, but it is not a verified identity. A database record can tell Immich where an asset belongs and how it relates to an album, but a database dump does not contain the photo or video itself. Conversely, a folder full of originals is not a complete Immich archive if the database relationships that make those files searchable and attributable are gone.
This layered view also explains why an upload can appear to be partly complete. The original may have arrived while metadata extraction, thumbnail generation, transcoding, OCR, smart search, or facial recognition remains queued. The user can reasonably see the asset, yet not be able to use every feature on it immediately. The delay is not necessarily evidence that the original was lost; it may mean that a derived layer has not been built.
The project’s documented architecture makes this division explicit. The server handles API requests and schedules work; background workers consume jobs through Redis and BullMQ; Postgres stores durable system information; the filesystem stores media; and the machine-learning service handles model-based operations. The components are different, but the user experiences their combined result as one asset record.
The diagram is not a claim that every job finishes in one fixed sequence in every release. It is a model of responsibility. Clients initiate work; the API accepts and records it; background processing adds useful layers; durable state connects those layers; and search or sharing exposes the result. Backup must reach the original files and the metadata that gives those files meaning.
This is also why the phrase “the files are still there” is incomplete as a recovery argument. Immich’s documentation says that it does not simply scan the library folder to reconstruct its database. Database backups contain metadata, not photos and videos, and the application does not arrange filesystem backups for the operator. A comprehensive recovery plan therefore has to preserve both sides and keep them sufficiently consistent. Derived thumbnails and encoded video may be regenerated in some situations, but rebuilding them still costs time and processing capacity; losing originals or the records that point to them is a more fundamental failure.
The operator’s real question
The practical question for an Immich operator is not “Which features should I turn on?” It is “Which layer owns each piece of meaning, how does that layer change, and what will I need if it fails?” That question produces better decisions than a feature checklist because it connects everyday convenience to long-term responsibility.
First, ask who owns the original. In a managed library, Immich expects its application and its storage rules to govern the asset. In an external library, the file remains outside Immich and is discovered through scans. That difference affects deletion, movement, permissions, and whether metadata added in the application is written back to the file. A read-only external mount may protect the original from application-side deletion, but it also limits what Immich can write alongside it. The important distinction is not which mode is universally best; it is whether the operator understands which system is authoritative.
Second, ask which information is explicit and which is inferred. A filename, capture date, or GPS tag is an explicit property that can be searched or filtered. A contextual result or a named face is produced by a model and an indexing process. The latter can be extremely useful without being ground truth. It may require memory, model downloads, reprocessing, and human correction. Treating a learned index as a convenient view over the archive is safer than treating it as a final statement about what an image contains or who appears in it.
Third, ask what happens between a successful upload and a successful archive. Mobile backup depends partly on the operating system’s background-task rules and network conditions. Server-side jobs depend on worker capacity and their prerequisites. A healthy API does not prove that every preview or search index is ready. Observing queues and understanding their dependencies is therefore part of operating the archive, not an implementation detail reserved for developers.
Finally, ask what “backed up” means. A database copy without originals cannot restore the media. Originals without the database may lose albums, paths, ownership, and other relationships. A public link that still works is not evidence that a private archive is safely governed. A face search that returns plausible results is not evidence of identity accuracy. Durable ownership means preserving the material, the structure around it, and the limits of the inferences built on top.
Immich’s value becomes clearer through this lens. It is not merely trying to display a folder elegantly; it is coordinating multiple kinds of state so a personal collection can be used as a living archive. The next question is how its clients, API, background workers, queues, databases, files, and machine-learning service divide that responsibility—and why those boundaries determine both the system’s strengths and its failure modes.