DSH Toolbox

DeepSeek Harness in Docker

There is no official DSH image: build one from node:24-slim, install @deepseek-ai/dsh, and publish port 8080 from dsh web.

DSH needs Node.js 24.9.0 or newer, so the base image is node:24-slim rather than an older tag. Everything else is one npm install and one command.

The one trap is binding: --host refuses wildcard addresses, so a container that runs --host 0.0.0.0 will not start. Resolve the container interface at boot instead.

Dockerfile

Sessions live in $DSH_HOME, which defaults to ~/.dsh — inside the container that is /root/.dsh. Mount it, or every rebuild loses the session list.

FROM node:24-slim
RUN npm install -g @deepseek-ai/dsh
WORKDIR /work
EXPOSE 8080
CMD ["sh", "-c", "dsh web --port 8080 --no-open --host $(hostname -i)"]

Build and run

Two volumes: dsh-home keeps sessions between runs, and the current directory is mounted as the workspace so the agent sees your project.

docker build -t dsh-web .
docker run --rm -p 8080:8080 -v dsh-home:/root/.dsh -v "$PWD:/work" dsh-web

Why not --host 0.0.0.0

--host takes one concrete IPv4 or IPv6 literal of a local interface and rejects wildcard addresses. In a container the interface address is not known when you write the command, so pass $(hostname -i) and let the shell resolve it at start-up.

If you need TLS, mount the PEM chain and key and add --tls-cert and --tls-key; both flags must be given together.

Common questions

Is there an official DeepSeek Harness Docker image?

Not from the published packages we checked. The Dockerfile here builds from node:24-slim and installs @deepseek-ai/dsh from npm.

Why does the container exit immediately?

Most often the host flag: --host 0.0.0.0 is rejected by design. Use the container interface address, or $(hostname -i) as above.

Where do sessions go after a rebuild?

They stay if you mount a volume at /root/.dsh, which is $DSH_HOME inside the container. Without the volume they go away with the container.

Related