dsh-model-key-sync
Sync your DeepSeek Harness model configuration and third-party API keys across
machines, over S3-compatible storage or WebDAV.
Sign in to Harness on a new computer, pull once, and your custom providers and their
keys are there — no retyping one key per provider.
Keys are stored in the remote as plaintext
This is deliberate — it matches CC Switch, and it means a new machine needs no
passphrase. The consequence is blunt: anyone who can read that bucket or
collection can read every API key in it. Use a dedicated application password,
keep the cloud account itself safe, and turn the key toggle off if you only want
model declarations to travel. See Security.
Why this exists
Harness keeps each machine's profile, credentials and model declarations locally.
Moving to a second machine normally means re-entering every provider: display name,
endpoint, protocol, model catalog, and the key.
Other plugins in the ecosystem sync the profile directory and local plugin sources —
dsh-cloud-sync documents that it
deliberately does not copy plaintext credentials. That leaves exactly this gap:
the keys. This plugin fills it, and carries the model declarations that reference
them.
Install
Ask the agent in Harness:
Install the plugin from github:tesths/dsh-model-key-sync
It runs the bundle installer for you. Or point it at a local checkout:
Install the plugin at /path/to/dsh-model-key-sync
Then reload the page. The section appears under Settings → Model Key Sync.
Requires a Harness build that provides the settings, credentials and tools
services, and an llm-pi-ai (or compatible) model adapter row.
Configure
Settings → Model Key Sync. Cloud sync is the page; a read-only summary of this machine — display name, API endpoint and model count — sits below it.
WebDAV
| Field | Value |
|---|
| Backend | WebDAV |
| Collection URL | https://dav.jianguoyun.com/dav/ (nutstore), or your Nextcloud path |
| User name | the account's login name (for nutstore: your email) |
| Password | an application password, not the login password |
| Remote directory | dsh-model-key-sync |
| Sync group | any name; identical on every machine |
S3-compatible
R2, OSS, B2, MinIO and AWS all work. Fill bucket, region (auto for R2), endpoint
(blank for AWS), access key id and secret.
Fill in the fields and press Save (configuration and secret save together), then Test → Upload.
On the second machine
Install the plugin, open the same page, fill the same values including the sync
group, and press Pull. The status card lists the credentials it
stored, for example:
pulled
credentials: ACME_API_KEY, OTHER_API_KEY
Daily use
- Manual: upload after editing models under Settings → Models; pull before using another machine.
- Auto: tick Auto upload. A pull never triggers an
upload.
- Conflict: nothing is overwritten silently. When both sides changed, a pull is
refused and the message names the axis —
model routes, API keys, or both. Tick
Force to take the remote, or upload to keep this device.
What travels
| Included | Not included |
|---|
| Provider routes: display name, protocol, endpoint, model catalog, key reference, provider defaults (reasoning, input, cache, thinking budgets) | Sessions, attachments, plugin sources |
The API key each route's apiKeyEnv resolves to | Credits/quota, usage history |
| Your choice of cloud backend and sync group | Other settings (theme, shortcuts, …) |
Restoring merges by route name and preserves fields it did not export — retry
policy, timeouts, transport or compatibility switches stay as they are on this
machine.
Remote layout
<remoteRoot>/v1/<syncGroup>/
├── manifest.json format, version, device, per-object sha256 and size, snapshotId
├── <provider>.json one file per route
└── keys.json { "ENV_NAME": "value" }
Payload objects are written first and the manifest last, so a reader never sees a
manifest describing objects the writer has not finished uploading. Every object is
verified by size and SHA-256 on download. Transfers are serialized with a total
timeout, an idle timeout and a response-size cap.
Security
- Keys leave the machine only through
ctx.credentials.resolve and are stored
through ctx.credentials.set — the same seam the model adapter reads.
- They are uploaded unencrypted. Treat the remote as a secret store: a private
bucket, an application password you can revoke, no shared folders.
- Turn off Sync keys to sync model declarations only.
- Anyone who obtains the remote can use your keys. Revoke them at the provider if
that happens.
- The local sync state (
~/.dsh/model-key-sync/cloud-state.json) stores hashes, not
keys.
Development
npm install
npm test # node test/host.mjs && node test/client.mjs
node test/host.mjs # 116 checks: settings, files, command channel, keys, S3 + WebDAV
node test/client.mjs # 91 checks: one-page cloud sync, read-only local summary, command channel
test/host.mjs starts a real S3-compatible server and a real WebDAV server on
loopback and drives two simulated devices through upload, pull, idempotency, conflict
refusal and forced overwrite. test/client.mjs loads the real client bundle into
jsdom with a faithful configForms/locale/slots contract.
See docs/ARCHITECTURE.md for why the page talks to the Host
the way it does, and CONTRIBUTING.md before changing that channel.
License
MIT
