Ghost immich app

[finnvyrn]

To Reproduce

1. Start immich using the template
2. Stop it and disable autodeploy
3. Reboot the host
4. Go to Dokploy -> Immich app -> Monitoring -> Although the app is grey (not running) and there is no "stop" button, its containers are running and eating resources.

Current vs. Expected behavior

Current: Immich's containers auto starts after host reboot, despite Dokploy shows Immich is not running.

Provide environment information

OS: Arch Linux x86_64
Kernel: Linux 6.19.12-1-cachyos
Dokploy: 0.28.8
Docker version 29.4.0, build 9d7ad9ff18

Which area(s) are affected? (Select all that apply)

Application

Are you deploying the applications where Dokploy is installed or on a remote server?

Same server where Dokploy is installed

Additional context

No response

Will you send a PR to fix it?

No

[dosubot]

This happens because Dokploy uses docker compose stop to stop compose applications [1], which only pauses containers without removing them or their restart policies. Since templates like Immich include restart: always or restart: unless-stopped in their compose files, Docker dutifully restarts those containers after a host reboot — even though Dokploy considers the app stopped.

There's a related issue in Dokploy/dokploy#4019 about orphan containers persisting after compose redeployments due to the same underlying cause [2].

Workaround: After stopping the app in Dokploy, you can manually prevent the auto-restart by running:

docker update --restart=no $(docker compose -p <project-name> ps -q)

Or use docker compose -p <project-name> down directly to remove the containers entirely (they'll be recreated on next deploy).

A proper fix would likely involve either switching the stop operation to use docker compose down, or having Dokploy set --restart=no on containers when stopping an app.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}
   

[finnvyrn]

This happens because Dokploy uses docker compose stop to stop compose applications [1], which only pauses containers without removing them or their restart policies. Since templates like Immich include restart: always or restart: unless-stopped in their compose files, Docker dutifully restarts those containers after a host reboot — even though Dokploy considers the app stopped.

There's a related issue in #4019 about orphan containers persisting after compose redeployments due to the same underlying cause [2].

Workaround: After stopping the app in Dokploy, you can manually prevent the auto-restart by running:

docker update --restart=no $(docker compose -p ps -q)

Or use docker compose -p <project-name> down directly to remove the containers entirely (they'll be recreated on next deploy).

A proper fix would likely involve either switching the stop operation to use docker compose down, or having Dokploy set --restart=no on containers when stopping an app.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

This is incorrect. Even after setting restart: no to all containers, it still starts after the host boots.

[dosubot]

This is the same issue you reported over on Dokploy/dokploy#4227, so the root cause and fix live on the Dokploy side rather than in this templates repo.

That said, from the templates perspective: the Immich template sets restart: always on all four services [1]. This is per the template conventions which require restart: unless-stopped or restart: always. When Dokploy stops a compose app it runs docker compose stop, which only pauses containers without removing them or their restart policies [2]. So after a host reboot, Docker sees the stopped containers still carrying restart: always and brings them back up — regardless of what Dokploy's UI shows.

Regarding your finding that docker update --restart=no didn't help either — that's likely because any subsequent Dokploy compose operation (redeploy, config change, etc.) re-reads the compose file and reapplies restart: always, overwriting the manual change. There's also a related issue (#4019) where orphaned containers with old restart policies persist across redeployments [3].

Workaround: Use docker compose -p <project-name> down to fully remove the containers (they'll be recreated on next deploy). This is more reliable than docker update --restart=no since there are no containers left for Docker to restart.

The proper fix needs to happen in Dokploy core — either by switching the stop operation to docker compose down, or by having Dokploy set --restart=no on containers as part of its stop flow.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.