[GH-ISSUE #792] Ghost immich app #2319

New Issue

Open

opened 2026-04-23 03:20:06 -05:00 by GiteaMirror · 3 comments

GiteaMirror commented 2026-04-23 03:20:06 -05:00

Owner

Copy Link

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

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-23 03:20:06 -05:00

GiteaMirror commented 2026-04-23 03:20:08 -05:00

Author

Owner

Copy Link

@dosubot[bot] commented on GitHub (Apr 15, 2026):

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}
   

<!-- 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).* --- ^{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)&nbsp;[](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.)&nbsp;[](https://go.dosu.dev/discord-bot?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=join-discord)&nbsp;[](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/Dokploy/dokploy/issues/4227)

GiteaMirror commented 2026-04-23 03:20:09 -05:00

Author

Owner

Copy Link

@finnvyrn commented on GitHub (Apr 15, 2026):

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.

<!-- 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.

GiteaMirror commented 2026-04-23 03:20:09 -05:00

Author

Owner

Copy Link

@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: 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.

---

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

<!-- 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).* --- ^{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)} [](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)&nbsp;[](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.)&nbsp;[](https://go.dosu.dev/discord-bot?utm_source=github&utm_medium=bot-comment&utm_campaign=github-assistant&utm_content=join-discord)&nbsp;[](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/Dokploy/templates/issues/792)

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

canary

dosu/doc-update-3913

dosu/doc-update-730

copilot/add-oneuptime-template

copilot/add-wazuh-template

copilot/add-docling-serve-template

copilot/fix-minio-image-deployment

copilot/initial-pr-setup

feat/update-template

fix/cicd

onetimesecret

No results found.

Labels

Clear labels

bug

documentation

pull-request

Mirrored from GitHub Pull Request

template

No Label bug

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

GiteaMirror ninjasurge

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/templates#2319