A photo library is an identity record that happens to contain pictures

A title query for Immich returns 510 matches in ZoomEye. The figure looks small beside the categories around it, and the contents of a single instance can outrank all of them. Personal media is where identifying material accumulates even though nobody decided to collect it.

Context and method

The query ran on 2026-10-01 and matched the title field for the literal string. ZoomEye title matching is inclusive, so a record returns when the string appears anywhere in the parsed title. One match equals one indexed record, captured whenever the scanner last reached the host.
The count therefore describes how many indexed records present the name. It says nothing about whether the instance holds a personal library or a test album, whether login is enforced, or who runs it.

What the product holds

Immich is a self-hosted replacement for consumer photo services. It backs up media from mobile clients, indexes it, pulls metadata out of image files and serves a browsable library, with search, albums and face grouping in recent versions. A typical deployment runs the application server, a database, a cache and a machine learning component for recognition tasks.
The important property is the metadata rather than the storage. Photographs from phones carry capture time and device model and, when location services were enabled, coordinates. Face grouping adds a second index that links one person across years of pictures.

Why a small count is not a small risk

Three concerns follow from the contents.
Location history. A library with coordinates reconstructs where a person slept, worked and travelled, and the pattern shows up before any image is opened.
Presence information. Face grouping and search make it possible to answer questions about a named individual without browsing the whole collection, which turns the library into a queryable biography.
Third-party exposure. Family photographs include people who never agreed to any of this, and their presence in the library is not something the operator can consent to for them.
The authentication path matters for the same reason. Mobile backup is a convenience feature, and the convenience of a client that reconnects automatically is the same property that makes a stolen token more useful than a stolen password.

Reading the count sensibly

A title match cannot distinguish a personal library, an internal media archive for a small organisation, and a demonstration deployment. It also cannot tell you whether the instance sits behind a reverse proxy with an identity provider in front of it or is reachable directly over the network.
The claim that holds is narrow. Hundreds of self-hosted media libraries are indexed, a small population that still needs an owner and a policy.

Running the check honestly

Identify the instances your organisation runs and verify them directly. Confirm whether the library is reachable from outside the network and where authentication is enforced. Confirm whether the mobile client configuration is shared, and whether session tokens are long-lived. Confirm where media is stored and whether that storage is reachable from other hosts. Confirm whether the recognition components run with access to cloud credentials.
Where the library is personal, the sensible default is access over a private network. Where it is organisational, treat it as a records system with an identity dimension rather than as a file share.

Implications for defenders

Judge this category by what the contents let someone infer rather than by the number of records indexed. A small exposed library can disclose more about the people in it than a large database of page views.

References

• ZoomEye query for title="Immich": https://www.zoomeye.ai/searchResult?q=dGl0bGU9IkltbWljaCI%3D
• Immich documentation: https://immich.app/docs/overview/introduction
• Immich source repository: https://github.com/immich-app/immich