devboxes

Namespace devboxes

Namespace の devbox は、リモートの linux/amd64 または macos/arm64 マシンです。Linux の devbox では Docker を利用できます。このスキルでは、devbox を作成する、ファイルを転送する、ワークスペースを準備する、ツールチェーンをインストールする、devbox exec でコマンドを実行する、devbox.so を通じてウェブ上の作業をチームメイトと共有する、devbox のライフサイクルを管理するといった、devbox を扱うための基本的な構成要素を説明します。

このスキルでは、以下の用語を使用します。

• devbox - name で識別される Namespace のマシンです。
• <name> - すべての devbox サブコマンドに渡す devbox の名前です。

呼び出し元の意図に応じて、devbox は長期間使用したり、タスク間で再利用したり、すぐに破棄したりできます。使い捨てとして扱うには、作成時に --ephemeral を渡します。

一度だけ実行して破棄するワークフロー（単一スクリプトやテスト実行、必要に応じたシャーディング）については、references/run-tests.md を参照してください。

0. 実行場所を確認する

以下の説明はすべて、別の場所から devbox を操作することを前提としています。まず、すでに devbox 上にいるかどうかを確認してください。ツールと認証の方法が異なります。

[ -n "${NAMESPACE_DEVBOX_WORKSPACE_DIR:-}" ] && echo "on a devbox"

Devbox エージェントはこの変数をマシン上のすべてのプロセスに設定するため、信頼性の高い簡単な確認方法です。設定されている場合は、ほかの操作を行う前に references/inside-a-devbox.md を読んでください。ここでは次の 2 点が異なります。

• 通常のコマンドにラッパーは不要です。 マシン上にいるため、go test、git、ファイルの編集を直接実行し、現在いる devbox 内で完結する作業では、以下の devbox の事前確認を省略してください。
• 両方の CLI をすでに使用できます。devbox login は実行しないでください。 boxctl と devbox はどちらも ~/.devbox/bin に含まれています。devbox CLI は ワークロード クレデンシャルで認証されます。このクレデンシャルはユーザーではなくテナントとして機能します。そのため、ワークスペースアクセスが有効な devbox は操作できますが、作成者専用の devbox（通常は現在いるマシンを含みます）は操作できません。これが、単に速いだけでなく、現在の devbox ではソケット経由でローカルエージェントに接続し、クレデンシャルを必要としない boxctl を使う理由です。ここで devbox auth check-login を実行すると、CLI が動作しているにもかかわらず「Not logged in」と報告されるため注意してください。それに従うと、完了できないブラウザーログインのフローに進んでしまいます。このほか、兄弟ボックスの作成に使用する --access_mode workspace などについては、リファレンスを参照してください。

事前確認 devbox を PATH またはプラットフォームの既定のインストール先から解決してください。PATH の情報が古い場合は絶対パスを使用し、Devbox CLI が存在しない場合に限って自分でインストールしてください。解決した CLI の auth check-login を実行します。ログインが必要な場合は devbox login を実行し、ユーザーがブラウザーフローを完了するまで待ってから、コマンドの終了を待ちます。セッションの有効期限切れやワークスペースの切り替えを含む正確な手順については、references/cli-setup.md を参照してください。ほかのツールからクレデンシャルを生成したり借用したりしないでください。

1. devbox を作成する

タスクでプロジェクトのツールチェーン（Go、Node、Xcode など）が必要な場合は、実行のたびに依存関係を再インストールせずに済むよう、必要なツールチェーンがすでに含まれているイメージを選んでください。devbox image list -o json を 1 回実行して既存のプロジェクトイメージを確認し、適切なものがあれば使用します。その結果をキャッシュしてください。再度実行しても新しい情報は得られません。

プロジェクトのツールチェーンが不要な一時的な作業（1 回限りのコマンド、使い捨ての VM、簡単なプラットフォーム確認など）では、イメージの確認を完全に省略し、builtin:default を使用してください。Linux では、builtin:default に Go など一般的なツールチェーンがすでに含まれているため、多くのタスクではそれだけで十分です。一般に、より単純な Linux のケースでは builtin:default を使用し、依存関係を直接インストールしてください。

重要 --image には devbox image list -o json の短い name フィールド（例：<org>/<image> または builtin:default）を渡してください。完全な repository URL は渡さないでください。完全な参照は通常、失敗します。イメージが要求されたプラットフォームに対応していることを確認してください。

devbox create \
  --name <name> \
  [--platform <linux/amd64|macos/arm64>] \
  --image <image> \
  --size <size> \
  [--ephemeral] \
  [--checkout <repo-url>] \
  --purpose "<purpose>"

--platform を省略した場合、既定で Linux/amd64 が使用されます。タスクで macOS または Apple Silicon が必要な場合は、--platform macos/arm64 を渡してください。 タスク完了後に devbox を保持する必要がない場合は --ephemeral を追加し、保持する必要がある場合は省略します。

重要（デフォルトのワークスペースチェックアウト） --checkout が設定されていない場合、Namespace はワークスペースに設定されたデフォルトのリポジトリを使用して、自動的にクローンします。リポジトリが不要な場合（例：一度だけ実行するコマンド用の使い捨て VM）は、--no_checkout を指定してクローンを完全にスキップします。

--checkout <repo-url>（例：[email protected]:org/repo.git）は、リポジトリを /workspaces/<repo-name> にクローンします。リポジトリまたは組織のチェックアウトが利用できず、作成に失敗した場合：

1. 作成したばかりの devbox を削除します（devbox expire <name> --force）。これにより、容量が解放されます。
2. ローカルに gh がインストールされている場合は、--checkout を指定せずに devbox を再作成し、devbox setup-github <name> を実行して gh トークンを devbox に転送します。成功したら、devbox exec <name> -- 経由で devbox 内に git clone --depth=1 <repo-url> /workspaces/<repo-name> を実行します。大規模なモノレポでは、必ず --depth=1 を使用してください。フルクローンは進捗表示がほとんどないまま数分かかることがあり、停止したように見えるためです。重要 転送された gh トークンによる認証は HTTPS のみです。[email protected]:... ではなく、https://github.com/<org>/<repo>.git 経由でクローンしてください。
3. gh がインストールされていない場合、または devbox setup-github／devbox 内での git clone に失敗した場合は、GitHub 組織を Namespace にリンクするようユーザーに案内してください（https://cloud.namespace.so/workspace/workspace/integrations?integration=github）。リンクしないとチェックアウトできません。

重要（大文字と小文字を区別する組織スラッグ） Namespace の関連付け検索では、--checkout の GitHub 組織／オーナー部分の大文字と小文字が区別されます。ユーザーから提示されたリポジトリ URL（または git remote -v の出力）に記載された組織／オーナーの大文字と小文字を正確に使用してください。チェックアウトに失敗した際、「修正」として別の大文字・小文字の表記（例：組織名を小文字にする）を絶対に試さないでください。

Linux のサイズ：s（4 vCPU／8 GB）、m（8 vCPU／16 GB）、l（16 vCPU／32 GB）、xl（32 vCPU／64 GB）。macOS のサイズ：m（6 vCPU／14 GB）と l（12 vCPU／28 GB）。小さいサイズは、範囲の限られたコマンドや小規模な対象限定のワークロードにのみ使用します。依存関係が大きい場合や複数のパッケージをビルドする場合は、OOM を避けるため、より大きいサイズを選んでください。プロセスが signal: killed で終了した場合は、より大きいサイズに変更して再試行します。

作成とローカル準備を並行する devbox create はマシンの準備が完了するまでブロックし、数十秒かかります。その時間を活用しましょう。devbox create をバックグラウンドタスクとして実行し、すぐにローカルの git diff を計算して、セットアップスクリプトと実行スクリプトをローカルで作成します。作成が完了したら、アップロードして実行します。これにより、待ち時間をなくせます。

注 Namespace のプランでリソース階層やインスタンス数に制限がある場合、devbox の作成に失敗することがあります。その場合は、先に進む前にユーザーに確認してください。devbox list を実行し、利用可能な devbox を削除するか再利用するかを尋ねてから、再試行します。最終手段として、作業をより少ない devbox にまとめ、ブロックを避けてください。

シャーディングによって複数の devbox での実行が有効なテストやスクリプトについては、references/run-tests.md を参照してください。

2. ワークスペースにデータを展開し、ツールチェーンをインストールする

ファイルをアップロードおよびダウンロードする

devbox upload <name> <local-path>  <remote-path> [--mkdir]
devbox download <name> <remote-path> <local-path>

• <remote-path> は完全なファイルパスでなければなりません。末尾に / を付けると失敗します。
• --mkdir は存在しない親ディレクトリを作成します。対象をディレクトリにはしません。
• 実行ビットは保持されません。スクリプトをアップロードした後、devbox exec で chmod +x を実行します。
• /workspaces または $HOME の下に書き込んでください。 リモートユーザーは root ではなく、権限のない devbox（uid 1001）です。そのため、システムパスへのアップロードは親ディレクトリの権限不足で失敗します。mkdir: cannot create directory '/srv/www': Permission denied のようなエラーが発生します。原因はディレクトリが存在しないことではなく権限がないことなので、--mkdir でも解決できません。ページを配信しますか？ /srv や /var/www ではなく、/workspaces/<name>/ が適切な場所です。

ワークスペースを準備する

UI でリポジトリを設定した devboxes 名前空間では、起動時にリポジトリが /workspaces/<repo-name> に自動でクローンされます。同期する前に、必ずまずここを確認してください。

devbox exec <name> -- ls /workspaces/

リポジトリがすでに存在する場合は、そのパスをそのまま使ってください。自動クローンされたリポジトリはデフォルトブランチを反映しているため、ローカルの作業内容は含まれていません。何かを実行する前に、必ずその内容を反映させてください。

ファイルを網羅できる、最も手軽な同期方法を選んでください。 方法は 2 つあります。通常はシンプルな方法が適切です。

(a) 既定：作業ツリーを送信する。 小規模または中規模のリポジトリでは、ディスク上のファイルをそのままコピーします。これなら追跡対象の編集内容と未追跡ファイルを一度に取り込めます。コミットやベースについて考える必要がなく、何かが気づかないうちに抜け落ちることもありません。ファイルを数個直接アップロードするか、さらに多い場合はツリーを tar にまとめます。

# A few files - upload them directly.
devbox upload <name> ./calc.go /workspaces/<repo-name>/calc.go --mkdir

# More than a handful - tar the tree, excluding .git and build output.
tar --exclude .git -czf /tmp/tree.tgz -C <repo-root> .
devbox upload <name> /tmp/tree.tgz /tmp/tree.tgz
devbox exec   <name> -- mkdir -p /workspaces/<repo-name>
devbox exec   <name> -- tar -xzf /tmp/tree.tgz -C /workspaces/<repo-name>

(b) 大規模なリポジトリ：コミットを合わせてからパッチを適用する。 ツリーが、クローンよりコピーのほうが遅くなるほど大きくなったら、devbox 自身のクローンに作業の大部分を任せ、差分だけを送信します。こちらは手順がより複雑なため、(a) では本当に時間がかかりすぎる場合にだけ選んでください。

重要： devbox のクローンはデフォルトブランチ上にあるため、差分とチェックアウトで同じコミットを指定する必要があります。そうしないと、無関係なファイルが上書きされます。

BASE=$(git merge-base origin/main HEAD)
git diff "$BASE" > /tmp/changes.patch   # add --binary if the diff touches generated/binary files

# For git, prefer `git -C <path>` over `cd <path> && git ...` - no cwd to get wrong.
devbox exec   <name> -- git -C /workspaces/<repo-name> fetch --depth=1 origin "$BASE"
devbox exec   <name> -- git -C /workspaces/<repo-name> checkout "$BASE"
devbox upload <name> /tmp/changes.patch /tmp/changes.patch
devbox exec   <name> -- git -C /workspaces/<repo-name> apply /tmp/changes.patch
devbox exec   <name> -- git -C /workspaces/<repo-name> status --short

重要（(b) が危険になる失敗例）： git diff で対象になるのは追跡対象のファイルだけです。まだ git add していない新規ファイルは認識されないため、パッチによる同期では気づかないうちに抜け落ちます。そのファイルが新しいテストだった場合、実際には存在しなかったコードの結果を自信を持って報告することになります。したがって、(b) の方法だけでは不十分です。未追跡ファイルも送信してください。

git ls-files --others --exclude-standard    # exactly what a patch will MISS

未追跡ファイルは直接アップロードするか、tarball に追加するか、数が多ければ rsync で送信してください。

# for rsync - configure native ssh
devbox configure-ssh <name>
# After running this, you can connect with:
ssh <name>.devbox.namespace
# Then list untracked files and feed them to rsync
git ls-files --others --exclude-standard | \
  rsync -av --files-from=- . \
  <name>.devbox.namespace:/workspaces/<repo-name>/

結果を信頼する前に検証してください。 送るつもりだったファイルが実際に存在することを確認し、同期漏れが後で誤った回答につながる前に見つけましょう。

devbox exec <name> -- ls -la /workspaces/<repo-name>

リポジトリにリモートが一切ない場合（作業用またはローカル専用のリポジトリ）は、(b) の方法は使えません。(a) を使ってください。

ツールチェーンをインストールする

ツールが見つからない場合は、作業に必要なものだけをインストールしてください。

重要： インストールする前に、ツールがすでに存在するか確認してください。Linux では builtin:default に、Go など予想以上に多くのものが含まれています。手動でインストールする前に、コマンドを試してください。

ツール自体のフラグを使って確認してください。これは実行可能ファイルです。

devbox exec <name> -- go version

この方法では command -v は使えません。これはシェル組み込みであり、devbox exec はシェルを介さずコマンドを直接実行するため、devbox exec <name> -- command -v go は exec: "command": executable file not found in $PATH で失敗します。その結果、ツールが存在するのに見つからないように見えます。command -v を使う場合は、シェルを指定してください。

devbox exec <name> -- bash -lc 'command -v go >/dev/null && go version || echo MISSING_GO'

重要： スクリプトが使用する CLI ツールはすべて、存在を確認してから、見つからない場合にだけインストールしてください。プラットフォームに適したインストーラーと成果物を使ってください。たとえば Linux/amd64 では、次のようにします。

devbox exec <name> -- apt-get install -y --no-install-recommends \
    git ca-certificates curl tar build-essential
devbox exec <name> -- curl -fsSL -o /tmp/go.tgz https://go.dev/dl/go<version>.linux-amd64.tar.gz
devbox exec <name> -- tar -xzf /tmp/go.tgz -C /usr/local

3. devbox exec でコマンドを実行する

重要 異なる devbox に対する devbox exec の呼び出しは並列で実行してください。独立した作業を順番に実行しないでください。

devbox exec <name> -- <cmd> <args...>

devbox ssh <name> は、対話型シェルや TTY に依存するワークフローで引き続き利用できます。非対話型コマンドでは devbox exec を優先してください。

代替手段：ネイティブ SSH ワークフローで、scp や rsync などの標準 SSH ツールを利用するツールを使う場合は、devbox configure-ssh <name> を一度実行して、~/.ssh/config にエントリを書き込みます。その後、devbox には <name>.devbox.namespace としてアクセスできます。コマンドには devbox exec を優先し、標準ツールが特に必要な場合はネイティブ SSH を使用してください。

重要（exec はシェルを起動しませんが、シェルを指定できます） devbox exec はコマンドを直接実行するため、&&、;、リダイレクト、変数展開などのシェル演算子は、デフォルトでは解釈されません。devbox exec <name> -- cd /src && make は意図したとおりに動作しません。

複数ステップの作業を行う方法は 2 つあり、それぞれに異なるトレードオフがあります。

短い複数ステップの作業 ― シェルを明示的に呼び出す。 1 回の往復で済みますが、ミスをすると再実行が必要です。

devbox exec <name> -- bash -lc 'cd /workspaces/<repo-name> && go build ./... && go test ./...'

長めのロジックや再利用するロジック ― スクリプトをアップロードする。 ロジックが長い場合、慎重な引用符の処理が必要な場合、または実行した手順をマシン上に正確に記録したい場合は、余分な往復（upload、chmod、実行）を行う価値があります。スクリプトにバグがあると、再アップロードに加えて再度 chmod が必要になるため、試行錯誤している間は bash -lc を優先してください。

devbox upload <name> /tmp/script.sh /tmp/script.sh
devbox exec   <name> -- chmod +x /tmp/script.sh
devbox exec   <name> -- bash /tmp/script.sh

bash -lc では引用符に注意してください。プログラム全体をシングルクォートで囲み、リモートシェルで $VARS を展開させてください。そうしないと、コマンドがマシンを離れる前にローカルで展開されます。

デタッチされたコマンドと保持されるログ

長時間実行するコマンドには devbox exec -d を使用します。コマンドを開始してすぐに戻り、exec ID が出力されます。この ID を使って devbox logs で保持された出力と実行中の出力をストリーミングできます。devbox logs list では、過去の実行とその状態を確認できます。

devbox exec -d <name> -- <cmd> <args...>
# exec_<id>

devbox logs <name> <exec-id>
devbox logs list <name>

重要 set -e の前に、必要な CLI をすべて事前確認してください。ツールが見つからない場合に不明瞭なエラーではなく、明確なメッセージを出して終了させるためです。command -v <tool> >/dev/null || { echo "MISSING_TOOL: <tool>"; exit 127; }。終了コード 127 または MISSING_TOOL マーカーが出た場合は、依存関係をインストールして再実行してください。実行が失敗したと報告してはいけません。

重要 スクリプトの出力はすべてリモートのログファイルに書き込み、デフォルトでは短い要約のみを返してください。

cat > /tmp/run.sh <<'EOF'
#!/bin/bash
export PATH=/usr/local/go/bin:$PATH
command -v <tool> >/dev/null || { echo "MISSING_TOOL: <tool>"; exit 127; }
set -euo pipefail
mkdir -p /workspaces/tmp
export TMPDIR=/workspaces/tmp
LOG=/workspaces/run.log

cd /workspaces/<repo-name>
status=0
<workload-cmd> >"$LOG" 2>&1 || status=$?

echo "exit=$status log=$LOG bytes=$(wc -c <"$LOG")"
exit "$status"
EOF
devbox upload <name> /tmp/run.sh /tmp/run.sh
devbox exec   <name> -- chmod +x /tmp/run.sh
devbox exec   <name> -- bash /tmp/run.sh

# Pull the full log only if the summary shows a non-zero exit.
# devbox download <name> /workspaces/run.log /tmp/run.log

注 要約を出力する前に、ワークロードの終了コードを取得してください（status=0; cmd || status=$?）。特に指定がない限り、要約で終了コードがゼロ以外と報告された devbox に対してのみ devbox download を使用してください。

テストランナー固有のガイダンス（シャーディング、並列実行、ハイドレートしてテストする手順、結果の報告）については、references/run-tests.md を参照してください。

4. ライフサイクル

devbox create --name <name> [--platform <linux/amd64|macos/arm64>] --image <image> --size <size> [--ephemeral] [--checkout <repo-url>] --purpose "<purpose>"
devbox exec <name> -- <cmd>
devbox exec -d <name> -- <cmd>                                     # run in the background and print an exec ID
devbox logs <name> <exec-id>                                       # stream retained and live output
devbox logs list <name>                                            # inspect retained executions and status
devbox ssh <name>                                                  # open an interactive shell; prefer exec for commands
devbox list [-o json]                                              # inspect running devboxes
devbox upload <name> <local-path> <remote-path>                    # transfer files to devbox
devbox download <name> <remote-path> <local-path>                  # retrieve files from devbox
devbox configure-ssh <name>                                        # add to ~/.ssh/config for native ssh/scp/rsync
devbox url access <name> [--mode <private|workspace>] -o json      # inspect or change devbox.so access
devbox url expose <name> --port <port> [--name <purpose>] -o json  # create a persistent devbox.so URL
devbox url get <name> (--port <port> | --name <purpose>) -o json   # retrieve an exposed URL
devbox url list <name> -o json                                     # list exposed URLs
devbox url unexpose <name> (--port <port> | --name <purpose>)      # remove an exposed URL
devbox port-forward <name> --ports <local:remote,...>              # forward devbox ports to localhost (e.g. a dev server or DB)
devbox shutdown <name>                                             # stop a devbox without destroying it
devbox expire <name> --force                                       # tear down a devbox

長時間の作業中に devbox を起動したままにする

アイドルタイムアウトが設定された devbox は、ビジー状態とみなされるものが何もないと自動停止します。Devbox エージェントは、実行中の devbox exec コマンドまたは SSH コマンドを、その実行中ずっとビジー状態として扱います。ターミナルセッションの作成や接続、および公開された devbox.so URL 経由での HTTP レスポンスの受信は、一定期間に限り直近のアクティビティとしてカウントされます。アクティブな exec または SSH コマンドでカバーされない作業には、明示的なマーカーが必要です。

devbox exec <name> -- boxctl task mark <task>          # hold the devbox busy
devbox exec <name> -- boxctl task clear-mark <task>    # release it
devbox exec <name> -- boxctl task list                 # what is currently holding it

boxctl はすべての devbox にプリインストールされているため、ボックスに何もインストールせずに、手元のマシンから実行できます。devbox の内部から実行する場合は、devbox exec <name> -- のプレフィックスを省略してください。

アクティブな devbox exec コマンドまたは SSH コマンドの外で無人実行される作業には、すべてマーカーを付けてください。たとえば、ターミナルセッションで開始した夜間ジョブ、マイグレーション、キューワーカー、まだ誰もアクセスしていない開発サーバーなどです。フォアグラウンドまたはデタッチされた devbox exec は、コマンドの実行中であればマーカーは必要ありません。どちらの形式のアクティビティもない場合、マシンが作業の途中で停止し、作業が中断される可能性があります。 重要 マーカーには TTL がなく、クリーンアップする仕組みもありません。マーカーを残すと、devbox が起動したままになり、無期限に課金され、アイドルタイムアウトも完全に機能しなくなります。そのため、失敗時の経路も含め、必ずマーカーと対応する clear-mark をセットで使用してください。どちらのコマンドも冪等で、マーカーがすでに存在する場合や、すでに削除されている場合は終了コード 0 で終了するため、トラップや再試行でも安全に使用できます。トラップのパターンについては、references/inside-a-devbox.md を参照してください。

マーカーが延長するのは アイドル タイムアウトだけです。devbox shutdown と devbox expire は、引き続きマシンを停止します。

重要 これらの devbox url コマンドを使用するには、devbox CLI v0.0.182 以降が必要です。devbox version でバージョンを確認してください。インストール済みのバージョンが古い場合は、使用前に devbox update を実行してください。

devbox.so URL を開けるユーザーを選択する 各 devbox の公開 URL はすべて、共通のアクセスモードを使用します。

• private - devbox の所有者のみ。
• workspace - 同じ Namespace ワークスペースのメンバー。

URL のモードは、最初は devbox の一般的なアクセスモードに従いますが、その後は個別に設定されます。URL のアクセス設定を変更しても、devbox への SSH、exec、またはファイルアクセスの権限は付与も削除もされません。

Devbox 全体に適用される URL モードを個別に確認または変更します。

devbox url access my-box -o json
devbox url access my-box --mode workspace -o json

重要 devbox url expose ... --access <mode> は、ポートを公開する際に、この同じ Devbox 全体の設定を変更します。devbox 上で現在公開されているすべての URL と、今後公開されるすべての URL に影響します。新しい URL だけにアクセス権を設定するものではありません。URL ごとのアクセスモードには対応していません。URL ごとに異なる対象ユーザーが必要な場合は、アクセス権を変更する前に確認するか、別の devbox を使用してください。

チームメイトと Web 上の作業を共有する ユーザーが、devbox 内で実行中の作業をチームメイトがレビューできるようにしたい場合は、--access workspace を指定してポートを公開し、生成された devbox.so URL を返してください。URL はコマンドの終了後も利用できます。ポートの用途がわかっている場合は --name を指定すると、後で URL を取得したり削除したりしやすくなります。エージェントのワークフローでは JSON 出力を優先してください。

重要（公開 URL の確認方法と、してはいけない確認方法） URL を返す devbox url expose が成功した時点で、それが確認になります。そこで止めて、URL をユーザーに渡してください。

URL が機能することを「証明」するために、URL へのアクセスを試みないでください。devbox.so URL へのアクセスには、サインイン済みユーザーのセッションが必要ですが、あなたはそのセッションを持っておらず、取得することもできません。curl は 401 unauthorized を返します。また、どの API トークンや ID トークンを使っても状況は変わりません。この 401 は失敗ではなく、確認が必要なことを示すものでもありません。200 を追い求めるのは、このスキルで最も時間を浪費する行き止まりです。CLI がすでに示した事実を再確認するためだけに、トークンエンドポイントや SSH トンネルの調査に何分も費やすことになります。

共有する前に サーバー が実際に起動していることを確認したい場合は、ゲートウェイ認証の影響を受けない devbox 内から確認してください。

devbox exec <name> -- curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:<port>/

devbox.so プロキシからアクセスできるように、サーバーは 127.0.0.1 ではなく 0.0.0.0 にバインドしてください。

devbox url expose my-box --port 3000 --name web --access workspace -o json

ユーザーから共有を依頼されていない場合は、--access を省略し、現在のモードを維持してください。共有の意図が不明な場合は、モードを確認し、アクセス範囲を広げないでください。devbox 上で公開するすべての URL を所有者のみに限定するようユーザーが明示的に求めた場合は、新しいポートを公開する前に private を設定してください。

devbox url access my-box --mode private -o json
devbox url expose my-box --port 3000 --name web -o json

ローカルのみのアクセスや Web 以外のサービスには、devbox port-forward を使用してください。例：devbox port-forward my-box --ports 3000:3000,5432:5432 は、ポートを localhost:3000 と localhost:5432 にマッピングします。このコマンドは Ctrl+C を押すまでターミナルを占有するため、専用のターミナルで実行するか、バックグラウンドプロセスとして実行してください。

devbox expire を実行するか、いつ実行するかは、呼び出し元の意図によって異なります。references/run-tests.md にあるテストスイートのワークフローでは最後にクリーンアップしますが、ほかの用途では devbox を起動したままにすることもあります。

重要 依存関係の不足によって失敗した場合は、それらをインストールして失敗したコマンドを再試行してください。アップロードしたスクリプトについても同様にしてください。