Introduction

DSH itself is designed for local, single-user scenarios: it runs in a local file and key environment after startup. However, if DSH is deployed on a public server for long-term use by multiple users, several additional considerations are needed: who can log in, who is allowed to use it, whether each user can see each other’s files, how to securely store API Keys for each user separately, and how to access each user’s DSH via domain names or sub-paths.

dsh-server-login addresses these scenarios by providing a multi-tenant DSH hosting solution on a single server. After multiple users register and are approved by an administrator, each user receives an isolated DeepSeek Harness (DSH) environment, accessible via domain names.

Positioning

  • Repository: https://github.com/pointer-a/dsh-server-login
  • License: MIT
  • One-line positioning: Public-facing multi-tenant DSH hosting platform
  • Key capabilities: Login verification, per-user isolated DSH, web desktop, per-folder plugins, multi-form access, API Key isolation, local single-machine or k8s deployment

The core problem it solves is integrating the originally local and single-machine DSH into a server-hosted workflow that supports verification, isolation, and remote access.

Core Features

Login and Verification

bootstrap-admin is used to create the first administrator. After a regular user registers, they must be approved by an administrator before they can log in.

When a user is disabled, their session is deleted, and any running DSH for that user is stopped.

Per-User Isolated DSH

Each user corresponds to an isolated DSH environment. The main DSH runs as a persistent external service; when it crashes, a guardian DSH is launched on-demand for repair and automatically restarts the main instance.

Web Desktop

After logging in, regular users are directed to a web desktop where they can perform operations such as file browsing, creation, and uploading, and start DSH per folder.

All paths undergo two layers of fencing validation: first, lexical containment validation, followed by component-wise rejection of symbolic link components, to prevent escaping the user’s root directory.

Per-Folder Plugins

The system detects plugins installed in the user’s profile and allows enabling them per folder. The enabled state is persisted and injected via cordis patches.

Multi-Form Access

Supports three access forms:

  • Default sub-path: /u/<userId>/dsh/
  • Per-user subdomain: <username>.<baseDomain>, supporting HTTP + WebSocket
  • Custom domain: Provides an nginx server {} generation interface

Credential Isolation

Each user has a named API key vault. API Keys are encrypted with AES-256-GCM and stored as references-not-secrets.

When a key is changed, the instance is automatically rebuilt; during spawn, only the currently enabled key is injected.

Deployment Modes

Supports two deployment modes:

  • local: Single-machine deployment
  • k8s: Per-user Pod

Installation and Running

The provided information does not include an official dsh plugin add ... style installation command. The project README outlines a local process involving git clone, building, and running.

Prerequisites:

  • Linux server
  • Node ^22.19 or ≥24
  • DSH CLI installed

First, clone the repository and complete the build:

git clone https://github.com/pointer-a/dsh-server-login.git
cd dsh-server-login
npm install && npm run build            # tsc → lib/

npm run build compiles the code into lib/.

Create the first administrator:

node lib/cli.js bootstrap-admin --username admin --password '<strong_password>' --db ./dev.local.db

This administrator is used to log into the management console.

Start the orchestration service:

node lib/cli.js --port 3080 --db ./dev.local.db

Environment variables can be omitted; CLI flags with the same name, such as --port, --db, and --isolation-mode, take precedence.

Typical Usage

After completing the steps above, open:

http://127.0.0.1:3080/

Follow these steps to walk through the complete chain:

  1. Log into the management console with the admin account.
  2. Register a regular user.
  3. Return to the management console and approve the user.
  4. The regular user logs in again and enters the web desktop.
  5. On the desktop, upload files, create a new folder, and click “Start DSH in this folder”.
  6. In “Manage Keys”, enter your DeepSeek API Key.

Local trial runs can verify the chain of login, verification, desktop, and startup. To open the DSH chat interface, domain name and per-user subdomain configuration are also required.

k8s Deployment Mode

In addition to the local single-machine mode, the project also supports a k8s per-user Pod mode. When enabling k8s mode, relevant variables need to be configured, for example:

DB_URL
DSH_IMAGE
CONTROL_PLANE_IMAGE

These configuration items support containerized deployment and the generation of per-user Pods.

Security and Auditing

Verified security practices include:

  • Sessions use opaque random tokens, with only SHA-256 hashes stored.
  • Cookies use HttpOnly + SameSite.
  • Under HTTPS, Secure is added.
  • Passwords are salted and hashed with scrypt, using constant-time comparison.
  • Per-user API keys are encrypted with AES-256-GCM and stored.
  • The master key comes from an environment variable or <dataRoot>/secret.key, with file permissions set to 0600.
  • File operations undergo lexical containment validation first, followed by component-wise rejection of symbolic link components.
  • Actions such as registration, login, verification, and key changes are logged in audit_log.

Isolation layers include:

  • Soft isolation
  • Account-level hard isolation: OS account + setpriv privilege reduction
  • Port guarding: iptables owner-match
  • k8s Pod boundaries

Use Cases and Notes

Suitable for:

  • Needing to deploy DSH on a public server for use by multiple people
  • Needing registration, verification, and disabling of users
  • Needing each user to have an independent desktop, file directory, and API Key
  • Needing to access DSH via sub-paths, subdomains, or custom domains
  • Needing to choose between local single-machine and k8s deployment forms

Notes:

  • As a DSH plugin/server-side form, it runs under the permissions of the current DSH process. Before installation and enabling, the source code and license should be checked.
  • Local trial runs can verify the chain of login, verification, desktop, and startup, but fully opening the DSH chat interface requires domain and per-user subdomain configuration.
  • API Keys are encrypted and stored, but they remain sensitive credentials. It is recommended to manage the master key and data directory permissions according to production environment requirements.

Conclusion

The value of dsh-server-login lies in extending DSH from a local single-user tool to a manageable, verifiable, and isolated multi-tenant hosting service. It is released under the MIT license, with the repository address at:

https://github.com/pointer-a/dsh-server-login