Outposts

Outpostsは早期アクセス版です。ここで説明するAPIとCLIコマンドは変更される可能性があります。組織でOutpostsを有効にするには、担当のアカウントチームにお問い合わせください。

Outpostsを使うと、自社のVM、コンテナ、Kubernetesクラスター、さらにはデスクの下のMac Miniまで、管理しているインフラストラクチャ内でDevinセッションを実行できます。Devinのエージェントループ (推論と計画) は引き続きDevinのクラウド上で実行されますが、コマンドの実行、ファイルの編集、リポジトリへのアクセスはすべて、お客様が運用するマシン上で行われます。次のような場合は、Outpostsの利用を検討してください。

セッションを自社ネットワーク内で実行し、社内サービス、レジストリ、シークレットの近くで動かしたい
カスタムのハードウェアプロファイル (例: GPU、大容量メモリマシン、特定のOSイメージ) が必要
既存の開発環境、VM、またはKubernetesインフラストラクチャでDevinのワークロードをホストしたい
ネットワークアクセス、ビルド出力、モニタリングに対するEnterprise向けの制御機能が必要

仕組み

Outposts は 2 つのレイヤーで構成されています。

ワーカー (例: devin worker start) — キューに入っている 1 つのセッションを処理するために、マシン上で実行するバイナリです。Devin のクラウドへのアウトバウンド接続を確立し、セッションのツール呼び出しをローカルで実行します。このバイナリは Cognition が提供するため、自分で実装する必要はありません。Devin CLI には、このバイナリを取得して実行するためのロジックが含まれています。
オーケストレーター — 利用者が作成するソフトウェア (または調整して使う参照実装) です。fleet API を監視してワーカーを待機中のセッションを見つけ、セッションごとに VM またはコンテナをプロビジョニングし、その中でワーカーを起動します。Kubernetes などの一般的なプラットフォーム向けに、いくつかの参照実装を提供していますが、これらは自由に調整して利用したり (オープンソースです!)、独自に作成したりできます。

ワーカーに必要なのは アウトバウンド の HTTPS アクセスだけです。インバウンドポート、公開 IP、VPN トンネルは不要です。ユーザーが Devin Cloud でセッションを開始し、登録済みの outpost の 1 つを選択すると、そのセッションはその outpost のキューに入ります。オーケストレーターがそれを引き取り、マシンを起動してワーカーを実行します。セッションが終了すると、ワーカーは終了し、オーケストレーターがマシンを削除します。

前提条件

Outposts が有効化されている組織
適切な Outposts スコープを持つ v3 APIトークン:
- outposts を管理するオーケストレーター向けの account.outposts.orchestrator (マシンスコープを含む)
- キューの読み取りとセッションの引き取り・解放を行うワーカー向けの account.outposts.machine
以下を備えたマシンイメージ (VM またはコンテナ) :
- Devin CLI がインストールされている
- 以下のマシンの依存関係
- リポジトリがクローンされ、リモートが設定されている
- セッションに必要なビルドツール、パッケージレジストリ、シークレット、内部サービスにアクセスできる

マシンの依存関係

セッションは使用中のマシン上で直接実行されるため、ワーカーはそのマシンにインストールされたツールを利用します。必須

依存関係	用途
`git` (`PATH` 上)	クローン作成と、すべてのリポジトリ操作

任意 — 特定の機能を有効にするには、以下をインストールしてください。

依存関係	機能
`ffmpeg` (`PATH` 上)	Devin の画面録画機能。これがない場合、セッションで画面を録画できません。
Chrome または Chromium	Browser およびコンピュータ操作機能。ワーカーはデフォルトで標準的なインストール先から Chrome を探します。別の場所を利用する場合は、ワーカーの環境変数 `DEVIN_CHROME_PATH` に実行ファイルの絶対パスを設定してください (例: `DEVIN_CHROME_PATH=/usr/bin/google-chrome`) 。これがない場合、ブラウザツールは利用できません。
パスワード不要の `sudo`	セッション中に必要なソフトウェア (例: 不足しているビルドツールやシステムパッケージ) を Devin がインストールできるようにします。これは、マシンが Devin 専用で、各セッション後に再作成される場合にのみ許可してください。共有マシンや長期間使用するマシンでは、絶対に許可しないでください。

クイックスタート: アウトポストを作成してワーカーを起動する

この手順では、devin worker start を使って 1 台のマシン上にアウトポストを作成し、運用します。オーケストレーターは不要です。これは開発用マシンで Outposts を試す最も手早い方法であり、大規模運用ではオーケストレーターも同じワーカーコマンドを実行します。

1. サービスユーザートークンを作成する

ワーカー (および任意のオーケストレーター) は、サービスユーザー に属する v3 APIトークンを使用して Outposts API に認証します。以下のロール権限により、このトークンに Outposts のスコープ (UseOutpostsMachine → account.outposts.machine、ManageOutpostsOrchestrator → account.outposts.orchestrator) が付与されます。Devin の web app で次を行います。

Outposts へのアクセス権を持つ ロールを作成 します。Settings → Roles で Enterprise ロールを追加し、Outpost permissions で Use outpost machine (UseOutpostsMachine) を有効にします。このサービスユーザーがアウトポストを作成または削除する場合は、Manage outposts (ManageOutpostsOrchestrator) も有効にします。
サービスユーザーをプロビジョニングします。 Settings → Devin API → Service users で Provision service user をクリックし、名前 (例: outposts-worker) を付け、手順 1 で作成したロールを割り当てて、有効期限を設定します。
トークンをコピーします。 cog_... トークンは作成時に 一度だけ 表示されます。今すぐコピーしてください。後から取得することはできません。

以下のコマンドで使えるように、これを export します。

export DEVIN_OUTPOSTS_TOKEN="cog_..."

2. アウトポストを作成する

アウトポストは、お使いのインフラストラクチャが提供する、セッション用の名前付きキューです。Devin CLI がインストールされた任意のマシンから作成できます。

devin worker outpost create my-outpost --platform linux --description "Dev boxes in our VPC"

このコマンドを実行すると、新しいアウトポストの ID (outpost_env-...) が表示されます。次のステップで使うので、控えておいてください。アウトポストは、Webアプリの Settings → Outposts から、または outposts API 経由でも作成できます。作成したアウトポストは、セッション開始時に、Devin Cloud のマシンオプションとして (Ubuntu や Windows などと並んで) 表示されます。

3. ワーカーを起動する

セッションを処理するマシンで、Devin CLI とマシンの依存関係をインストールし、チェックアウト済みのリポジトリがあるディレクトリからワーカーを起動します：

cd /path/to/repos
devin worker start --outpost=<outpost_id>

ワーカーはアウトポストのキューを定期的にポーリングし、保留中の最初のセッションを引き取り、適切な devin-remote バイナリをダウンロードして、そのセッションを実行します。セッションが終了すると、キューに戻って次のセッションを待機します。代わりに、1 つのセッションを実行したら終了するには --once を、特定の 1 つのセッションを引き取って実行するには --session=<session_id> を指定します。 --token と DEVIN_OUTPOSTS_TOKEN の両方が未設定の場合、コマンドはエラーになります。対話型ターミナルで --outpost を省略すると、ワーカーはアカウントのアウトポストから選択するよう求めます。

4. アウトポストでセッションを開始する

Devin Cloud で新しいセッションを開始し、マシンとして自分のアウトポストを選択します。セッションはキューに入るとワーカーに引き取られ、実行が自分のマシン上で開始されます。より多くのセッションを同時に処理するには、同じアウトポストを指定して複数のマシンでワーカーを実行します — 中央集約なしのスケジューリングを参照してください。

Kubernetes 上で実行していますか？オープンソースの devin-outpost-k8s オペレーターは Helm でインストールでき、任意の認定済みクラスター (GKE、EKS、…) 上でアウトポスト用のワーカーを実行できます。そのリポジトリをクローンした環境から、次を実行します。

helm install outposts charts/devin-outposts-k8s \
  --set defaultPool.enabled=true \
  --set defaultPool.poolId=<outpost_id> \
  --set defaultPool.token.value="$DEVIN_OUTPOSTS_TOKEN"

基本的な流れ

1. アウトポストを登録する

アウトポストとは、貴社のインフラストラクチャで複数のワーカーによって処理される、名前付きセッションのキューです (たとえば rhel、gpu-h200、my-outpost など) 。devin worker outpost create を使って作成します。

devin worker outpost create <name> --platform <platform> --description "..."

登録が完了すると、セッション開始時に、そのアウトポストが Devin Cloud のマシンオプションとして表示されます (Ubuntu や Windows などと同様) 。そのアウトポストを対象とするセッションは、ワーカーが引き取るまで、そのキューで待機します。

fleet API では、アウトポストは outposts リソースとして表され、アカウント単位でスコープされます (所属するすべての組織で共有されます) 。

2. fleet APIをポーリングして待機中のセッションを確認する

オーケストレーターは、担当するOutpostsの保留中のセッションを一覧で取得します:

curl -H "Authorization: Bearer $DEVIN_API_TOKEN" \
  "https://api.devin.ai/opbeta/outposts/devins?outpost=<outpost_id>&phase=pending"

一覧レスポンスでは、キューに入っているセッションは items に格納されます:

{
  "items": [
    {
      "metadata": {
        "session_id": "devin-...",
        "outpost_id": "outpost_env-...",
        "created_at": 1781050000,
        "updated_at": 1781050000
      },
      "spec": {
        "kind": "new",
        "platform": "linux",
        "remote_binary_sha": null
      },
      "status": {
        "phase": "pending",
        "acceptor_id": null,
        "claim_deadline": null,
        "session_status": "pending"
      }
    }
  ],
  "cursor": "djE6MTc4MTA1MDAwMC4w",
  "has_next_page": false,
  "total": 1
}

レスポンスのカーソルを利用して、キュー全体を繰り返し照合することなくページネーションします。first をページサイズ (最大 200) に設定し、その後、 has_next_page が true の間は各レスポンスの cursor を次のリクエストに渡します:

curl -H "Authorization: Bearer $DEVIN_API_TOKEN" \
  "https://api.devin.ai/opbeta/outposts/devins?outpost=<outpost_id>&first=200&cursor=<cursor>"

このAPIは少なくとも1回配信されることを保証します。ページ境界にあるセッションは両方のページに含まれることがあるため、すべての項目を新規として扱うのではなく、 metadata.session_id でエントリをアップサートしてください。has_next_page が false になったら、返されたカーソルを watch API の開始位置として保存してください。

変更を監視する

最初の一覧取得後、最後のカーソルを使って Server-Sent Events (SSE) による監視を開始します:

curl -N -H "Authorization: Bearer $DEVIN_API_TOKEN" \
  "https://api.devin.ai/opbeta/outposts/devins?outpost=<outpost_id>&watch=true&cursor=<cursor>"

ストリームは、セッションのキューエントリに変更があると MODIFIED イベントを送信し、削除されると DELETED イベントを送信します。新たにキューに入ったセッションも MODIFIED イベントとして届きます。各 SSE data フィールドには、次の形式の JSON が含まれます:

{
  "type": "MODIFIED",
  "object": {
    "metadata": {
      "session_id": "devin-...",
      "outpost_id": "outpost_env-...",
      "created_at": 1781050000,
      "updated_at": 1781050100
    },
    "spec": {
      "kind": "new",
      "platform": "linux",
      "remote_binary_sha": null
    },
    "status": {
      "phase": "pending",
      "acceptor_id": null,
      "claim_deadline": null,
      "session_status": "pending"
    }
  },
  "cursor": "djE6MTc4MTA1MDEwMC4w"
}

各イベントの処理後に、その最上位の cursor を保存してください。接続が切れた場合は、最後に保存したカーソルで再接続し、切断中に発生した変更を再取得します。watch の配信も少なくとも 1 回であるため、クライアントは重複イベントを許容する必要があります。ストリームは最長 5 分で終了するため、再接続する watch ループを前提としています。 outpost フィルターは list リクエストと watch リクエストの両方に適用されます。phase と acceptor_id のフィルターは list リクエストにのみ適用され、watch=true の場合は無視されます。watch しているイベントは、各イベントの object にあるフィールドを使って絞り込んでください。カーソルを省略すると先頭から開始されるため、通常の整合処理には list-then-watch を利用してください。セッション用のマシンを起動する前に、他のワーカーに取得されないよう、アトミックに引き取ってください。acceptor_id を渡します。これは、ワーカーが自身で申告する識別情報です:

curl -X POST -H "Authorization: Bearer $DEVIN_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"acceptor_id": "worker-1"}' \
  "https://api.devin.ai/opbeta/outposts/devins/{session_id}/claim"

引き取り処理はアトミックです。別のワーカーが先にそのセッションを引き取っていた場合は、409 が返されます。引き取りを行うと、サーバーによって割り当てられた引き取り期限 (status.claim_deadline) までにワーカーの準備が整うことが保証されます。期限切れになった引き取りは自動的にキューに戻されます。プロビジョニングに失敗した場合は、引き取りを解放してセッションがただちにキューに戻るようにしてください:

curl -X POST -H "Authorization: Bearer $DEVIN_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"acceptor_id": "worker-1"}' \
  "https://api.devin.ai/opbeta/outposts/devins/{session_id}/release"

3. マシンを起動してワーカーを実行する

引き取った各セッションについて、イメージから VM またはコンテナをプロビジョニングします。その中で、セッションのリポジトリがすでにチェックアウトされているディレクトリでワーカーを実行します:

cd /path/to/repos
devin worker start --session=<session_id> --outpost=<outpost_id> --acceptor-id=<worker_id>

セッションのすべてのリポジトリは、devin worker start を実行する作業ディレクトリを基準とした相対パスでチェックアウトされている必要があります。

repos

app

.git

infra

.git

この例では、repos/ で devin worker start を実行すると、セッションは作業ディレクトリからの相対パスとして app/ と infra/ を認識します。便利なフラグ:

Flag	Description
`--session`	処理するセッションを指定します。セッションが終了すると、ワーカーも終了します。
`--outpost`	処理するセッションの outpost を指定します。
`--acceptor-id`	このワーカーの API claim と同じ acceptor ID を使用します。
`--token`	ワーカー用の省略可能な認証トークンです。省略した場合、ワーカーは `DEVIN_OUTPOSTS_TOKEN` を使用します。どちらも設定されていない場合、コマンドはエラーになります。

使用例:

devin worker start --session=<session_id> --outpost=<outpost_id> --acceptor-id=<worker_id> --token="<token>"
DEVIN_OUTPOSTS_TOKEN="<token>" devin worker start --session=<session_id> --outpost=<outpost_id> --acceptor-id=<worker_id>

ワーカーはDevinのクラウドに接続し、セッションを準備完了にして、ツール呼び出しの実行を開始します。

4. リモートバイナリを直接取得する

devin worker start コマンドは、適切な devin-remote バイナリを自動的にダウンロードします。Devin CLI を利用しないカスタムオーケストレーターを構築する場合は、次の場所からバイナリを直接取得できます。

https://static.devin.ai/devin-rs/remote/

最新バージョンを確認する:

# プラットフォーム向けの最新公開バイナリのgit SHAを返します
curl -fsSL "https://static.devin.ai/devin-rs/remote/latest_linux_x64"

ダウンロードして検証する:

SHA=$(curl -fsSL "https://static.devin.ai/devin-rs/remote/latest_linux_x64")

# バイナリをダウンロード
curl -fL "https://static.devin.ai/devin-rs/remote/devin-remote_${SHA}_linux_x64" \
  -o devin-remote

# チェックサムをダウンロードして検証
curl -fsSL "https://static.devin.ai/devin-rs/remote/devin-remote_${SHA}_linux_x64.sha256" \
  -o devin-remote.sha256
echo "$(cat devin-remote.sha256)  devin-remote" | sha256sum -c

chmod +x devin-remote

利用可能なプラットフォーム:

接尾辞	OS / アーキテクチャ
`linux_x64`	Linux x86_64
`macos_arm64`	macOS Apple Silicon
`windows_x64.exe`	Windows x86_64

セッションのキューエントリに spec.remote_binary_sha が含まれている場合は、latest ではなくその SHA を利用してください。これにより、セッションは特定のテスト済みバージョンに固定されます。

起動時の仕様

オーケストレーターが devin-remote を直接起動する場合は、次のようにします:

devin-remote serve

次の環境変数を設定します。

Variable	Required	Description
`DEVIN_OUTPOST_GATEWAY_URL`	はい	Outpost gateway のベース URL (例: `wss://outpost-gateway.devin.ai`) 。
`DEVIN_OUTPOST_CONNECT_TOKEN`	はい	gateway 用の Bearer 接続トークン。引き取りのレスポンスから取得します。
`DEVIN_OUTPOST_SESSION_ID`	はい	対象のセッション ID。3 つの `DEVIN_OUTPOST_*` 変数は必ずまとめて設定する必要があります。
`DEVIN_REMOTE_STATE_DIR`	強く推奨	リモートが認証情報、トークン、Shell 統合ファイルを保存する、セッションごとの状態ディレクトリ。セッションごとに一意のディレクトリを使用してください (例: `~/.devin/worker/sessions/<session_id>`。これは `devin worker` が使用するパスです) 。未設定の場合、リモートは共有のシステム全体のデフォルト (Linux では `/opt/.devin`、macOS では `~/.devin`、Windows では `C:\ProgramData\devin`) にフォールバックします。この場合、そのディレクトリは存在し、書き込み可能である必要があり、さらに並行実行中のセッション間でセッションごとの状態が漏れる原因になります。必ず設定してください。
`DEVIN_CHROME_PATH`	任意	Browser ツール用の、そのマシン上の Chrome/Chromium バイナリへのパス (Outposts では Devin 管理の Chrome は提供されません) 。
`DEVIN_OUTPOST_DESKTOP`	任意	デスクトップ (VNC) ストリームを有効にするには `true` に設定します。リモート側では必要になった時点で初めて有効化され、ビューアーが接続するまで何もキャプチャされないため、常に有効にしておいても安全です。

リモートには、上記の変数に加えて、基本的なシステム変数 (PATH、HOME、USER、LOGNAME、TMPDIR、LANG、TZ、および Linux/X11 でデスクトップストリームの画面キャプチャに必要な DISPLAY、WAYLAND_DISPLAY、XAUTHORITY) だけを含むクリーンな環境を渡してください。エージェントに見せるべきでないものは、リモートに漏らさないでください。これらはエージェントの Shell に引き継がれます。追加のライフサイクルに関する前提:

作業ディレクトリ: セッションのリポジトリを含むディレクトリからリモートを起動します (devin worker start と同じルールです) 。
セッション終了: セッションが終了したとき (sleep 状態になる、または終了する) 、Devin はリモートに通知し、リモートは自動的にステータス 0 で終了します。正常終了はセッション終了として扱ってください。キューエントリの status.session_status が suspended または terminated であることを確認し (ステータス更新は終了から数秒遅れることがあるため、数回読み直してください) 、その後引き取りを解放します。フォールバックとして、リモートの実行中にも status.session_status をポーリングし、terminated に達した時点 (またはキューエントリが消えた時点) で自分でプロセスを終了してください。

5. ワーカーの終了時にマシンを終了する

devin worker start が終了すると、セッションも終了するか、一時停止状態になります。VM またはコンテナを終了してください。outpost が再開に対応している場合は、セッション再開時に復元できるよう、終了前にマシンのスナップショットを作成してください。オーケストレーターは、引き取ったセッションとその状態を追跡できます。

curl -H "Authorization: Bearer $DEVIN_API_TOKEN" \
  "https://api.devin.ai/opbeta/outposts/devins?phase=claimed&acceptor_id=worker-1"

各エントリは、status.session_status として pending、running、suspended、または terminated を返します。

中央集約なしのスケジューリング

約16台を超えるコーディネーター (outpost を監視して引き取るワーカーまたはオーケストレーター) を実行する予定がある場合は、まず担当のアカウントチームにご連絡ください。大規模なフリートでは引き取り競合とキュー読み取り負荷が増大するため、その規模に対応できるよう outpost が適切にプロビジョニングされていることを事前に確認したいからです。

フリートを運用するのに、中央スケジューラーは必要ありません。キュー API は、多数の独立したワーカーが互いに通信することなく同じ outpost を処理できるよう設計されています。

調整の仕組みは引き取りだけです。 すべてのワーカーはそれぞれ独立してキューを監視し、保留中のセッションの引き取りを競います。引き取りはサーバー上で原子的に実行される compare-and-swap です。勝てるワーカーは必ず1台だけで、負けたワーカーは 409 を受け取り、そのまま次の保留中セッションに進みます。引き取り競争に負けるのはエラーではなく、通常の動作です。
各ワーカーは固有の ID を持ちます。 acceptor_id によって、そのワーカーの引き取り、更新、再起動後の復旧は、そのワーカー自身にのみ紐づけられます。devin worker start はマシンごとにこれを自動生成して保存するため、フリート側で ID を設定する必要はありません。マシン間で acceptor ID (またはコピーしたワーカーデータディレクトリ) を共有しないでください。ワーカー同士が衝突し、互いの引き取りを奪い合う原因になります。
障害は自動的に回復します。 ワーカーが引き取り後に停止した場合でも、引き取り期限に達するとその引き取りは失効し、セッションは別のワーカーが取得できるようキューに戻ります。フリート全体のヘルス状態を追跡する必要はありません。

つまり、スケールアウトは同じ outpost を向くワーカーをより多くのマシンで実行するだけです。N 台のマシンがあれば N 個のセッションを同時に処理でき、それ以外は保留状態で待機します。運用上の注意点が2つあります。

完全な一覧を何度も取得するのではなく、watch エンドポイントを利用してください。 まずページネーション付きの一覧取得を1回実行して初期状態を構築し、その後は返されたカーソルから watch stream を維持してください。すべてのワーカーがキュー全体を再ポーリングするとスケールしにくくなり、引き取りの遅延も増えます。watch stream であれば、変更を発生時に受け取れます。
1つの outpost で約16台を超える前にご相談ください。 調整不要の引き取りは小規模なフリートではうまく機能しますが、フリートが大きくなるほど引き取り競合とキュー読み取り負荷が増大します。単一の outpost に対して約16台を超えるワーカーを実行する予定がある場合は、まず担当のアカウントチームにご連絡ください。その規模に対応できるよう、outpost が適切にプロビジョニングされていることを確認します。

API リファレンス

すべての Outposts エンドポイントは https://api.devin.ai/opbeta 配下にあり、共通のリソース形式 (metadata / spec / status) を持ちます。一覧レスポンスは items、cursor、has_next_page、total を返します。

Devins (`/outposts/devins`)

エンドポイント	説明
`GET /outposts/devins?outpost=...&phase=pending`	ワーカーを待機中のセッションを一覧表示します。
`GET /outposts/devins?outpost=...&first=...&cursor=...`	前回のレスポンスのカーソルから、ページ分割された一覧の続きを取得します。
`GET /outposts/devins?outpost=...&watch=true&cursor=...`	一覧または watch のカーソル以降の `MODIFIED` および `DELETED` イベントをストリーミングします。
`GET /outposts/devins?phase=claimed&acceptor_id=...`	指定した acceptor が引き取ったセッションを一覧表示します。
`GET /outposts/devins/{session_id}`	単一のキューエントリを取得します。
`POST /outposts/devins/{session_id}/claim`	セッションをアトミックに引き取ります (すでに引き取られている場合は `409`) 。Body: `{"acceptor_id": "..."}`.
`POST /outposts/devins/{session_id}/release`	解放し、セッションをキューに戻します。Body: `{"acceptor_id": "..."}`.

Outposts (`/outposts`)

Endpoint	説明
`GET /outposts`	アカウントのOutpostsを一覧表示します。
`POST /outposts`	Outpostを作成します。Body: `{"name": "my-outpost", "platform": "linux", "description": "..."}`.
`GET /outposts/{outpost_id}`	指定したOutpostを取得します。
`DELETE /outposts/{outpost_id}`	Outpostを削除します (アクティブな引き取りがある間は `409`) 。

{
  "metadata": {
    "outpost_id": "outpost_env-...",
    "account_id": "...",
    "created_at": 1781050000
  },
  "spec": {
    "name": "my-outpost",
    "platform": "linux",
    "description": "..."
  },
  "status": {
    "queue_depth": 3,
    "active_claims": 2
  }
}

status.queue_depth と status.active_claims は、オートスケーリングの判断に役立つシグナルです。キューに処理待ちが溜まっている場合、オーケストレーターはウォームマシンをさらにプロビジョニングできます。

ワーカーでできること

Outpostsワーカー上で実行されるセッションは、フル機能を備えたDevinセッションです。スキル、Knowledge、MCPサーバー、シークレットはすべてDevin Cloudと同様に利用でき、ワーカーの接続を通じて提供されます。リポジトリ、ビルドキャッシュ、ツールの実行はお使いの環境内に保持され、スクリーンショットなどのセッション成果物はDevin Cloudにアップロードされるため、セッション内およびPRで閲覧できます。

Outpostセッションには厳格な準備完了タイムアウトがあります。オーケストレーターがセッションを引き取った後、引き取り期限までにワーカーが接続する必要があります。そうしないと引き取りは失効し、タイムアウト時間中に発生した固定費用と時間単位の費用は請求されます。

概要

基本ガイドライン

Devin の導入

Devin の使い方

製品ガイド

統合

管理

リリースノート

仕組み

前提条件

マシンの依存関係

クイックスタート: アウトポストを作成してワーカーを起動する

1. サービスユーザートークンを作成する

2. アウトポストを作成する

3. ワーカーを起動する

4. アウトポストでセッションを開始する

基本的な流れ

1. アウトポストを登録する

2. fleet APIをポーリングして待機中のセッションを確認する

変更を監視する

3. マシンを起動してワーカーを実行する

4. リモートバイナリを直接取得する

起動時の仕様

5. ワーカーの終了時にマシンを終了する

中央集約なしのスケジューリング

API リファレンス

Devins (`/outposts/devins`)

Outposts (`/outposts`)

ワーカーでできること

​仕組み

​前提条件

​マシンの依存関係

​クイックスタート: アウトポストを作成してワーカーを起動する

​1. サービスユーザー トークンを作成する

​2. アウトポストを作成する

​3. ワーカーを起動する

​4. アウトポストでセッションを開始する

​基本的な流れ

​1. アウトポストを登録する

​2. fleet APIをポーリングして待機中のセッションを確認する

​変更を監視する

​3. マシンを起動してワーカーを実行する

​4. リモートバイナリを直接取得する

​起動時の仕様

​5. ワーカーの終了時にマシンを終了する

​中央集約なしのスケジューリング

​API リファレンス

​Devins (/outposts/devins)

​Outposts (/outposts)

​ワーカーでできること

仕組み

前提条件

マシンの依存関係

クイックスタート: アウトポストを作成してワーカーを起動する

1. サービスユーザートークンを作成する

2. アウトポストを作成する

3. ワーカーを起動する

4. アウトポストでセッションを開始する

基本的な流れ

1. アウトポストを登録する

2. fleet APIをポーリングして待機中のセッションを確認する

変更を監視する

3. マシンを起動してワーカーを実行する

4. リモートバイナリを直接取得する

起動時の仕様

5. ワーカーの終了時にマシンを終了する

中央集約なしのスケジューリング

API リファレンス

Devins (`/outposts/devins`)

Outposts (`/outposts`)

ワーカーでできること