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
Originally created by @finnvyrn on GitHub (Apr 15, 2026).
Original GitHub issue: https://github.com/Dokploy/templates/issues/792
### 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
```bash
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
GiteaMirror
added the bug label 2026-04-20 10:42:34 -05:00
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:
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.
<!-- gh-comment-id:4252951019 -->
@dosubot[bot] commented on GitHub (Apr 15, 2026):
<!-- Answer -->
This happens because Dokploy uses `docker compose stop` to stop compose applications [[1]](https://github.com/Dokploy/dokploy/blob/ddff8b9de767213700c10ece2975cb319b8deaaf/packages/server/src/services/compose.ts), 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]](https://github.com/Dokploy/dokploy/issues/4019).
**Workaround:** After stopping the app in Dokploy, you can manually prevent the auto-restart by running:
```bash
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.
<!-- Dosu Comment Footer -->
*To reply, just mention [@dosu](https://go.dosu.dev/dosubot?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=brand-link).*
---
<sup>How did I do? [Good](https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-great_response#message_id=a90051b6-5bb0-4397-8c3e-2a3ef622b403&feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-irrelevant_answer#message_id=a90051b6-5bb0-4397-8c3e-2a3ef622b403&feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-incorrect_sources#message_id=a90051b6-5bb0-4397-8c3e-2a3ef622b403&feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-too_verbose#message_id=a90051b6-5bb0-4397-8c3e-2a3ef622b403&feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-hallucination#message_id=a90051b6-5bb0-4397-8c3e-2a3ef622b403&feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-bug_report#message_id=a90051b6-5bb0-4397-8c3e-2a3ef622b403&feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-other#message_id=a90051b6-5bb0-4397-8c3e-2a3ef622b403&feedback_type=other)</sup>
[](https://app.dosu.dev/6bf07378-6531-485c-acb5-f8edab4b0c01/ask?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=chat-badge) [](https://cursor.com/link/prompt?text=This%20happens%20because%20Dokploy%20uses%20%60docker%20compose%20stop%60%20to%20stop%20compose%20applications%20%5B%5B1%5D%5D%28https%3A//github.com/Dokploy/dokploy/blob/ddff8b9de767213700c10ece2975cb319b8deaaf/packages/server/src/services/compose.ts%29%2C%20which%20only%20pauses%20containers%20%2A%2Awithout%20removing%20them%20or%20their%20restart%20policies%2A%2A.%20Since%20templates%20like%20Immich%20include%20%60restart%3A%20always%60%20or%20%60restart%3A%20unless-stopped%60%20in%20their%20compose%20files%2C%20Docker%20dutifully%20restarts%20those%20containers%20after%20a%20host%20reboot%20%E2%80%94%20even%20though%20Dokploy%20considers%20the%20app%20stopped.%0A%0AThere%27s%20a%20related%20issue%20in%20%234019%20about%20orphan%20containers%20persisting%20after%20compose%20redeployments%20due%20to%20the%20same%20underlying%20cause%20%5B%5B2%5D%5D%28https%3A//github.com/Dokploy/dokploy/issues/4019%29.%0A%0A%2A%2AWorkaround%3A%2A%2A%20After%20stopping%20the%20app%20in%20Dokploy%2C%20you%20can%20manually%20prevent%20the%20auto-restart%20by%20running%3A%0A%0A%60%60%60bash%0Adocker%20update%20--restart%3Dno%20%24%28docker%20compose%20-p%20%3Cproject-name%3E%20ps%20-q%29%0A%60%60%60%0A%0AOr%20use%20%60docker%20compose%20-p%20%3Cproject-name%3E%20down%60%20directly%20to%20remove%20the%20containers%20entirely%20%28they%27ll%20be%20recreated%20on%20next%20deploy%29.%0A%0AA%20proper%20fix%20would%20likely%20involve%20either%20switching%20the%20stop%20operation%20to%20use%20%60docker%20compose%20down%60%2C%20or%20having%20Dokploy%20set%20%60--restart%3Dno%60%20on%20containers%20when%20stopping%20an%20app.) [](https://go.dosu.dev/discord-bot?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=join-discord) [](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/Dokploy/dokploy/issues/4227)
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:
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.
This is incorrect. Even after setting restart: no to all containers, it still starts after the host boots.
<!-- gh-comment-id:4252951061 -->
@finnvyrn commented on GitHub (Apr 15, 2026):
> This happens because Dokploy uses `docker compose stop` to stop compose applications [[1]](https://github.com/Dokploy/dokploy/blob/ddff8b9de767213700c10ece2975cb319b8deaaf/packages/server/src/services/compose.ts), 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](https://github.com/Dokploy/dokploy/issues/4019) about orphan containers persisting after compose redeployments due to the same underlying cause [[2]](https://github.com/Dokploy/dokploy/issues/4019).
>
> **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](https://go.dosu.dev/dosubot?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=brand-link)._
>
> How did I do? [Good](https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-great_response#message_id=a90051b6-5bb0-4397-8c3e-2a3ef622b403&feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-irrelevant_answer#message_id=a90051b6-5bb0-4397-8c3e-2a3ef622b403&feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-incorrect_sources#message_id=a90051b6-5bb0-4397-8c3e-2a3ef622b403&feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-too_verbose#message_id=a90051b6-5bb0-4397-8c3e-2a3ef622b403&feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-hallucination#message_id=a90051b6-5bb0-4397-8c3e-2a3ef622b403&feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-bug_report#message_id=a90051b6-5bb0-4397-8c3e-2a3ef622b403&feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-other#message_id=a90051b6-5bb0-4397-8c3e-2a3ef622b403&feedback_type=other) [](https://app.dosu.dev/6bf07378-6531-485c-acb5-f8edab4b0c01/ask?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=chat-badge) [](https://cursor.com/link/prompt?text=This%20happens%20because%20Dokploy%20uses%20%60docker%20compose%20stop%60%20to%20stop%20compose%20applications%20%5B%5B1%5D%5D%28https%3A//github.com/Dokploy/dokploy/blob/ddff8b9de767213700c10ece2975cb319b8deaaf/packages/server/src/services/compose.ts%29%2C%20which%20only%20pauses%20containers%20%2A%2Awithout%20removing%20them%20or%20their%20restart%20policies%2A%2A.%20Since%20templates%20like%20Immich%20include%20%60restart%3A%20always%60%20or%20%60restart%3A%20unless-stopped%60%20in%20their%20compose%20files%2C%20Docker%20dutifully%20restarts%20those%20containers%20after%20a%20host%20reboot%20%E2%80%94%20even%20though%20Dokploy%20considers%20the%20app%20stopped.%0A%0AThere%27s%20a%20related%20issue%20in%20%234019%20about%20orphan%20containers%20persisting%20after%20compose%20redeployments%20due%20to%20the%20same%20underlying%20cause%20%5B%5B2%5D%5D%28https%3A//github.com/Dokploy/dokploy/issues/4019%29.%0A%0A%2A%2AWorkaround%3A%2A%2A%20After%20stopping%20the%20app%20in%20Dokploy%2C%20you%20can%20manually%20prevent%20the%20auto-restart%20by%20running%3A%0A%0A%60%60%60bash%0Adocker%20update%20--restart%3Dno%20%24%28docker%20compose%20-p%20%3Cproject-name%3E%20ps%20-q%29%0A%60%60%60%0A%0AOr%20use%20%60docker%20compose%20-p%20%3Cproject-name%3E%20down%60%20directly%20to%20remove%20the%20containers%20entirely%20%28they%27ll%20be%20recreated%20on%20next%20deploy%29.%0A%0AA%20proper%20fix%20would%20likely%20involve%20either%20switching%20the%20stop%20operation%20to%20use%20%60docker%20compose%20down%60%2C%20or%20having%20Dokploy%20set%20%60--restart%3Dno%60%20on%20containers%20when%20stopping%20an%20app.) [](https://go.dosu.dev/discord-bot?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=join-discord) [](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/Dokploy/dokploy/issues/4227)
This is incorrect. Even after setting `restart: no` to all containers, it still starts after the host boots.
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.
<!-- gh-comment-id:4253002669 -->
@dosubot[bot] commented on GitHub (Apr 15, 2026):
<!-- Answer -->
This is the same issue you reported over on [Dokploy/dokploy#4227](https://github.com/Dokploy/dokploy/issues/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]](https://github.com/Dokploy/templates/blob/d157cef3c357550aff801c336b99611813b522ae/blueprints/immich/docker-compose.yml). This is per the [template conventions](https://app.dosu.dev/6bf07378-6531-485c-acb5-f8edab4b0c01/documents/44ea2253-ee24-43ba-9846-021db5e34324) 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]](https://github.com/Dokploy/dokploy/blob/ddff8b9de767213700c10ece2975cb319b8deaaf/packages/server/src/services/compose.ts#L497-L541). 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](https://github.com/Dokploy/dokploy/issues/4019)) where orphaned containers with old restart policies persist across redeployments [[3]](https://github.com/Dokploy/dokploy/issues/4019).
**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.
<!-- Dosu Comment Footer -->
*To reply, just mention [@dosu](https://go.dosu.dev/dosubot?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=brand-link).*
---
<sup>How did I do? [Good](https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-great_response#message_id=9c356407-704f-49e7-9a2d-6c7a79bf12f6&feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-irrelevant_answer#message_id=9c356407-704f-49e7-9a2d-6c7a79bf12f6&feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-incorrect_sources#message_id=9c356407-704f-49e7-9a2d-6c7a79bf12f6&feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-too_verbose#message_id=9c356407-704f-49e7-9a2d-6c7a79bf12f6&feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-hallucination#message_id=9c356407-704f-49e7-9a2d-6c7a79bf12f6&feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-bug_report#message_id=9c356407-704f-49e7-9a2d-6c7a79bf12f6&feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=feedback-other#message_id=9c356407-704f-49e7-9a2d-6c7a79bf12f6&feedback_type=other)</sup>
[](https://app.dosu.dev/6bf07378-6531-485c-acb5-f8edab4b0c01/ask?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=chat-badge) [](https://cursor.com/link/prompt?text=This%20is%20the%20same%20issue%20you%20reported%20over%20on%20%5BDokploy/dokploy%234227%5D%28https%3A//github.com/Dokploy/dokploy/issues/4227%29%2C%20so%20the%20root%20cause%20and%20fix%20live%20on%20the%20Dokploy%20side%20rather%20than%20in%20this%20templates%20repo.%0A%0AThat%20said%2C%20from%20the%20templates%20perspective%3A%20the%20Immich%20template%20sets%20%60restart%3A%20always%60%20on%20all%20four%20services%20%5B%5B1%5D%5D%28https%3A//github.com/Dokploy/templates/blob/d157cef3c357550aff801c336b99611813b522ae/blueprints/immich/docker-compose.yml%29.%20This%20is%20per%20the%20%5Btemplate%20conventions%5D%28https%3A//app.dosu.dev/6bf07378-6531-485c-acb5-f8edab4b0c01/documents/44ea2253-ee24-43ba-9846-021db5e34324%29%20which%20require%20%60restart%3A%20unless-stopped%60%20or%20%60restart%3A%20always%60.%20When%20Dokploy%20stops%20a%20compose%20app%20it%20runs%20%60docker%20compose%20stop%60%2C%20which%20only%20pauses%20containers%20%2A%2Awithout%20removing%20them%20or%20their%20restart%20policies%2A%2A%20%5B%5B2%5D%5D%28https%3A//github.com/Dokploy/dokploy/blob/ddff8b9de767213700c10ece2975cb319b8deaaf/packages/server/src/services/compose.ts%23L497-L541%29.%20So%20after%20a%20host%20reboot%2C%20Docker%20sees%20the%20stopped%20containers%20still%20carrying%20%60restart%3A%20always%60%20and%20brings%20them%20back%20up%20%E2%80%94%20regardless%20of%20what%20Dokploy%27s%20UI%20shows.%0A%0ARegarding%20your%20finding%20that%20%60docker%20update%20--restart%3Dno%60%20didn%27t%20help%20either%20%E2%80%94%20that%27s%20likely%20because%20any%20subsequent%20Dokploy%20compose%20operation%20%28redeploy%2C%20config%20change%2C%20etc.%29%20re-reads%20the%20compose%20file%20and%20reapplies%20%60restart%3A%20always%60%2C%20overwriting%20the%20manual%20change.%20There%27s%20also%20a%20related%20issue%20%28%5B%234019%5D%28https%3A//github.com/Dokploy/dokploy/issues/4019%29%29%20where%20orphaned%20containers%20with%20old%20restart%20policies%20persist%20across%20redeployments%20%5B%5B3%5D%5D%28https%3A//github.com/Dokploy/dokploy/issues/4019%29.%0A%0A%2A%2AWorkaround%3A%2A%2A%20Use%20%60docker%20compose%20-p%20%3Cproject-name%3E%20down%60%20to%20fully%20remove%20the%20containers%20%28they%27ll%20be%20recreated%20on%20next%20deploy%29.%20This%20is%20more%20reliable%20than%20%60docker%20update%20--restart%3Dno%60%20since%20there%20are%20no%20containers%20left%20for%20Docker%20to%20restart.%0A%0AThe%20proper%20fix%20needs%20to%20happen%20in%20Dokploy%20core%20%E2%80%94%20either%20by%20switching%20the%20stop%20operation%20to%20%60docker%20compose%20down%60%2C%20or%20by%20having%20Dokploy%20set%20%60--restart%3Dno%60%20on%20containers%20as%20part%20of%20its%20stop%20flow.) [](https://go.dosu.dev/discord-bot?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=join-discord) [](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/Dokploy/templates/issues/792)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @finnvyrn on GitHub (Apr 15, 2026).
Original GitHub issue: https://github.com/Dokploy/templates/issues/792
To Reproduce
Current vs. Expected behavior
Current: Immich's containers auto starts after host reboot, despite Dokploy shows Immich is not running.
Provide environment information
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[bot] commented on GitHub (Apr 15, 2026):
This happens because Dokploy uses
docker compose stopto stop compose applications [1], which only pauses containers without removing them or their restart policies. Since templates like Immich includerestart: alwaysorrestart: unless-stoppedin 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:
Or use
docker compose -p <project-name> downdirectly 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=noon containers when stopping an app.To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
@finnvyrn commented on GitHub (Apr 15, 2026):
This is incorrect. Even after setting
restart: noto all containers, it still starts after the host boots.@dosubot[bot] commented on GitHub (Apr 15, 2026):
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: alwayson all four services [1]. This is per the template conventions which requirerestart: unless-stoppedorrestart: always. When Dokploy stops a compose app it runsdocker 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 carryingrestart: alwaysand brings them back up — regardless of what Dokploy's UI shows.Regarding your finding that
docker update --restart=nodidn't help either — that's likely because any subsequent Dokploy compose operation (redeploy, config change, etc.) re-reads the compose file and reappliesrestart: 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> downto fully remove the containers (they'll be recreated on next deploy). This is more reliable thandocker update --restart=nosince 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=noon containers as part of its stop flow.To reply, just mention @dosu.
How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other
