Skip to content
zhming0Public

About

Always-on DeepSeek Harness for the web, one sandbox for each session. 🥱

Topics

Resources

Stars

3 stars

Watchers

0 watching

Forks

Repository files navigation

DeepSeek Harness Yawn

Project logo

Always-on DeepSeek Harness for the web.
A self-hosted distribution: deploy it once, open it from any browser, and every session runs in its own sandbox.

A task sent from a laptop runs in its own sandbox behind an always-on control plane. The laptop closes and the work continues. The idle sandbox sleeps and keeps its files, then wakes when a phone sends the next message.

Why

DeepSeek Harness is a great harness, but it assumes it runs on your laptop: every session shares your operating system, so you have to watch what the agents do, keep the machine awake, and live with the scale of one machine. DSH Yawn splits dsh in two: the harness itself runs on a server you keep on, and everything the agent does runs in a sandbox of its own. Hence the name: you can lay back and yawn :)

dsh on your laptop DSH Yawn
dsh itself (Web UI, sessions, model calls) your laptop an always-on server: a VM or a Kubernetes cluster
The agent's work (shell commands, file edits) your laptop a sandbox per session: a Docker container, a Kubernetes pod, or a Buildkite build
Where you open it that laptop any browser, after signing in
Many sessions at once share one OS, CPU, and disk one sandbox each, on your VM, cluster, or Buildkite agents
Starting on a repository your local checkout paste a URL; the sandbox clones it and runs .agents/setup
Secrets your shell environment a store on the server, pushed to a sandbox before commands

What's in the distribution

  • Control-plane and runner images, released and tested together, and a Helm chart.
  • dsh's Web UI, with its file, shell, and search tools running in the session's sandbox.
  • Sandbox backends: Docker, Kubernetes agent-sandbox with warm pools, and Buildkite.
  • Sign-in with a built-in passcode, or OIDC through the identity provider you configure in the Helm chart.
  • Web UI pages for sandbox profiles and idle timers, secrets, AGENTS.md instructions, notifications, MCP servers, and plugins, applied without a restart.
  • In every session: a Sandbox tab, a file browser, and a terminal.
  • Previews: a dev server in a sandbox gets its own URL.

Requirements

  • An always-on place for the control plane: a VM with Docker, or a Kubernetes cluster through the Helm chart.
  • The ability to expose it under a domain name, on the internet or your LAN.
  • Somewhere to run sandboxes: Docker on the same VM, a Kubernetes cluster with agent-sandbox, or a Buildkite organization.
  • Sign-in for the Web UI: a passcode, or OIDC with your identity provider.
  • A model API key, added in the Web UI.
  • Optional: a GITHUB_TOKEN, or Git credentials for another host, for private repositories and pushes.

Setup: docs/installations.md.

Quick start

This runs the control plane in Docker and starts each session's sandbox as a sibling container: the whole install on one machine. The same shape works on a VM.

export DSH_YAWN_PASSCODE="$(openssl rand -base64 18)"
printf 'passcode: %s\n' "$DSH_YAWN_PASSCODE"

docker run -d --name dsh-yawn \
  -p 127.0.0.1:3000:3000 -p 8081:8081 \
  -e DSH_YAWN_BIND_ALL=1 \
  -e DSH_YAWN_PASSCODE \
  -v dsh-yawn-data:/data \
  -v /var/run/docker.sock:/var/run/docker.sock \
  ghcr.io/zhming0/dsh-yawn-control-plane
  1. Open http://localhost:3000/ and enter the passcode printed above.
  2. Settings → Sandboxes → New profile: name: standard, backend: docker.
  3. Add a model credential in the Web UI settings.
  4. Send a message in the Scratch workspace, whose sessions start in an empty sandbox, or use New session → Add workspace… with a repository URL.

To clean up: docker rm -f dsh-yawn. What each flag does is in the FAQ.

Documentation

Page Covers
docs/installations.md installation index: control plane, runner, credentials
docs/control-plane.md the control plane on Kubernetes (Helm chart) or on a VM with Docker
docs/credentials.md the secret store: GITHUB_TOKEN and other Git hosts, the Web UI, control-plane credentials
docs/runners/kubernetes.md sandboxes as Kubernetes pods: install, security model, what survives a wake
docs/runners/buildkite.md sandboxes as Buildkite builds: pipeline, idle checkpoints, limits
docs/faq.md sign-in, sandbox lifecycle, the runner tunnel, plugins
control-plane/README.md what the bundle patch changes, every setting, secret handling
docs/development.md repository layout, build and test, checkout installs, releasing

About

Always-on DeepSeek Harness for the web, one sandbox for each session. 🥱

Topics

Resources

Stars

3 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages