When managing gPhotos2Immich entirely via containers (Docker Compose / Podman Quadlets), updating the Immich API key or URL via environment variables (or an .env file) after the initial setup has no effect. The application permanently prefers the values written to the persistent config.json file. If Immich rotates keys (like the recent v3.0 breaking change) and the user updates their container manifest, the container silently crash-loops with a 401 Unauthorized until they realize they have to manually exec in or locate the volume to modify config.json.
I'm thinking of a few ways to fix this by implementing a quick validation/sync check during the container's initialization phase:
Option A (Sync): If an environment variable like IMMICH_API_KEY is present at startup in the docker compose, check if it matches the current value inside config.json. If it doesn't, automatically overwrite the key in config.json with the environment variable's value before spinning up the sync/Web UI engine.
Option B (Precedence): Ensure that runtime environment variables always take precedence over the JSON configuration file, treating the file purely as a fallback.
Whichever one is preferred it should be documented somewhere, probably in the logs, of where it got the API key for that run so people can know where to change the API key once a config.json is already spun up.
I solved the problem by just manually editing the config.json file so that the API key in there from immich 3.x match the new api key in my .env file and restarted the container and it worked.
When managing gPhotos2Immich entirely via containers (Docker Compose / Podman Quadlets), updating the Immich API key or URL via environment variables (or an .env file) after the initial setup has no effect. The application permanently prefers the values written to the persistent config.json file. If Immich rotates keys (like the recent v3.0 breaking change) and the user updates their container manifest, the container silently crash-loops with a 401 Unauthorized until they realize they have to manually exec in or locate the volume to modify config.json.
I'm thinking of a few ways to fix this by implementing a quick validation/sync check during the container's initialization phase:
Option A (Sync): If an environment variable like
IMMICH_API_KEYis present at startup in the docker compose, check if it matches the current value insideconfig.json. If it doesn't, automatically overwrite the key inconfig.jsonwith the environment variable's value before spinning up the sync/Web UI engine.Option B (Precedence): Ensure that runtime environment variables always take precedence over the JSON configuration file, treating the file purely as a fallback.
Whichever one is preferred it should be documented somewhere, probably in the logs, of where it got the API key for that run so people can know where to change the API key once a config.json is already spun up.
I solved the problem by just manually editing the
config.jsonfile so that the API key in there from immich 3.x match the new api key in my .env file and restarted the container and it worked.