DeepSeek Harness をサーバーに常駐させて 24 時間動かす
スクリーンショット検証済みの13ステップ。空の VPS から常時稼働の dsh へ — root SSH とブラウザターミナルの確保、モデルプロバイダーとコンテキストウィンドウ付きカスタムモデルの接続、タブを離れずにプラグインを入れる、そして agent が作ったサイトへの公開 URL を取りに戻す。
最終更新: 2026-10-15
DeepSeek Harness はエージェントループをぶら下げた Web アプリケーションなので、どの機械で動かすかは単なる設定です。その機械をノートパソコンからサーバーに置き換えると、依頼できることが変わります。ふたを閉じてもビルドは続き、ワークスペースは再起動を生き残り、開くアドレスは臨時のトンネル URL ではなくサーバー自身のホスト名になります。長時間のタスクをバッテリー残量で調整しなくて済みます。
このページは、サーバー構築を一から最後まで追った 1 本の動画（出典はページ末尾に記載）に沿って、「サーバー常駐型」だけを扱います。harness を VPS に入れる、SSH かブラウザターミナルをつなぐ、ローカル構成では不要だったモデル設定を組み直す、そして全員が驚く一点 — agent が返してきたプレビューリンクが自分の PC では開けない問題まで。スマホをトンネルでリモート接続する話と、Ollama でローカルモデルを動かす話は別の仕事なので、下の関連ガイドに譲ります。
やり切ったときに手に入るもの
- ▸いつも使っている Web UI そのまま。VPS のホスト名で開き、ログイン名は root ではなくパネルが教える admin。シェルが要るときはブラウザの中にターミナルがあります。
- ▸リリースされた当日のモデルも、ピッカーに出る前に追加できます。プロバイダーの slug をカスタムモデル行に貼り付け、同じ場所でコンテキストウィンドウと最大出力トークンを指定します。
- ▸作ったものがサーバーに残ります。出力先フォルダをセッションに指示すると、リモートでは開けない localhost リンクの代わりに、8080 番ポートの公開 URL が返ってきます。
13 ステップでサーバー常駐版を完成させる
harness を機械の上に乗せる
- 1
ワンクリックデプロイ後、パネルの SSH 行を控える
ワンクリック用イメージは Ubuntu 上に完成済みのアプリとして harness を入れます。完了カードには、この後ずっと使う情報が並びます。アプリ名と基盤 OS、ログインユーザー名（admin）、パスワードリセット、起動中の harness を新しいタブで開く Manage App ボタン、そして SSH access の ssh root@<サーバーIP> という完全なコマンドです。このコマンドは今すぐコピーしておいてください。エージェントが住む機械への入口になります。
$ssh root@<YOUR_SERVER_IP>1 枚のカードに、この後必要になる 3 つが揃っています。ログインユーザー、稼働中のアプリ、SSH コマンド。3:40 から見る - 2
VPS の概要ページで root SSH とブラウザコンソールを確保する
概要ページは管制室です。アプリが動き出したあとでも一度は通しておく価値があります。DeepSeek Harness のカードには admin というログイン名が再掲され、Ubuntu 26.04 Running の行には Reboot と並んで Web console ボタン。その下の帯には SSH username: root、IPv4 アドレス、root パスワードのリセット、そして ssh root@… の完全なコマンドが置かれています。いちばん効くのが Web console です。ブラウザのタブの中に root シェルが開くので、SSH クライアントを置いていない機械からもこの harness を管理できます。
ブラウザの Web console は保険です。SSH クライアント無しで root シェルに到達できます。8:20 から見る - 3
初回の APIキー ダイアログは Configure later で飛ばす
アプリを初めて読み込むと Add an API key to get started が出て、公式 DeepSeek プロバイダーの設定を促されます。動画では意図的に Configure later をクリックします。サーバー構成の価値はどのプロバイダーを付けるかを自分で決められることにあり、OpenRouter のキー 1 本で数百モデルになるのか、特定モデルのためにベンダーのキーを別で引くのか、その判断は Settings の仕事であってこのダイアログの仕事ではありません。
ここではスキップ。プロバイダー選びは Settings → Models の判断であって初回起動の話ではありません。3:46 から見る - 4
セッションを開始する前にワークスペースのフォルダを作る
セッションはワークスペースの中で動き、ワークスペースはサーバー上のただのディレクトリです。Select Workspace Directory ダイアログはサーバー自身の home を見に行き、既存フォルダの一覧に Show hidden files の横に New folder ボタンを備えています。動画では deepseek-test を作って開きます。このワークスペースで始めたセッションはすべてそのフォルダの内側だけを読み書きするので、複数人で使う機械でもファイルが野良化しません。
ワークスペースはサーバー上のフォルダ 1 つ。セッションはそこから読み書き範囲を継承します。4:08 から見る
サーバー構成にモデルを接続する
- 5
Settings → Models → Add provider
Settings はサイドバーの一番下にあります。Models タブがプロバイダーの住処で、Add provider を押すとアルファベット順の長い一覧が開きます。amazon-bedrock、art-dog、atenloop、azure-openai-responses、cerebras、cloudflare-ai-gateway、cloudflare-workers-ai、deepseek、fireworks、github-copilot、google、google-vertex、groq、huggingface、kimi-coding、minimax、mistral、moonshotai、nvidia、openrouter と続きます。動画の構築では OpenRouter を選びました。キー 1 本でこれらのベンダーのモデルをほぼカバーでき、会話の途中でも切り替えられるからです。
一覧が長いので、現実解は OpenRouter のキー 1 本になります。4:42 から見る - 6
プロバイダーのモデル一覧を取り込んで、まとめて追加する
キーを貼り付けたあと、Customized settings の中に Fetch available models が出ます。押すと Choose models to add ダイアログが開き、モデル slug ごとにチェックボックスが並びます — a1zlj/jamba-large-1.7、aion-labs/aion-2.0、amazon/nova-2-lite-v1、amazon/nova-lite-v1、anthropic/claude-3-haiku など — 加えて Deselect all と Add selected。全部入れたままにするのが要点で、モデルピッカーは以後メンテ対象ではなくなります。Apply を押すと、この一覧が稼働中のサーバー側インスタンスに書き込まれます。
1 回全部チェックしておけば、モデルピッカーは以後のメンテ対象ではなくなります。5:24 から見る - 7
まだ一覧に無いモデルを、コンテキストウィンドウ付きで追加する
当日リリースされたモデルはピッカーに出てきません。取り込み済みの一覧の方がモデルより古いからです。解決策は同じ Models 画面のいちばん下、Add model の行にあります。プロバイダー側のページからコピーした slug を貼り（動画では google/gemini-3.8-flash）、セッションのドロップダウンに表示する名前を打ち（gemini-3.8-flash）、その行を広げるとフィールドが 2 つ増えます — Context window と Max output tokens で、プレースホルダーはそれぞれ 256K と 32K です。動画では両方空のままデフォルトに任せていますが、トークン課金されるサーバーでは、暴走した出力に上限をかける場所はこの場所です。
$google/gemini-3.8-flash
リリース当日のモデルを、取り込み済み一覧がそれを知る前に追加する方法です。7:12 から見る
どこからでもアクセスする
- 8
一声かけて、実行統計の行を読む
スモークテストは一言で十分です。返信の下にメタデータの行が付いてきて、経過時間、Ran for 1s、TTFT 1.7s、そしてこのセッションで強調表示されている 5167 tok/s が並びます。この 1 行が 4 つを同時に確認させてくれます。プロバイダーキーが解決できたこと、モデルが応答したこと、エージェントループがサーバー側で回っていること、そしてブラウザからデータセンターまでの往復が 1 日使い続けられる速さであること。
強調された 1 つの数字が、キーとモデルとサーバーの接続を同時に証明します。7:28 から見る - 9
localhost ではなくホスト名で harness を開く
アプリがサーバーに配信される側になると、アドレスバーには 127.0.0.1:3080 ではなく VPS のホスト名が表示され、同じアドレスがノートパソコンでもスマホでも同僚の機械でも開けます。サイドバーが何よりの証拠です。サーバー上のワークスペースが全部並んでいます — 定期タスク用の Morning Brief、並行して走った Web サイト demo 2 つ、テスト用に作ったものまで。状態がブラウザではなくサーバー側にあるからです。
同じアプリ、違うアドレス — 左のワークスペース列がその証拠です。18:40 から見る
ブラウザを離れずに拡張する
- 10
ブラウザのコンソールでプラグインのコマンドを実行する
プラグインは dsh のコマンドラインで入れますが、まっさらなシェルで最初に叩くと必ず失敗します。ターミナルは Command 'dsh' not found, did you mean… と返し、その下に思いついた apt パッケージ名まで添えてきます。動画での直し方は、まず Node のパッケージマネージャーを入れる（npm install -g pnpm）、それからプラグイン追加コマンドを再実行して harness サービスを再起動する、という順です。同じコンソールは hostname、hostname -f、ipinfo.io への curl にも応えてくれるので、ブラウザに貼り付けるアドレスはここで手に入れます。
$hostname; hostname -f; curl -s https://ipinfo.io/ip$npm install -g pnpm
プラグイン導入は CLI の仕事ですが、まっさらな機械の PATH にはまだコマンドがありません。8:56 から見る - 11
強制再読込のあとに、プラグインマーケットからクリックで導入する
プラグインを入れても、サービスを再起動してタブを強制再読込するまで何も起きません。しかもプロンプトもエラーも出ないので、ここで詰まる人が後を絶ちません。通過すると Settings → Plugins → Plugin Market が生きたカタログになり、各項目に Install ボタン（dsh-git-graph、dsh-skill-explorer、modlens、dsh-context）、Discover / Themes / Installed / Advanced のタブ列、上部に Update the plugin market が見えます。動画の注意喚起は意図をそのまま引く価値があります。審査済みのプラグインだけを入れること。マーケットの中身はコミュニティのコードで、動くときはあなたのエージェントの権限をそのまま使います。
サービスの再起動と強制再読込を済ませれば、以後ターミナルは不要になります。9:52 から見る
作ったものを配信する
- 12
VPS では localhost のリンクが開けない前提で考える
作ったものをどう見ればいいか尋ねると、返ってくるのは http://localhost:3000 と、起動用の python3 -m http.server か npx serve のコマンドです。開くと Chrome に This site can't be reached — 127.0.0.1 refused to connect、ERR_CONNECTION_REFUSED と出ます。壊れているものは何もありません。サーバー上で localhost はそのサーバー自身を指し、あなたのパソコンのブラウザは自分に問いかけているだけです。ローカル構成とサーバー構成のいちばん大きな差はここです。
VPS において localhost はその VPS を指します。このプレビューリンクは手元のパソコンからは開けません。15:56 から見る - 13
出力フォルダを固定して、公開 URL を取り返す
回避策は追加の 1 メッセージで、ファイルをどの出力先に置き、どのアドレスを表示させるかをセッションに伝えることです。動画では the final output should be at http://<ホスト名>:8080/<ビルド名>/ と書いています。エージェントはサイトを /var/www/preview/<ビルド名>/ にコピーし、自分のポートに curl を流して 200 を確認し、Final Live URL と合わせて index.html、styles.css、menu-data.js、app.js を 1 ファイルずつ説明して返します。プレビュー用フォルダを 1 回決めるだけで、以後このワークスペースのビルドはすべて、顧客に送れるリンクで終わります。
$the final output should be at http://<YOUR_HOSTNAME>:8080/<BUILD_NAME>/
一言足すだけで、以後のビルドはすべて送れるリンクになります。16:24 から見る
複数人で使う場合は？
ここまでで手に入るのは、admin ログイン 1 つに対して harness 1 台という構成で、動画もそこで止まっており、ユーザー単位の分離は一切設定していません。個人用なら問題ありませんが、チームだとこれは実際の課題になります。あの URL に到達してログインを通過した人は、同じワークスペース、同じセッション履歴、同じ APIキーを共有するからです。人ごとに隔離する話はサーバー設定では解決できず、プラグインの仕事です。公網向けのサーバーをマルチテナントのホスティング基盤に変えるコミュニティ製プラグインがあり、ユーザーが登録し、管理者が承認し、各自が分離された dsh 環境と自分のキーを受け取ります。何をするかは 詳細ページに書いてあります.
隔離とサンドボックス
セルフホスティングが答えるのは「サーバーをどこで動かすか」、サンドボックスが答えるのは「動き出したエージェントに何を触らせるか」です。2つの意図は一緒に現れますが、同じ仕事ではありません。「自分のマシンで動かす」はデータ主権の話、「エージェントを隔離環境に閉じ込める」は被害半径の話です。2026-09-27 の実測で「dsh 沙箱插件」は 26.4（易い）で、供給もようやく独立したセクションに足るものになりました。
strukto-ai/mirage（★3,663）
クラスタの筆頭：AI エージェントのために作られた仮想ターミナルです。エージェントが手にするのは本物のシェルではなく、模擬的なシェルとファイルシステム。「npm install を実行されたが、あとは祈るしかない」という不安を、再生可能なサンドボックスに置き換えます。
sandbaseai/sandbase-harness（★674）
ローカルファーストのセルフホスト型エージェントランタイムです。サンドボックス化されたセッション、資格情報の保管、監査ログを MCP ブリッジの向こう側に備えます。このページの2つの半分——セルフホスト（あなたのハードウェア）と隔離（エージェントの操作）——を一度の導入でつなぐ橋です。
SeaOf0/dsh-redteam-model（★637）
スペクトラムの攻撃側です。stage-gate の強制とスキャナーによるラッピングにより、許可されたセキュリティ研究——ペネトレーションテスト、レッドチーム評価、コード監査——に対応します。サンドボックスは「エージェントが暴れるかもしれない」と仮定し、レッドチームツールは「エージェントが攻撃される」と仮定します。同じ脅威モデルの同じページの、正反対の席です。
チームとエンタープライズ導入
同じサーバーでも、組織図が違います。個人 VPS があなたにだけ答えるのに対し、エンタープライズ導入はID・監査・共有ワークスペースに答えます。公式ディスカッション #8045（「エンタープライズ向けシナリオ」）が今週立ったばかりで、2026-09-27 実測の「dsh エンタープライズ導入」は 33.3（易い）。docker（67.4）と VPS（62.4）という困難の山に比べ、この角度は無人です。
Devin-AXIS/iPolloWork（★6,785）
人とエージェントのチーム向けエンタープライズグレード・ローカルファーストのワークベンチです。ロールと共有コンテキストを備えた統一マルチエンジン ワークスペース。このガイドの軌道で最も重いリポジトリであり、需要の所在——より多くのパネルではなく、ガバナンス——を物語っています。
himovo/movo（★164）
DSH をセルフホストのエンタープライズ エージェントプラットフォームに変えます。同じランタイムの上にナレッジベース、ディープリサーチ、コラボレーションを重ねます。「一人に一台の VPS」とワークベンチ全面展開の中間ルートです。
実際に変わるもの
3つの変化で、ハードウェアは不要です。ID（上のマルチテナントログインサーバーが選択肢から必須になる）、監査（誰がいつエージェントに何を実行させたか）、設定のコード化（ワークスペースを再構築できること）。サンドボックスの節から来たなら、こう理解してください。エンタープライズ導入とは、組織図のついた被害半径の問題を制度化したものです。
Docker で DeepSeek Harness を動かす：現状と現実的な道
2026-10-15 時点で公式リポジトリを確認：dsh は Dockerfile も docker-compose.yml も同梱しておらず——リポジトリ内唯一の Dockerfile は sshd ヘルパーのテストフィクスチャです——Docker Hub に公式イメージもありません。公式ドキュメントのデプロイ路線は Node.js とリバースプロキシ：public-deployments ドキュメントが --public-url、--trusted-host、TLS を扱っており、上のウォークスルーはまさにその路線です。公式に方針転換を求める公開のお願いが 2 件あります：discussion #9440（「強烈建議支援docker部署」、賛成 2、2026-10-11）と #9654（「希望補充/更新 Docker 部署方式」、2026-10-14、DSH_HOME の永続化・明示的な実行 uid・設定可能な --trusted-host/--public-url を備えた本番向け compose の輪郭を描いています）。公式が着手するまで、以下はすべてコミュニティ実践の立場であり、公式サポートではありません。
コンテナ化のレシピは、公式コマンドに箱を被せただけです。ベースイメージ：最新の Node.js——リポジトリ自身の engines フィールドは Node ^22.19.0 または >=24 を要求。実行コマンド：公式ドキュメントの npx @deepseek-ai/dsh web に、公式 CLI ヘルプが決めているコンテナ向けの 3 つを加えます：--no-open（コンテナにブラウザはない）、--host は具体的なインターフェースアドレスで指定（0.0.0.0 のようなワイルドカードは明示的に拒否される）、そして既定ポートは 3080。保つべき状態はすべて DSH_HOME の下にあります——harness ホームを指す公式の環境変数で、既定は ~/.dsh——これこそボリュームに載せるべきものです。
スケッチの読み方：ホスト名とバインドアドレスは自分のものに差し替えてください。信頼フェンスは --trusted-host が名指しした authority だけを通し——別のホスト名で来たブラウザは、他が正しくても API 呼び出しごとに 403 を食らいます。ワイルドカードのバインドアドレスが拒否されるため、コミュニティのやり方は、起動時にコンテナ NIC の実際の IP を解決する（コンテナ内で hostname -i）か、ホストネットワークで動かすかのどちらか。名前付きボリュームがこの演習の本質です。DSH_HOME をボリュームに載せれば、コンテナを入れ替えてもセッション・プロファイル・ワークスペースのファイルは残ります。
アップグレードはコマンドの再実行です：npx の流れは最新リリースを取得するので、ベースイメージを更新してコンテナを再作成すれば、それがアップデートの全部——Linux インストールガイドの「再実行で更新」と同じ規則です。セキュリティもコンテナ内で緩みません。表示された URL はパスワード扱い、ポート 3080 を公開インターネットに直接晒さず公式ドキュメントどおりリバースプロキシの後ろへ、そしてユーザー単位の分離はないということを忘れないでください——上のベアメタル版ウォークスルーと同じ注意事項です。
DeepSeek Harness のセルフホスティング：よくある質問
dsh をノートパソコンから引っ越す前に、みんなが気にする点。
DeepSeek Harness を動かすには大きなサーバーが必要ですか？
小さくて足ります。追った構築では 2 コア / 8 GB の KVM プランで harness 全体を動かし、モデルはすべて API 呼び出しでした。機械が担うのは Web UI の配信、エージェントループ、ファイルの保存だけで、推論はプロバイダー側で起きます。ウェイトまで自前で動したいときだけ、もっと大きい構成が必要になります — それは別のガイドの話です。
スマホからリモート接続するのとは何が違うのですか？
別物で、差が重要です。遠隔アクセスはトンネルです。harness は自分の機械で動き続け、その機械は電源を入れっぱなしにしなくてはならず、公開 URL はランダムでトンネルを再起動すれば失われます。セルフホスティングは harness そのものを常時稼働のサーバーへ移します。ふたを閉じた後も夜のタスクは進み、ブックマークするアドレスはサーバー自身のホスト名です。
動画と同じホスティング会社を使う必要がありますか？
いいえ。ベンダーは本質ではありません。Ubuntu イメージと harness テンプレートが動く VPS ならどこでも構いません。パネルから欲しいものは同じ 3 つです。本物のシェル用の ssh root@ コマンド、単発コマンド用のブラウザ内 Web コンソール、稼働中のインスタンスを開く Manage App のリンクです。
別のモデルを使いたいのに、なぜ最初に DeepSeek のキーを求められるのですか？
あのダイアログは公式 DeepSeek プロバイダーを 1 つ接続するだけで、Configure later で飛ばしても何も壊れません。プロバイダーは Settings → Models で追加し、それぞれに個別のキーを割り当てます。全プロバイダーのモデルは同じセッションのピッカーに集約されるので、会話の途中でモデルを乗り換えられるようになります。
モデルごとにコンテキストウィンドウを設定できますか？
できます。Settings → Models のカスタムモデル行では、モデル ID と表示名のすぐ下に Context window と Max output tokens の 2 フィールドが続きます（プレースホルダーは 256K と 32K）。空欄ならプロバイダーの既定値に従い、値を入れれば出力トークン課金のモデルに上限をかけられます。複数人で共有する機械ではコスト抑制にも効きます。
公網 IP に置いても安全ですか？
あの URL をパスワードとして扱ってください。アプリのログインはユーザー名 admin と VPS のパスワードを使い、ユーザー単位の分離はありません。ログインを通過した人はワークスペース、セッション履歴、APIキーを共有します。強いパスワードを使い、剥き出しのポートを開くのではなく手前に HTTPS を噛ませ、プラグインは審査済みだけを入れる。動画でもこの注意は 2 回出てきます。1 回はテーマを試しながら、最後に削除するところまで見せています。
dsh のセルフホストに Docker は必要？Docker Compose や Docker Hub のイメージ、Raspberry Pi で動かせる？
Docker は公式ドキュメントのルートにはありません。公式が示すのはサーバー上の Node.js と npm によるデプロイ——上の解説のステップそのものです——そしてリポジトリーが同梱しているのは Makefile であって、Dockerfile や compose ファイルではありません。チームの標準がコンテナーなら、梱包は自分で行うことになります。Docker Hub で見つかる dsh イメージはすべてコミュニティ製なので、サードパーティーのプラグインと同じ基準で審査してください。compose ファイルに書くべきは、このガイドがすでに要求している 2 つだけ：ポートと、永続化されたワークスペースディレクトリーです。Raspberry Pi クラスのハードウェアでも同じステップが動きます——条件は Node.js 20+ なので、ボードには 64 ビット OS を載せ、Web UI は控えめな速度を想定。ステップ 4 の「最初にワークスペースディレクトリーを作る」ルールは、小さいディスクほど重要です。
関連ガイド
隣り合う仕事：動かさずに残した harness につなぐ、機械の上で推論する、安全に入れる。
どの端末からも DeepSeek Harness をリモート操作する
harness は自分の機械に置いたまま、無料の ngrok トンネルでポート 3080 を公開する。スマホ向けの同じ問題の解き方です。
ガイドを読むDeepSeek Harness にローカルモデルを接続する
Ollama や OpenRouter の無料モデルを繋ぎ、推論をキー呼び出しではなくその機械の上で実行します。
ガイドを読むDeepSeek Harness のプラグインの入れ方
マーケットの使い方、再起動＋強制再読込という見落とされがちなルール、エージェントの権限で動く前に中身を確認する方法。
ガイドを読むモデルの切り替えとカスタムプロバイダーの追加
セッション途中でモデルを換える、一覧に無いプロバイダーを登録する、実際に誰と話しているか検証する。
ガイドを読むDeepSeek Harness の安全設定と権限
24 時間稼働でシェルも使えるエージェントに、何を許可して何を触らせないようにするか。
ガイドを読むデスクトップアプリとクライアント
DSH のネイティブ・Electron クライアントの棚卸し。せっかく立てたサーバーを、自分のマシンから使うための入り口探し。
ガイドを読む出典とクレジット
このページのスクリーンショットはすべて、下にリンクした動画から取り出したコマです。解説者のカメラ吹き出しを消すためのトリミングを加え、出典を明記しています。各ステップは、元動画の正確な秒数へのディープリンクを持ち、手順・注意点・結論はこのページ独自に書いたものです。