Dockerode-over-SSH service creation fails, while equivalent manual docker service create works on the same host

[eddiespotfav]

Summary

I am using Dokploy programmatically from OpenClaw to deploy an application on the same machine where Dokploy is running.

After debugging several earlier issues (server binding, SSH reachability, serverId persistence, permissions, Docker access), I isolated a new problem:

• Dokploy's deployment flow still fails with:
  • Remote command failed with exit code 1
• but the equivalent manual Docker Swarm service creation works on the same host, with the same image, port, env vars, and network.

This suggests the issue is now specifically in Dokploy's Dockerode-over-SSH service creation path, not in the application itself.

---

Context

I already validated all of the following:

• SSH connectivity from Dokploy to the target host works
• host uses real LAN IP instead of 127.0.0.1
• serverId is correctly set at application.create
• buildServerId is correctly set
• remote clone works
• remote .env file creation works
• remote Docker build works
• Docker access for the remote user works
• a Dokploy application port record exists
• dokploy-network exists on the host

So the app/runtime is valid and deployable.

---

What fails in Dokploy

Dokploy deployment still ends with:

An error have occured: Remote command failed with exit code 1

The deployment record has no useful log path/body in this failure mode.

---

What works manually

On the same host, I can manually do the following successfully:

1. clone the repo to:
   /etc/dokploy/applications/<appName>/code
2. write the .env
3. build the image:
   docker build -t <appName>:latest -f Dockerfile .
4. create the Swarm service manually:

docker service create \
  --name <appName> \
  --network dokploy-network \
  --publish published=3001,target=3001,protocol=tcp,mode=host \
  --env AUTH_SECRET=... \
  --env DATABASE_URL=file:/data/mydestinations.db \
  --env NODE_ENV=development \
  --env HOSTNAME=0.0.0.0 \
  --env PORT=3001 \
  --env NEXT_TELEMETRY_DISABLED=1 \
  <appName>:latest \
  npm run start:prod

This converges successfully, opens port 3001, and the app responds with HTTP 200 on:

• /
• /login
• /setup

---

Why I think the bug is in Dokploy

From the source:

• build happens via remote shell command
• service creation happens later via Dockerode-over-SSH:
  • getRemoteDocker(application.serverId)
  • docker.createService(settings)

Relevant files:

• packages/server/src/utils/builders/index.ts
• packages/server/src/utils/servers/remote-docker.ts

The same service configuration appears to work manually, so the remaining problem seems specific to:

• how Dokploy builds the settings object
• or how Dockerode-over-SSH is executing createService(settings) in this environment

---

Evidence gathered

Working manually

• remote git clone: OK
• remote env file write: OK
• remote docker build: OK
• manual swarm service create: OK
• service converges: OK
• app reachable on published port: OK

Failing in Dokploy

• deployment status: error
• message: Remote command failed with exit code 1
• no useful deployment log body for this stage

---

Suspected area

The issue is likely in one of these:

• Dockerode-over-SSH service creation
• generated CreateServiceOptions object
• mismatch between Dokploy-generated service spec and the working manual docker service create
• swallowed Dockerode error before it is logged back into deployment logs

---

Environment

• Dokploy public repo
• investigated against source commit:
  • 290a03c
• automation/orchestration client:
  • OpenClaw
• deployment target:
  • same host where Dokploy is installed

[dosubot]

Good debugging work — your analysis is close but I think the error message you're seeing points to the build/clone shell phase, not the Dockerode service creation phase. Here's what I found in the source:

"Remote command failed with exit code 1" comes from execAsyncRemote(), not Dockerode. It's thrown in packages/server/src/utils/process/execAsync.ts when the SSH shell command (clone + build script) exits non-zero [1]. The Dockerode createService() path produces a different class of error entirely.

This means something in the shell build pipeline is still failing, even though your manual steps work. A few things to check:

1. Non-root SSH user permissions — This is the most common cause. If the SSH user Dokploy connects with isn't root, /etc/dokploy/ needs the right ownership. Workaround: sudo chown <user>:root -R /etc/dokploy/ [2]. PR feat(servers): enhance server setup and validation for user privileges #4059 (merged 2026-03-24) added non-root SSH user support with sudo validation [3], so make sure you're on the latest.

2. The build command differs from your manual one — Dokploy wraps the clone + build in a single set -e; pipeline and redirects to a log file: (set -e; <clone>; <build>) >> ${logPath} 2>&1. If any command in that pipeline fails (even a cd or mkdir), set -e causes an immediate exit code 1 [4].

3. Check the deployment log file directly — Since the output is redirected to ${deployment.logPath} via >> 2>&1, the actual error should be in that file even if the UI doesn't display it well. Look for the log at the path stored in the deployment record.

That said, you're also right that there are real issues in the Dockerode service creation path — if you get past the shell phase, be aware of:

• getRemoteDocker() silently falls back to the local Docker daemon if server.sshKeyId is null — no warning at all [5]. Verify your server record has sshKeyId populated.
• Errors from service.inspect()/service.update() are swallowed — they're only console.log'd at line 184 in packages/server/src/utils/builders/index.ts and never written to the deployment log [6]. This is a known logging gap.
• The authconfig bug for createService() was partially fixed in PR fix: handle optional authConfig in mechanizeDockerContainer function #4016 (merged 2026-03-17) [7], but service.update() still has the same issue with X-Registry-Auth header propagation.

To narrow this down further: can you check the actual deployment log file on disk (the logPath from the deployment record) and share what's in it? That should contain the stdout/stderr from the shell command that's exiting with code 1.

To reply, just mention @dosu.

---

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

   

[hriztam]

I can help with this issue
@eddiespotfav @dosu