01
It no longer lives on one machine
dsh runs on a server you own, so closing the laptop does not stop it. Phone, tablet, work computer — any browser gets in, with no environment to install and no files to sync.
Runs on your own serverDEEPSEEK HARNESS · SELF-HOSTEDOpen source · MIT
dshcloud
Your infrastructure.
A workspace for everyone.
Move DeepSeek Harness (dsh) onto a machine you own. You and the people you invite each get a workspace, isolated from each other — open it from a phone, a tablet, or any other computer.
Early development. Built for evaluation and development.
The problems it takes awayAlways runningOpen from anywhereMulti-userUpgrades that keep data
Don't let dsh live on one laptop.
The difference between running dsh locally and running it on a server you own.
02
No two people fighting over one copy
You and the people you invite each get a workspace: its own container, its own /data. You cannot see each other’s, and you cannot break each other’s.
Multi-user03
One person can have several
Split by project or by purpose. Each workspace has its own CPU, memory and disk limits, so they do not crowd each other out.
CPU / Memory / PIDs / Disk04
Upgrading is one image swap
Workspaces, sessions, plugins and configuration stay under /data, so a version change is not a reinstall. A snapshot is taken first, and you can roll back.
Persistent by design02 / TRUST BOUNDARIES
Code can execute. Boundaries still matter.
Agents run shell commands, install dependencies and write files. Every workspace container is treated as an untrusted code execution environment, not an ordinary application process.
- 01Browser
- 02Authentication
- 03Owner check
- 04Instance gate
The ingress comes first
Each workspace has its own container network and data directory, unreachable from the others; ports are published only to the host loopback, never to the LAN. The platform authenticates, checks that you own the workspace, then strips the platform cookie before forwarding — pages, APIs and WebSocket handshakes share the same entry path.
Operations are not file access
Administrators can inspect status and container logs, but the platform provides no browser for user /data. Logs may still contain sensitive content.
Know the limits of isolation
Containers share the host kernel. This is not VM-level isolation. Host or Docker operators can access the underlying storage.
Explicit boundaries, not a promise of absolute security.
Start with your infrastructure.
One command installs it on your own Linux server: platform image, ingress, database and the first administrator, in one pass.
Prerequisites
- Linux host (x86-64 / arm64)
- Docker and Compose v2
- Storage that can enforce a quota (XFS + pquota)
- Ports 80 / 443 free
- Wildcard DNS pointing here
01
Install in one command
Preflight, then the storage pool on the host, PostgreSQL, migrations, and finally the control plane and ingress — ending with a single bootstrap URL. It asks no questions at all.
curl -fsSL https://raw.githubusercontent.com/eskim2001/dshcloud/main/scripts/install.sh \
| bash02
Create the account and domain on that page
Open the printed URL (it carries a one-time token) and use it to create the first administrator account and enter a parent domain. On submit the platform closes the entry point and the console lands at console.<the parent you entered>.
http://<host>:3000/setup?token=...03
Open the console
Certificates are issued per host — one for the console, one per workspace — so the first visit may land while one is still being issued. Sign in with the credentials you just created.
https://console.example.com04
Upgrade and uninstall
An upgrade swaps the image and keeps data and secrets. Uninstall keeps the database volume and storage pool unless you add --purge.
curl -fsSL https://raw.githubusercontent.com/eskim2001/dshcloud/main/scripts/install.sh \
| bash -s -- updateWhat else does instance access need?
Instances also need a pullable instance image, wildcard DNS pointing at this machine, and per-host TLS certificates. Starting the console alone does not open instances. Build an image locally only if you changed it:
./docker/instance-image/build.shNot production-ready. Verified on a real host: install, the bootstrap page, a per-host ACME certificate, and the :80 redirect. Not yet verified: creating and opening a workspace, or recovery after a host reboot.
FAQ
Good questions to ask first.
How does this relate to DeepSeek Harness?
DeepSeek Harness is the upstream agent harness. dshcloud adds accounts, workspace orchestration, quotas and access control around it. It is not an official DeepSeek cloud service.
Does the platform supply a shared model key?
No shared model key is injected into instances. Model endpoints and credentials are configured in dsh inside each instance. Platform and database credentials must stay outside instances.
Will recreating a name restore deleted data?
No. Deleting while retaining data preserves its ownership record. Reusing a name gets a separate storage identity. Restoring old data requires operator verification.
Can upgrade snapshots replace backups?
No. Only one pre-upgrade snapshot is kept per instance, and rollback discards changes made after that snapshot. Plan independent backups separately.
Are billing and multiple nodes included?
No. The current focus is instance lifecycle, access control and persistence on a single Docker host. Billing and multi-node runtimes are not current features.