GuoMonth/dsh-multi-tenant
Multi-tenant SaaS extension for DeepSeek Harness (DSH): tenant identity, session isolation, authorization, ten
dsh-multi-tenant makes DeepSeek Harness a real Multi-Tenant Runtime and provides a composable SaaS Framework Core: trusted product ingress resolves a TenantPrincipal, RuntimeComposition produces an exact whole-plan attestation bound to a canonical Tenant, canonical Principals own typed Runtime capabilities through Cordis with replaceable PrincipalCredentials, and one-shot create/resume Operations combine authorization with an immutable snapshot to drive Principal-owned DSH agents that use native Agent-scoped MCP Tools through the official DSH MCP client. M4 established the exact CompositionPlan↔RuntimeComposition binding/attestation and trusted Product Ingress→canonical Principal; M5 implements the real DSH-native MCP Tools agent integration. It is designed to be the foundation layer for multi-tenant SaaS deployments on DSH without forking Cordis/DSH semantics.
Install
dsh plugin --profile web add dsh-multi-tenantnpm package dsh-multi-tenant 0.2.0-rc.3 (registry-verified 2026-08-24; published foundation, README-documented). Install: dsh plugin --profile <profile> add dsh-multi-tenant. Current v0.3 line is in development (M5 real DSH-native MCP Tools Agent Integration implemented and executable; next step is 0.3.0-rc.1 release convergence). Pinned DSH baseline: 0.1.1-rc.2 at commit b150a551b8d465e31e418e1b2eaf5e79bbb7d28e; CI never follows floating latest/master. Verify: pnpm install --frozen-lockfile && pnpm release:check. MIT.
Compatibility
DeepSeek Harness 0.1.1-rc.2 (pinned baseline; CI never follows floating latest/master). Multi-Tenant Runtime + composable SaaS Framework Core without replacing Cordis/DSH lifecycle semantics. Explicit boundaries: product authentication stays outside Core; Product Ingress resolves trusted identity; RuntimeComposition prevents Plan mixing; Tenant/Principal own typed Runtime capabilities through Cordis; Operation owns one semantic create/resume decision, not the Agent lifetime; the live Agent is Principal-owned and drained by Principal teardown; MCP transport/protocol is delegated to the official @deepseek-ai/dsh-mcp-client; strong hostile-code isolation remains a process/container/Pod concern.
Details
- Repo: GuoMonth/dsh-multi-tenant
- Category: Other
- Stars: 6
- Version: npm package dsh-multi-tenant 0.2.0-rc.3 (registry-verified 2026-08-24)
- Last push: 2026-09-21
- First seen: 2026-08-14
Recent updates
The current English README documents: the product path diagram (auth → ingress → TenantPrincipal → RuntimeComposition → Tenant → Principal → Operation → Agent → MCP tools), explicit boundary list, M4 foundation (CompositionPlan binding/attestation, PrincipalCredentials), M5 status (real MCP agent integration executable, 0.3.0-rc.1 convergence next), pinned DSH baseline, install, and verification.
FAQ
- What is the pinned DSH baseline?
- DSH 0.1.1-rc.2 at commit b150a551b8d465e31e418e1b2eaf5e79bbb7d28e — CI never follows floating latest/master, so behavior is reproducible.
- Does it replace Cordis or DSH lifecycle semantics?
- No — it makes DSH a real multi-tenant runtime and provides a composable SaaS framework core without replacing Cordis/DSH lifecycle semantics.
- How does MCP tool access work?
- MCP transport/protocol is delegated to the official @deepseek-ai/dsh-mcp-client, giving Principal-owned agents native Agent-scoped MCP Tools.
Alternatives
xiaozhe7772222/dsh-api-key-pool · BruceLanLan-dsh-tier-router · Lhy723/dsh-agent-canvas