v1.1.0

Photos of one person, pulled from more than one Immich account.

The problem

Immich scopes face recognition per account. The link between a detected face and a person belongs to whoever owns it, so a search with your person id never returns photos sitting in a partner's account — even when the same child is tagged in both libraries. If half the photos of your kid were taken on someone else's phone, half of them were invisible to grow-up, and nothing in the output said so.

The fix

A source is now an account: a URL, an API key, and the person id within that account.

[[immich.sources]]
name = "me"
person_id = "…"                      # your account's record for the subject

[[immich.sources]]
name = "partner"
person_id = "…"                      # *their* account's record for the same person
key_env = "IMMICH_API_KEY_PARTNER"

export IMMICH_API_KEY=…              # yours
export IMMICH_API_KEY_PARTNER=…      # theirs, from their own Account Settings → API Keys

Their key needs the same four permissions as yours. url_env can be set per source too, if the two accounts are on different servers.

Indexing, face lookup and download run once per account; filtering, alignment and encoding then see one merged pool, so the timelapse interleaves both libraries by date. Each account keeps its own sync watermark, so they stay incremental independently — grow-up status shows a block per account.

New --source NAME on index, faces, fetch, run, trial and doctor works on one account at a time.

Two failure modes made loud

• Two sources sharing one API key is rejected at load. It is the copy-paste mistake, and it would index the same account twice — leaving the partner's photos still missing, with nothing on screen to explain why. Exactly the symptom this release exists to remove.
• Every key is checked before any account starts work, and one failure aborts the run. A video quietly missing one account's photos looks completely fine, which makes it the worst kind of failure. Preflight messages now name the account they are about.

Nothing about an existing setup changes

• A config.toml with no [[immich.sources]] keeps working untouched — [immich] person_name / person_id on the plain IMMICH_URL / IMMICH_API_KEY is simply the one-account case.
• Databases from 1.0.0 upgrade in place. assets gains a source column, and the first configured source adopts the existing rows: everything in such a database came from the one account there was.
• A single-account run's output is byte-for-byte what it was, down to the progress labels and the preflight wording.

From 1.1.0 on, an existing config will not be broken by a release. New settings arrive with a default and a fallback for their absence.

Under the hood

sync_state and runs were already keyed on person id, so two accounts keep two independent watermarks with no new bookkeeping. assets.source exists because only the owning account's key can download an asset or answer a face lookup for it — asking the wrong one returns 404 on exactly the other account's half of the library.

514 tests, up from 473. The compatibility promise is written down as TestTheReleasedConfigStillWorks in tests/test_sources.py.

Notes

This project was written entirely by Claude (Anthropic's AI assistant, running as Claude Code) and supervised by the repository owner. The model has never had access to the Immich instance or its API keys; all verification against real libraries was done by the owner — including the two-account setup this release is about.