[Bug] Native logs use a stale container ID for Docker Stack services and return "No such container"

To Reproduce

Create a Compose service using Stack as the Compose Type.

Deploy the stack successfully.

Confirm through Docker Swarm that the service task/container is running.

Open the service's Logs page.

Enable the Native switch.

Observe that the logs fail with an error similar to:

Error response from daemon: No such container: aeeb80f5f573

Disable the Native switch.

Observe that the logs work correctly in the non-Native/Swarm mode.

Current vs. Expected behavior

Current behavior

When Native logging is enabled, Dokploy tries to retrieve logs using a container ID that no longer exists or does not correspond to the currently running Swarm task.

The application is running, but the Logs page returns:

Error response from daemon: No such container:

Disabling Native makes the logs work again.

Expected behavior

Native logging should resolve the current runtime container associated with the selected Docker Swarm service/task.

If a task was replaced during a deployment or restart, Dokploy should refresh the container ID instead of continuing to request logs from a stale ID.

Provide environment information

Dokploy version: Version v0.30.0
Deployment type: Docker Compose / Docker Swarm
Compose deployment mode: Stack
Dokploy topology: Dokploy manager with remote production nodes
Application runtime: Quarkus / Java
Number of Swarm nodes: 2

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

Docker Compose

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

Remote server

Additional context

This happens with a Compose service deployed using Stack mode.

The ID displayed in the error does not correspond to the currently running container. This suggests that the Native logs implementation may be retaining or resolving a stale Swarm task/container ID.

Related issue: #5111 reports another problem in the same Logs view affecting container selection in Swarm and Native modes. However, this report describes a different behavior: the selected container does not merely reset—the Native log request is sent using a nonexistent container ID and fails with No such container.

Will you send a PR to fix it?

Maybe, need help

DOK-664

@ThiagoCrepequer

@ThiagoCrepequer I traced the root cause through the code. There are two related issues depending on which log component your Stack service uses.

The core problem: Native mode runs docker container logs on the wrong host

In show-stack.tsx, the getContainersByAppNameMatch query for Native mode correctly passes appType: "stack" [1], which routes to getStackTaskContainers. That function runs docker stack ps + docker inspect to resolve the real, currently-running container ID for each Swarm task [2]. So the dropdown should show a live container ID.

However, the resolved container ID is sliced to 12 characters and then passed to docker container logs --follow <12-char-id> via the WebSocket server [3]. When runType is anything other than "swarm", the WebSocket runs docker container logs — which requires the container to be locally visible to the Docker host being SSH'd into. For Swarm stacks running on a remote worker node, the container doesn't exist on the manager node, which explains your "No such container: aeeb80f5f573" error.

When you disable Native (switching to Swarm mode), it uses docker service logs <service-name> instead [4], and the Swarm manager aggregates logs across all nodes — hence it works.

Second issue in show.tsx (application-level logs)

If your stack is rendered via the application logs component (show.tsx) rather than show-stack.tsx, there's an additional bug: the getContainersByAppNameMatch query doesn't pass appType at all [5]:

api.docker.getContainersByAppNameMatch.useQuery({
  appName,
  serverId,
  // ❌ no appType: "stack"
})

Without appType, the function falls through to the docker ps -a | grep <appName> path [6] instead of getStackTaskContainers. For a Swarm task whose container name is <stack>_<service>.<n>.<task-id>, the grep may match an old, stopped container from a previous deployment, returning a stale ID.

What needs fixing

For remote Swarm nodes: Native mode (docker container logs) fundamentally cannot work for containers running on a different Swarm node than the one being SSH'd into. The fix is either to disable Native mode for remote Stack services, or to SSH into the correct worker node. The node information is already available from getStackTaskContainers via the node field [7].
For show.tsx: Add appType: "stack" to the getContainersByAppNameMatch query when the compose type is Stack, so it uses the correct container resolution path.
For the WebSocket layer: The runType sent for Native mode in a Stack deployment is not "swarm", so it builds a docker container logs command. This should either use "swarm" mode (service-level logs via the manager) or route the SSH connection to the specific worker node hosting the task.

Happy to help sketch out a more detailed patch if you want to move forward with a PR.

To reply, just mention @dosu.

Docs are dead. Just use Dosu.

I'm also coming across this. In order to reproduce, I have a database service with the filter node.hostname == swarm-worker and an API service that interacts with that database. The stack deploys successfully but since the database is on the worker, and I cannot see the logs, Dokploy thinks it is not there, which also prevents the backups feature from working.

In the screenshot above, the services on the node "limae" are not detected and so cannot be backed up

fix: keep native log container id in sync when Swarm/compose replaces it

chore(release): 0.42.0 [skip ci]

chore: rebase fork onto Dokploy v0.30.10 (#9)

Navigation Menu

Repository navigation

[Bug] Native logs use a stale container ID for Docker Stack services and return "No such container" #5134

To Reproduce

Current vs. Expected behavior

Current behavior

Expected behavior

Provide environment information

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

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

Additional context

Will you send a PR to fix it?

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug] Native logs use a stale container ID for Docker Stack services and return "No such container" #5134

Description

To Reproduce

Current vs. Expected behavior

Current behavior

Expected behavior

Provide environment information

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

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

Additional context

Will you send a PR to fix it?

Activity

linear-code commented on Aug 19, 2026

dosubot commented on Aug 19, 2026

selipso commented on Aug 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions