Introduction

After using an agent like DSH to write a static site, a Worker, or a dsh plugin, things often get stuck at the last mile: To see the online effect, you have to register a cloud account, install wrangler, write configuration, and configure authentication; to publish the plugin you wrote, you have to check package contents and dependency licenses item by item, and deal with npm’s 2FA process. These steps are mechanical, error-prone, and irrelevant to writing code itself.

dsh-plugin-deploy targets this closing work. Below is an introduction to its positioning, installation method, two main capabilities (deployment and publishing), and design regarding credentials and approval.

What is it

dsh-plugin-deploy is a DeepSeek Harness (DSH) plugin maintained by Octo-o-o-o, under the MIT license. Positioning in one sentence: Deploying a project to Cloudflare and publishing a dsh plugin to npm are both done with a single sentence in the conversation; you can get an online address without a Cloudflare account, and credentials are invisible to the model.

It provides two entry points:

  • deploy tool and /deploy slash command: Deploy project to Cloudflare;
  • publish_plugin tool and /publish-plugin slash command: Publish dsh plugin to npm.

Installation and Enablement

Installation command:

npx @deepseek-ai/dsh plugin --profile web add dsh-plugin-deploy

After installing into a specified dsh profile, start the Web interface:

npx @deepseek-ai/dsh web

Environment requirements:

  1. Node >= 22 (engine declaration);
  2. dsh 0.1.2-rc.1 or later;
  3. Wrangler >= 4.102.0 installed locally (temporary preview requirement).

A reminder: pnpm has minimumReleaseAge supply chain protection, so newly released versions cannot be installed during the cooldown period. If add dsh-plugin-deploy installs a version that is not the latest, you can explicitly specify:

npx @deepseek-ai/dsh plugin --profile web add dsh-plugin-deploy@0.1.4

Capability 1: Deploying a Project to Cloudflare

After installation, just say a sentence in the conversation:

Help me deploy the ./my-site directory

The Agent will invoke the deploy tool and return a temporary preview URL, remaining claim time, and claim link. To force a mode, you can directly say “Use temporary preview” or “Deploy to my account”.

Two Deployment Modes

  1. temporary Temporary Preview: No Cloudflare account needed, get a *.workers.dev URL and a 60-minute claim window;
  2. account Own Account: Deploy to your own account, get a persistent URL, requires configuring a token or running wrangler login.

Default is auto for automatic selection, but can be specified in the conversation.

Supported project types:

  • Pure static directories;
  • Vite-like build outputs (dist/);
  • Worker projects with existing wrangler.jsonc / wrangler.toml / wrangler.json.

It will ask if the project type cannot be detected; it won’t guess blindly. If there is no wrangler configuration in the project, the plugin will temporarily generate one, writing it to the system temp directory, without writing it to your repository.

Claim Window for Temporary Preview

Temporary preview uses Cloudflare’s temporary account capability, with a hard constraint: if not claimed within 60 minutes, Cloudflare will delete that temporary account and all its resources. Therefore, the plugin will provide a countdown and a claim link in the results, and remind of unclaimed records during the next deployment.

Two points to note:

  1. The claim link itself is a credential and will appear in conversation history; do not share the conversation;
  2. Creating a temporary account is equivalent to accepting Cloudflare’s Terms of Service. wrangler accepts these automatically in non-interactive environments, but the plugin does not accept this default. It will present the Terms of Service and Privacy Policy links for you to confirm.

Additionally, the temporary preview runs in an isolated environment with a separate HOME, unable to read local Cloudflare credentials, so wrangler logout is not needed. Temporary accounts have asset limits: no more than 1,000 files, and a single file size limit of 5 MiB.

Capability 2: Publishing a dsh Plugin to npm

This section is aimed at plugin authors. It provides the publish_plugin tool and /publish-plugin slash command, with three modes:

  1. check: Only validation, zero side effects (default);
  2. pack: Create a .tgz file after validation passes;
  3. npm: Publish to npm after validation passes and you confirm.

There are 8 validations before publishing: dsh-plugin, patch-in-pack, client-bundle, main-entry, deps, pack-clean, version-available, scan. If any validation fails, neither pack nor npm will execute (fail closed).

Conversation example: Say “Publish this plugin to npm”, after all 8 validations pass, enter approval, you click “Allow once”, then execution proceeds.

npm token handling: The plugin writes a temporary .npmrc containing only the reference ${DSH_NPM_TOKEN}. The actual value is passed to npm via the process environment and deleted after use. It does not touch your ~/.npmrc, and the token is not written to disk.

A practical tip: When your npm account has 2FA enabled, a standard token will get stuck on the OTP prompt. It is recommended to use an automation token or a granular token with “Bypass 2FA” checked, set a short expiration time, and revoke it after publishing.

“Publish” Button Next to Conversation Title

After installation, the action bar next to the conversation title will have an extra “Publish” button. Clicking it offers two options: Deploy to Cloudflare, Check plugin publish.

Its working method is to write the corresponding sentence into the input box and submit it, bypassing the agent approval process—it does not bypass the agent approval flow. Afterward, the model invokes tools, confirms terms, approval, and result recording proceed as usual. This is a deliberate design: Deployment and publishing are irreversible external actions, and direct execution by the UI does not allow for approval.

Credential Handling

The credential design is split into two layers:

  1. Only the reference name is stored in the configuration; defaults are CLOUDFLARE_API_TOKEN and NPM_TOKEN. You fill in the name, not the token itself;
  2. The token value is handed to the dsh credential service, stored in $DSH_HOME/.credentials.yaml, with permissions 0600.

Tokens do not enter the conversation or logs, and command output is masked before returning. The Cloudflare token requires Edit Cloudflare Workers permissions; you can also skip configuring the token and directly run wrangler login to use OAuth.

Security and Approval

The plugin will stop and ask you at two places:

  1. Terms of Service confirmation (temporary preview only): It will present the Terms of Service and Privacy Policy links for you to confirm, rejecting wrangler’s automatic acceptance;
  2. Approval: Deploying to the public network and publishing to npm both go through the dsh approval channel and require you to click “Allow once”; rejection, timeout, or unavailability of the approval service will all abort (fail closed).

Known Limitations

Listed truthfully:

  • Only supports Cloudflare. Vercel / Netlify / VPS / custom domains / rollback / Next.js SSR (OpenNext) are not currently in scope.
  • Temporary preview expires after 60 minutes and is lost if not claimed; this is a Cloudflare rule, and the plugin can only remind you.
  • In account mode, wrangler writes to ~/.wrangler/logs, which may throw EPERM under Workspace Write sandbox, but testing shows it does not affect deployment results.
  • stderr has a 64 KB limit, and diagnostic information may be truncated in extreme cases.
  • Publishing only supports npm and tarballs.
  • Not verified under TUI / headless profile; handled as fail-closed when no interactive provider is available.

Applicable Scenarios and Notes

Suitable for two types of people: those who have written static sites, Vite projects, or Workers with DSH and want an online address within a few minutes, especially when they don’t have a Cloudflare account yet; and dsh plugin authors who want to standardize the publishing process with a set of fixed validations.

Note before installation: The plugin runs with the permissions of the current dsh process; it is recommended to check the source code first to confirm the behavior meets expectations before deciding to install. License is MIT.

Conclusion

dsh-plugin-deploy compresses the “deployment” and “publishing” closing work into the conversation: Temporary preview lets you see results without a cloud account, 8 validations block common npm publishing pitfalls, credentials don’t enter the model context, and irreversible actions require manual approval.

Repository: https://github.com/Octo-o-o-o/dsh-plugin-deploy, you can search for it in the dsh.pub plugin directory: https://dsh.pub/en/plugins/?q=Octo-o-o-o%2Fdsh-plugin-deploy .