DeepSeek Harness in Docker: image, ports and data

Running DeepSeek Harness in a container is half startup and half persistence. Sessions, plugins, and configuration live under DSH_HOME; without a volume, a rebuild resets everything.

Three things a container loses

Three kinds of data decide how much configuration you repeat.

All three sit under DSH_HOME. Mount the right directory and all three survive; mount only sessions and plugin configuration still disappears.

Do not store data on a container path. Container paths disappear with the container; mounts must point to host directories or named volumes.

Mounting the volume

The core container action; path consistency matters.

1. Prepare a host directory, such as ~/dsh-data.
2. Mount it to DSH_HOME when starting the container.
3. Set the environment variable so DSH uses the same path.
4. After startup, confirm sessions and config subdirectories appear.
5. Reuse the same mount on rebuild to restore data.

Paths must match. If the environment variable points at A and the volume mounts at B, data writes to a temporary container path and the volume appears useless.

Named volumes work too. Bind mounts are easier to inspect and back up; named volumes are managed by Docker and need export commands when migrating. Confirm the directory is writable on first start; otherwise DSH may start but fail to persist.

Ports and access

Port mapping defines who can reach the service.

1. The service listens on a container port mapped to a host port.
2. Prefer mapping to 127.0.0.1 for local-only access.
3. For LAN access, evaluate authentication and source limits first.
4. Public access needs a reverse proxy, TLS, and authentication.
5. Do not use 0.0.0.0 for convenience; it widens exposure.

Port mapping is not authentication. Reachability is not permission; authentication belongs to the service or proxy layer. Container networking differs from the host; when 127.0.0.1 cannot reach the container, check mapping and listen address instead of changing service config randomly.

Plugin persistence

Plugins install into a profile, and profiles live under DSH_HOME.

1. Confirm plugins installed into the profile under the mounted directory.
2. Verify with dsh plugin --profile web list.
3. Rebuild and verify again.
4. Keep plugin configuration and keys under DSH_HOME too.
5. Migrate by copying the whole directory, not just plugin packages.

"Plugin present but config gone" usually means config wrote elsewhere. Check paths and environment variables. Plugins still need network access inside the container; verify registry reachability.

Rebuild order

Rebuilding is not delete and start; order prevents loss.

1. Stop the old container and confirm no writes are in progress.
2. Back up the mounted directory for rollback.
3. Start the new container with the same mount and DSH_HOME.
4. Check sessions, plugins, and configuration.
5. Remove the old container and image only after verification.

Back up before rebuilding, and record versions. A wrong volume configuration leaves only the backup as a fallback. Image tag, DSH version, and plugin list help return to the previous combination.

Four failures

Four failure classes dominate containers.

1. Data lost after rebuild: volume missing or wrong path; compare environment variable and mount.
2. Plugins disappear: installed into a container path; confirm the profile is under the mount.
3. Port unreachable: mapping or listen address; curl locally first.
4. Permission errors: container user cannot write the mount; adjust permissions or user.

The common entry is "inspect paths inside the container." Looking only at the host cannot confirm where data went. Keep container logs before deleting.

Security prerequisites

Containers add isolation and a new exposure surface.

1. Trusted images: official or self-built; avoid unknown bundles.
2. Minimal ports: map only what is needed, preferably localhost.
3. No keys in images: inject through environment variables or mounted config.
4. Tight plugin permissions: containers do not justify loosening least privilege.
5. Regular updates: base image and DSH both need security updates.

Isolation is not security. Containers limit impact but do not replace authentication, permissions, and source verification.

Next steps

Mount the volume before ports and plugins. For the three container install methods, read How to install DeepSeek Harness in Docker. For Linux, read Running DeepSeek Harness desktop on Linux. For remote security, read How to configure remote access.

Sources: DeepSeek Harness docs, dsh CLI README, deepseek-harness repository