Immich Refused: Connection Refused, Login Fails, or It Won't Uninstall
· Updated 18 September 2026 · SparkBox team
You try to log into Immich and get a refused-connection error, or you try to remove a broken Immich install and it says it can't. Both trace back to the same family of problem: something in the container layer — usually the database password, sometimes a stuck container — never made it through correctly.
Rather not hand-debug container env vars at all? SparkBox clears stale environment values on its own and stops containers before removing them, so this class of "refused" error doesn't happen in the first place. See the walkthrough →
The 10-second version: If Immich refuses connections or won't let you log in, it's Postgres — Immich's database — rejecting an empty password that got left behind by an earlier update. If instead a failed or old Immich install refuses to be removed, it's a container stuck in a restart loop that older removal steps couldn't stop. Both have known fixes below.
"Connection refused" or login just fails — Postgres never started
Immich's photo library is backed by a Postgres database. Postgres needs a password to initialize on first run, and it reads that password from an environment file (commonly a .env file next to your compose setup). If that variable is empty for any reason, Postgres refuses to initialize at all — it won't silently start with a blank password. When the database doesn't start, the rest of Immich has nothing to talk to, so you get connection-refused errors, timeouts, or a login screen that never succeeds no matter what you type.
This isn't a typo in your password and it isn't your account. The actual cause is subtler: an update process can leave an empty copy of the password sitting in memory, and when the container starts back up, that leftover empty value wins over the correct value in your environment file. In other words, your file was right the whole time — a stale in-memory value overrode it.
How to confirm this is what's happening
- Check the logs for the Postgres/database container behind Immich. A message about an empty or missing password, or the database refusing to start, confirms it.
- Check that the value in your environment file for the database password is not blank and matches what Immich's own configuration expects.
- If the file looks correct but the container still won't start cleanly, you're dealing with a stale in-memory value overriding the file — not a typo you made.
How to fix it
- Update your host to at least version v1.6.214 if you're running an older release — from that version on, stale in-memory copies of environment values are cleared automatically before containers restart.
- After updating, run the startup command once:
sudo sparkbox up - Do not run
sparkbox updateagain as a next step — that is the specific command that emptied the password in the first place. Running it a second time just re-triggers the same problem. - Let Postgres come back up on its own after the clean start. It should read the real password from your environment file this time and initialize normally.
Why "just retyping the password" doesn't help: The password stored in your account and the password Postgres expects at container startup are two different things. If Postgres never finished initializing because it got an empty value, no amount of retyping your login password fixes it — the database itself has to actually start.
A failed or broken Immich install won't uninstall
Sometimes an Immich install fails partway through — maybe an image pull was interrupted, or a dependency container never came up. What's left behind is a container that keeps restarting itself in a loop, over and over, without ever settling. When you then try to remove that failed app, the removal step tries to delete a container that's actively running (mid-restart), and the deletion is rejected. The tool reports that it "could not remove the container," which is confusing when you're specifically trying to get rid of something broken.
This has been fixed at the removal-tool level: since v1.6.336, removal stops the container first and then deletes it, instead of trying to delete a container that's still actively restarting.
How to fix it
- Update to v1.6.336 or later if you haven't already — this changes the order of operations during removal so it works even on a restart-looping container.
- Retry the removal. It should now stop the container first, then remove it cleanly.
- If you're on an older version and can't update immediately, manually stop the specific container before attempting removal through your normal container tool, then remove it once it's stopped.
Related but separate: The same release that fixed this removal order also changed how Calibre-Web handles a first-run folder with no metadata file — it now creates an empty library instead of rejecting the folder outright. If you're seeing odd first-run behavior in other apps alongside a stuck Immich removal, you're likely on the same pre-fix version across the board and a single update resolves both.
Putting it together: which one am I hitting?
- If Immich is installed, running, and you simply can't log in or every page times out with a refused connection — this is the Postgres empty-password issue. Check your host version and update if needed.
- If you're trying to delete a broken or failed Immich install and the removal itself fails with a message about not being able to remove the container — this is the restart-loop removal issue. Update to v1.6.336 or later, or stop the container manually first.
- Either way, avoid running an update command a second time as a troubleshooting step for the password issue specifically — it's the trigger, not the cure.
Frequently asked
Why does Immich say connection refused on login?
Almost always because the Immich database (Postgres) never actually started. If Postgres received an empty password on startup, it refuses to initialize, so the app behind it can't reach the database and login requests get refused.
Is my Immich password wrong if login gets refused?
No. This is not a wrong-password problem on your account. It's the database container's own password, set in an environment file, that arrived empty. Your login credentials are unaffected once the database is running again.
Why can't I remove a stuck or failed Immich install?
A failed install can leave a container that keeps restarting itself in a loop. Older removal tools tried to delete the container while it was still running and restarting, which failed. The fix is to stop the container first, then remove it.
Do I need to reset my Immich password after this fix?
No. Once the correct password from your environment file is actually passed through to Postgres and the database starts cleanly, your existing password works as before.
Skip the environment-file archaeology
SparkBox clears stale in-memory values automatically and stops containers cleanly before removing them, so "refused" errors from a broken password or a stuck restart loop don't happen in the first place.
Questions, or did this not match your box?
Every guide here came from a real problem someone hit. If yours behaves differently, say so — that is how these get corrected, and how the fix gets prioritised.
We answer there rather than in a comment box, because that is where the people who have already solved it are.