Why Does Immich Behave Differently After a Container Restart?

Immich changes after a restart because transient caches disappear and service dependencies reconnect, while misconfigured persistence can expose more serious state loss.

A slow first search may be normal cold behavior; a fresh onboarding screen is not. Classify the symptom by duration and scope before changing data, because cache warming, dependency failure, and missing persistent storage require completely different responses.

A Restart Removes Transient Process State

Restarted processes lose in-memory models, connection pools, compiled paths, and application caches. The host page cache may survive a container restart, but a host reboot removes more warmth. Consequently, the first search or timeline request can perform initialization work that immediate repeats avoid.

A community measurement reports a slow first smart search followed by much faster repeats while the machine-learning model loads into GPU memory. The exact timing is local to that server, but the state transition explains why one post-restart request cannot represent steady operation.

Run the same known request three times and record whether latency converges. If only the first request is slow and results remain correct, investigate cold loading or retention policy. If every request fails or state appears missing, stop treating the symptom as cache warming and examine dependencies and persistence.

Dependency Order Can Expose a Startup Race

Immich depends on more than the web-facing process. The database, job coordination, machine-learning service, and mounted media must become reachable with compatible configuration. A container marked running may still be initializing, so an early request can fail even though the stack becomes healthy moments later.

A restart failure report describes Immich losing access to PostgreSQL or Redis after seemingly unrelated compose changes. That account does not establish a product-wide defect, but it illustrates the diagnostic value of matching application connection errors with dependency readiness and restart timing.

Collect timestamped logs from the application and the named dependency from the same restart. Verify DNS resolution, port reachability, health checks, and mount availability inside the container. If automatic retry recovers the service, improve readiness handling; if it never recovers, test configuration and credentials directly.

Persistent State Must Survive Container Replacement

Images and database files stored only in a container writable layer disappear when that container is replaced. Named volumes and bind mounts persist only when the deployment references the same underlying location. A simple restart normally preserves them, but compose edits or path changes can silently select new empty storage.

The ZimaSpace data-path article explains that a visible container path does not reveal the physical storage or failure domain behind it. This is crucial after recreation: an identical internal pathname can point to a different host directory, empty volume, or unavailable network mount.

If Immich presents first-run onboarding, do not create a replacement library immediately. Inspect the effective mounts, volume identifiers, ownership, and database logs, then compare them with the last working deployment. New writes can complicate recovery by creating a second state set beside the missing original one.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Use a Five-Minute Restart Classification

At minute zero, record which containers restarted and whether images or configuration changed. At minute one, check dependency health and mounts. At minute three, repeat one known search and original download. At minute five, decide whether behavior is improving, persistently unavailable, or presenting empty state.

A database-persistence report describes repeated onboarding after compose restarts while the expected host database directory remained empty. It is a single environment, yet it provides a clear failure signature: durable application identity disappearing across restart indicates the database is being written somewhere other than the intended persistent path.

Map improving latency to cold state, connection errors to dependency startup, missing media to mounts, and lost users or albums to database persistence. Preserve logs and the current volume mappings before any change. Escalate to restore only after confirming the original state is unavailable rather than merely disconnected.