#Updating in Docker environment fails

16 messages · Page 1 of 1 (latest)

charred vault
#

I have my openclaw running on a vps in a docker. The last stable version was 3.28. I wanted to update it to 4.11.
Unfortunately, the update fails. Everytime I hit "/status", nothing happens in the telegram chat and I receive the following logs:
openclaw-gateway | 2026-04-13T05:48:36.871+00:00 [telegram] bot error: Error: Cannot find module '/app/dist/commands-status-deps.runtime.js' imported from /app/dist/runtime-import-QDWd4HE-.js

I am using a custom dockerfile and a customized docker-compose.yml.
I assume I have to change one or both of them, but I dont know where to start debugging.

Can you help me?

tired lichenBOT
gray flintBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

tired lichenBOT
lethal quiverBOT
#

Let me check the local docs and image layout, this smells like a packaging mismatch in the custom container rather than a Telegram-specific problem.

#

Yep. This looks much more like a broken/custom image build than a Telegram problem.

/status now lazy-loads extra runtime files from /app/dist, and your container is missing one of them. In the official Docker flow, the whole dist/ tree is built and copied, not just dist/index.js.

Most likely causes:

  1. your custom Dockerfile copies only part of dist/
  2. it runs a custom build step instead of the official one
  3. your compose file mounts over /app or /app/dist
  4. you rebuilt on top of stale artifacts

Two quick checks first:

docker compose exec openclaw-gateway sh -lc 'node -e "console.log(require(\"/app/package.json\").version)"'
docker compose exec openclaw-gateway sh -lc 'ls -1 /app/dist | sort | egrep "status|runtime-import|deps\\.runtime"'
#

If the image is correct, you should see a file like:

status.scan.deps.runtime.js

If that is missing, the build is incomplete.

What I’d recommend:

  • Best fix: base your custom image on the official one:

    FROM ghcr.io/openclaw/openclaw:2026.4.11
    

    then add only your extra packages/tools.

  • If you must build from source, match the official Dockerfile and use the official build flow, especially:

#
  • pnpm build:docker

    • copy the entire /app/dist directory into the runtime image
  • In docker-compose.yml, do not mount:

    • /app
    • /app/dist
    • /app/node_modules

    Only persist the OpenClaw data dirs, like the docs show under /home/node/.openclaw.

Docs:

If you paste your Dockerfile and the openclaw-gateway service from docker-compose.yml, I can probably point at the exact line that’s breaking it.

alpine terrace
lethal quiverBOT
#

Yep, if they are using the stock GHCR image and not overriding /app, that should be enough.

The part that makes me suspicious is this error:

Cannot find module '/app/dist/commands-status-deps.runtime.js'

That usually means one of these is true:

  • they are not actually running the stock GHCR image
  • they have a bind mount over /app or /app/dist
  • they rebuilt a custom image that copied an incomplete dist/
  • they are still starting an old cached image

So the split is basically:

#
  • GHCR image only → update tag, docker compose pull, recreate container
  • custom Dockerfile / /app mounts → that custom setup is the first thing to inspect

If they paste the openclaw-gateway service from compose, it should be pretty easy to tell which camp they’re in.

Docs: https://docs.openclaw.ai/install/docker

charred vault
lethal quiverBOT
#

It can, but probably not because of the COPY line by itself.

COPY --from=nodebuild /app /app basically says, “whatever ended up in /app in the build stage, ship all of it”. So the real question is:

what exactly happened in nodebuild before that copy?

If that stage produced a mismatched or partial dist/, the final image will keep that broken state.

For this error, the likely problem is one of these:

  • nodebuild did not run the full official build flow
  • dist/ contains a stale mix of old and new files
  • the build stage produced one runtime layout, but the final container is executing another

So yes, this pattern can absolutely carry the problem forward, even if it doesn’t create it by itself.

What I’d check next:

#
docker compose exec openclaw-gateway sh -lc 'node -e "console.log(require(\"/app/package.json\").version)"; ls -1 /app/dist | sort | egrep "commands-status|status\\.scan|runtime-import"'

And in the Dockerfile, show the whole nodebuild stage, especially the lines around:

  • pnpm install
  • pnpm build / pnpm build:docker
  • pnpm ui:build

My hunch: the fix is to make the build stage match the official Dockerfile more closely, or just extend the GHCR image instead of copying a self-built /app.
Docs: https://docs.openclaw.ai/install/docker

charred vault
lethal quiverBOT
#

Those build lines actually look mostly fine.

So I’d say the problem is probably not pnpm build:docker itself. The next suspects are:

  1. the final image/container is stale
  2. compose is mounting over /app or /app/dist
  3. the running container is not the image you think it is
  4. your final runtime stage drifted from the official one enough to create a mixed dist/

What stands out to me is the filename mismatch. That usually means the runtime loader file and the rest of dist/ are not from the same build.

So I’d check these next:

docker compose exec openclaw-gateway sh -lc 'node -e "console.log(require(\"/app/package.json\").version)"; ls -1 /app/dist | sort | egrep "commands-status|status\\.scan|runtime-import"'
docker compose config