Skip to main content
一般的な言語やユースケース向けに、コピー&ペーストして使えるブループリントを用意しています。これらを組み合わせて、完全な configuration を構築してください。使用例は Linux 上の Bash を前提としています。サンプルのホスト、scope、コマンドはご自身の環境に合わせて置き換えてください。 各フィールドの詳細については、Blueprint reference を参照してください。
シークレット: 各ブループリントエディタ内の Secrets タブで、名前付きシークレットを configure してください。build step には該当するブループリントのシークレットが渡されます。セッション中は、各コマンドが必要なシークレットを確実に受け取れるようにしてください。repo scope のシークレットには、env={"REGISTRY_TOKEN": "secret:repo:owner/repo:REGISTRY_TOKEN"} のように exec の environment バインドを明示的に指定する必要があります。詳しくは Secrets を参照してください。認証情報をブループリントにハードコードしないでください。
build step はセッション起動時のフックではありません。 initialize と maintenance はスナップショットの build 中に実行されます。maintenance はセッション開始時に自動実行されるわけではありません。knowledge は Devin に instructions を提供するものであり、実行可能なフックではありません。$ENVRC を含め、永続的なファイルに認証情報を残さないでください。スナップショットのクリーンアップで削除されるのは Devin が注入したシークレットファイルであり、ユーザーのコマンドが書き込んだ任意のファイルは削除されません。利用するツールがサポートする変数参照をそのまま使うか、コマンドの environment で認証情報を渡してください。ツールが認証情報ファイルを必要とする場合は、1 回の操作のためだけに作成し、終了前にクリーンアップしてください。セッション内で必要になった場合は、その setup を都度明示的に繰り返してください。

クイックスタート

よくあるセットアップ向けの最小構成のブループリントです。1 つをコピーしてブループリントエディタに貼り付ければ完了です。

リポジトリのブループリント

リポジトリごとのビルド手順、依存関係管理、Knowledge エントリ。これらは Settings > Environment > Blueprints > [ご利用のリポジトリ] で設定します。

Python

依存関係の管理に uv を利用する Python プロジェクト向けの推奨セットアップです。

Node.js

npm を使う標準的な Node.js のセットアップです。
maintenance では npm ci ではなく npm install を利用してください。npm install は差分更新を行いますが、npm ci はコマンドが実行されるたびに node_modules を削除し、すべてを最初から再インストールします。

Go

モジュールを使用した標準的なGoのセットアップ。

Java

Gradle を使用する Java のセットアップ。
JDK 17 は Devin のベースイメージにプリインストールされています。デフォルトの OpenJDK 17 で十分な場合は、JDK のインストール手順をスキップしてください。

Ruby on Rails

PostgreSQL を使用する Rails のセットアップ。

Rust

cargo を使った標準的な Rust のセットアップ。
Rust (rustup 経由) と Cargo は、Devin のベースイメージにあらかじめインストールされています。デフォルトの安定版ツールチェーンで十分な場合は、インストール手順は省略できます。必要なのは依存関係の取得だけです。

モノレポ

Node.js のフロントエンドと Python のバックエンドを持つモノレポです。各サブプロジェクトには、それぞれ専用のKnowledge エントリを設定します。
ステップ間で作業ディレクトリがリセットされるように、cd dir && command ではなくサブシェル (cd dir && command) を利用してください。

非公開パッケージレジストリ

非公開レジストリから依存関係を解決するようにパッケージマネージャーを設定します。設定は Settings > Environment > Blueprints > Org-wide setup で行います (1つのリポジトリでのみ必要な場合はリポジトリ単位で設定) 。
展開済みの認証情報ではなく、参照を保存してください。 <<'EOF' のように引用符付きのヒアドキュメント区切り文字を使うと、ファイル内に変数参照がそのまま保持されます。npm、Yarn Berry、Maven、Gradle は、実行時に以下の参照を解決できます。pip は pip.conf 内のシェル変数を展開しないため、代わりに環境変数を利用してください。シェルのセットアップファイルは、ツールと同じコマンド内で明示的に読み込む必要があります。新しいシェルが自動的に読み込んだり、認証情報を更新したりすることを前提にしないでください。Cargo のインデックス、Docker ミラー、APT ミラーなど、永続的な設定に直接書き込む URL に認証情報を含めてはいけません。認証は、各テンプレートで示されている個別のシークレットに分離して保持してください。認証情報をディスクに書き込む古いテンプレートを利用していた場合は、該当ファイルを削除し、それらを含むスナップショットではなくクリーンなベースから再ビルドしてください。漏洩した可能性のある認証情報はローテーションしてください。
非公開レジストリが企業の CA を利用している場合は、まず CA 証明書 が Enterprise レベルでインストールされていることを確認してください。以下の設定は、HTTPS の信頼関係がすでに確立されていることを前提としています。

Node.js レジストリ

npm を設定して、スコープ付きパッケージ (例: @myorg/*) は非公開レジストリから取得し、公開パッケージは引き続きデフォルトの npm レジストリから取得するようにします。
  • GITHUB_PACKAGES_TOKEN — read:packages スコープを持つパーソナルアクセストークン、または GitHub App トークン
@myorg は実際の npm スコープに置き換えてください。一般的な非公開レジストリ URL:
  • GitHub Packages: https://npm.pkg.github.com
  • Artifactory: https://artifactory.example.com/artifactory/api/npm/npm-virtual
  • Nexus: https://nexus.example.com/repository/npm-group
  • GitLab: https://gitlab.example.com/api/v4/packages/npm
  • AWS CodeArtifact: https://<domain>.d.codeartifact.<region>.amazonaws.com/npm/<repo>

Python レジストリ

pip と uv が非公開の PyPI レジストリ (例: Nexus、Artifactory) からパッケージを取得できるように設定します。
  • PYPI_REGISTRY_URL — 必要に応じて認証情報を含む、PyPI インデックスの完全な URL (例: https://user:token@nexus.example.com/repository/pypi-proxy/simple)
ビルド中に依存関係を事前に取得しておくには、設定ステップの後に同じ source ... && コマンドを maintenance に追加します。URL の認証情報に含まれる特殊文字はパーセントエンコードしてください。
一般的な PyPI レジストリ URL パターン:
  • Artifactory: https://artifactory.example.com/artifactory/api/pypi/pypi-virtual/simple
  • Nexus: https://nexus.example.com/repository/pypi-proxy/simple
  • AWS CodeArtifact: https://aws:TOKEN@domain-owner.d.codeartifact.region.amazonaws.com/pypi/repo/simple/
  • Azure Artifacts: https://pkgs.dev.azure.com/org/project/_packaging/feed/pypi/simple
  • GitLab: https://gitlab.example.com/api/v4/groups/<group-id>/-/packages/pypi/simple

JVM 用レジストリ

JDK をインストールし、すべての依存関係の解決が非公開レジストリ (例: Artifactory、Nexus) を経由するように Maven を設定します。
Devin のベースイメージには JDK 17 がプリインストールされています。デフォルトの OpenJDK 17 で十分な場合は、インストール手順をスキップしてください。必要なのは Maven のインストールとレジストリ設定のみです。
  • MAVEN_REGISTRY_URL — Maven レジストリの URL (例: https://artifactory.example.com/artifactory/maven-virtual)
  • REGISTRY_USER — レジストリのユーザー名
  • REGISTRY_PASS — レジストリのパスワードまたは API トークン
Mavenでよく使われるレジストリURLのパターン:
  • Artifactory: https://artifactory.example.com/artifactory/maven-virtual
  • Nexus: https://nexus.example.com/repository/maven-public
  • Azure Artifacts: https://pkgs.dev.azure.com/org/project/_packaging/feed/maven/v1
  • GitHub Packages: https://maven.pkg.github.com
  • GitLab: https://gitlab.example.com/api/v4/groups/<group-id>/-/packages/maven
  • AWS CodeArtifact: https://<domain>.d.codeartifact.<region>.amazonaws.com/maven/<repo>

その他のレジストリ

Go をインストールし、非公開のモジュールプロキシ (Athens、Artifactory、GOPROXY エンドポイントなど) 経由でモジュールを解決するように設定します。
  • GO_PROXY_URL — Go モジュールプロキシの URL (例: https://athens.corp.internal)
Git provider を接続し、Git 統合を通じて非公開モジュールをホストするリポジトリへのアクセスを許可します。Devin に設定済みの認証情報を用いて、通常の HTTPS 形式の Git URL を利用してください。Git URL の書き換えに token を埋め込まないでください。
ビルド時にモジュールキャッシュをウォームアップするには、go.mod が参照できるリポジトリブループリントの maintenance にそのコマンドを追加してください。org-wide setup はリポジトリがクローンされる前に実行されるため、そこでは実行しないでください。
一般的な Go の proxy URL のパターン:
  • Artifactory: https://artifactory.example.com/artifactory/go-virtual
  • Nexus: https://nexus.example.com/repository/go-proxy
  • Athens: https://athens.corp.internal
非公開フィードからパッケージを解決するように NuGet を設定します。
  • NUGET_SOURCE_URL — NuGet フィードの URL
  • NuGetPackageSourceCredentials_private — NuGet の環境変数形式でのフィード認証情報: Username=any;Password=<PAT> (フィードで required なユーザー名を利用してください)
非公開のコンテナレジストリからプルできるよう Docker を設定します。Docker のログインでは、認証情報が config ディレクトリに書き込まれることがあります。操作ごとに分離したディレクトリを利用し、プルが失敗した場合でもそのディレクトリを削除してください。セッション中に別のイメージが必要になった場合は、ログインとプルの手順を再度実行します。
  • DOCKER_MIRROR_URL (任意) — Docker Hub ミラーの URL (例: https://mirror.corp.internal)
  • DOCKER_REGISTRY_URL — 非公開コンテナレジストリの URL (例: registry.corp.internal:5000)
  • DOCKER_REGISTRY_USER — レジストリのユーザー名
  • DOCKER_REGISTRY_PASS — レジストリのパスワードまたは API トークン
スナップショットにイメージをキャッシュするには、同じサブシェル全体をビルドステップに記述します。ログインとクリーンアップを複数のステップに分割せず、イメージ化の前にクリーンアップが成功したことを確認してください。レジストリのミラー URL に認証情報を含めてはいけません。
一般的なコンテナレジストリの URL:
  • Amazon ECR: <account-id>.dkr.ecr.<region>.amazonaws.com
  • Azure Container Registry: <name>.azurecr.io
  • Google Artifact Registry: <region>-docker.pkg.dev
  • GitHub Container Registry: ghcr.io
  • GitLab Container Registry: registry.gitlab.example.com
  • Nexus: https://nexus.example.com:8443
  • JFrog: <name>.jfrog.io
非公開レジストリからクレートを取得できるように Cargo を設定します。
Rust (rustup 経由) と Cargo は Devin のベースイメージにプリインストールされています。デフォルトの stable ツールチェーンで十分な場合は、インストール手順を省略してください。必要なのはレジストリの設定のみです。
  • CARGO_REGISTRY_INDEX — 非公開レジストリのインデックスの URL (例: sparse+https://cargo.corp.internal/api/v1/crates/)
  • CARGO_REGISTRIES_PRIVATE_TOKEN — private という名前のレジストリ用の認証トークン
レジストリのインデックス URL に認証情報を含めてはいけません。Cargo の cargo:token プロバイダーは、指定した名前のレジストリ用トークンを環境変数から読み取ります。ビルドステップで cargo login を実行しないでください。
crates.io を置き換えずに非公開レジストリを追加したいだけの場合は、[source.crates-io] と [source.private] のセクションを削除し、cargo install --registry private を利用するか、Cargo.toml に [dependencies] my-crate = { version = "1.0", registry = "private" } を記述してください。
Ruby をインストールし、非公開の gem サーバーから gem を解決するように Bundler を設定します。
  • GEM_SERVER_URL — 非公開 gem サーバーの URL (例: https://artifactory.example.com/artifactory/api/gems/gems-virtual)
  • BUNDLE_ARTIFACTORY__EXAMPLE__COM — artifactory.example.com 用の username:password。変数名は利用する gem サーバーに合わせて変更してください
認証情報を含まない GEM_SERVER_URL を利用してください。Bundler の認証情報用変数では、ホスト名を大文字にしたものに BUNDLE_ をプレフィックスとして付け、ドットを __ に、ハイフンを ___ に置き換えます。
一般的な gem サーバー URL のパターン:
  • Artifactory: https://artifactory.example.com/artifactory/api/gems/gems-virtual
  • Nexus: https://nexus.example.com/repository/rubygems-proxy
  • Gemfury: https://gem.fury.io/<org>
PHPをインストールし、非公開のPackagistまたはSatisレジストリからパッケージを取得するようにComposerを設定します。
  • COMPOSER_REGISTRY_URL — 非公開ComposerレジストリのURL (例: https://repo.packagist.com/<org>)
  • COMPOSER_AUTH — レジストリホスト向けのJSON形式の認証情報。例: {"http-basic":{"repo.packagist.com":{"username":"<user>","password":"<token>"}}}
認証情報を含まない COMPOSER_REGISTRY_URL を利用します。
一般的な Composer レジストリ URL のパターン:
  • Artifactory: https://artifactory.example.com/artifactory/api/composer/packagist-virtual
  • Nexus: https://nexus.example.com/repository/packagist-proxy
  • Private Packagist: https://repo.packagist.com/<org>
  • Satis: https://satis.corp.internal
AWS CodeArtifact のトークンは通常 12 時間で有効期限が切れます。リテラル参照を含むスクリプトを作成し、npm、pip、Maven を実行するのと同じシェルコマンド内で明示的に source してトークンを取得してください。スクリプトをブループリントに保存しても、セッション開始時に実行されるわけではありません。
Devin のベースイメージには awscli がプリインストール されています。設定が必要なのはトークンの更新とレジストリの構成だけです。
  • AWS_ACCESS_KEY_ID と AWS_SECRET_ACCESS_KEY — codeartifact:GetAuthorizationToken および sts:GetServiceBearerToken 権限を持つ IAM 認証情報
  • CA_DOMAIN — CodeArtifact のドメイン名
  • CA_DOMAIN_OWNER — ドメインを所有する AWS アカウント ID
  • CA_REGION — AWS リージョン (例: us-east-1)
  • CA_NPM_REPO、CA_PYPI_REPO、CA_MAVEN_REPO — 各エコシステムのリポジトリ名
スナップショット内で依存関係のキャッシュをウォームアップするには、適切な source ... && コマンドを後続のビルドステップとして追加してください。取得したトークンはそのシェルの環境内にのみ保持されます。aws codeartifact login、展開済みトークンを使った npm config set、認証情報を含む pip.conf などで永続化しないでください。

Enterprise インフラストラクチャ

すべての org とリポジトリに共通して適用されるマシンレベルのインフラストラクチャです。これらは Enterprise Settings > Environments > Blueprint (enterprise-wide の場合) または Settings > Environment > Blueprints > Org-wide setup (org-wide の場合) で設定します。

ネットワークと接続

お使いの組織では、内部サービス向けに非公開の認証局を利用しています。Devin が HTTPS 経由で内部レジストリやツールに接続するには、ルート証明書が必要です。
  • CORP_ROOT_CA_B64 — 社内 CA の PEM 証明書を Base64 エンコードしたもの。生成方法: cat corp-root-ca.crt | base64 -w0
これらの入力は公開証明書です。openssl x509 は解析済みの証明書のみを書き出すため、誤って含まれた秘密鍵がトラストストアにコピーされることはありません。各CA証明書は、次の使用例のように個別に指定してください。
組織で複数のCA証明書 (例:内部サービスごとに異なるCA) を利用している場合。
  • CORP_ROOT_CA_B64 — Base64エンコードされたプライマリCA証明書
  • CORP_INTERMEDIATE_CA_B64 — Base64エンコードされた中間CA証明書
すべてのネットワークトラフィックを社内プロキシ経由で送信します。
  • CORP_HTTP_PROXY — HTTP プロキシ URL (例: http://proxy.corp.example.com:8080)
  • CORP_HTTPS_PROXY — HTTPS プロキシ URL
  • CORP_NO_PROXY — プロキシを経由しないホストのカンマ区切りリスト (例: localhost,127.0.0.1,.corp.example.com)
企業内プロキシでユーザー名/パスワード認証が必要な場合。
  • PROXY_USER — プロキシのユーザー名
  • PROXY_PASS — プロキシのパスワード
  • PROXY_HOST — プロキシのホスト名とポート (例: proxy.corp.example.com:8080)
  • CORP_NO_PROXY — プロキシを経由しないホスト
プロキシのユーザー名とパスワードに含まれる特殊文字はパーセントエンコードしてください。Git と npm はプロキシの環境変数を利用できます。認証情報を含むプロキシ URL を、これらの永続的な設定にコピーしないでください。
社内CAとプロキシの両方が必要な環境向けの設定です。これは、内部サービスが社内証明書を利用し、すべてのトラフィックをプロキシ経由にする必要があるEnterprise環境で一般的です。
  • CORP_ROOT_CA_B64 — Base64エンコードされた社内CA証明書
  • CORP_HTTP_PROXY, CORP_HTTPS_PROXY — プロキシURL
  • CORP_NO_PROXY — プロキシをバイパスするホスト
非公開レジストリ、Git サーバー、その他の社内サービスには、VPN 経由でのみアクセスできます。VPN クライアントはブループリントでインストールしてください。トンネルは必要な操作のために明示的に確立し、終了後は切断して認証情報ファイルを削除してください。
OpenVPN:
  • VPN_CONFIG_B64 — Base64 エンコードされた OpenVPN 設定ファイル (.ovpn) 。生成方法: cat corp.ovpn | base64 -w0
  • VPN_AUTH_USER (任意) — VPN でユーザー名/パスワード認証が必要な場合の VPN ユーザー名
  • VPN_AUTH_PASS (任意) — VPN パスワード
WireGuard:
  • WG_CONFIG_B64 — Base64 エンコードされた WireGuard 設定ファイル。生成方法: cat wg0.conf | base64 -w0
OpenVPN:
このブロックは、VPN のシークレットが利用できるセッション内で明示的に実行してください。curl コマンドは、トンネルを必要とする実際の作業に置き換えてください。設定には必要な証明書とキーをインラインで含め、dev tun0 を利用する必要があります。永続的な VPN サービスは有効化しないでください。
WireGuard:
このブロックは WG_CONFIG_B64 を利用できる状態で明示的に実行し、curl コマンドを実際の操作に置き換えてください:
スナップショットのビルドで VPN アクセスが必要な場合は、依存する作業をすべて同じ block にまとめ、イメージ化の前にクリーンアップが完了するようにしてください。認証情報の書き込みを maintenance に移しただけでは、一時的なものにはなりません。アクティブな tunnel や非公開の VPN 設定をスナップショットに含めないでください。
VPN の設定の詳細については、VPN configurationを参照してください。
お客様の内部サービスでは、公開DNSでは名前解決できない非公開DNS名を利用しています。

アイデンティティとセキュリティ

組織がすべての Git コミットへの署名を必須としており、Devin のコミットを GitHub 上で Verified と表示させたい場合の設定です。
  • GPG_PRIVATE_KEY_B64 — Base64 エンコードされた GPG 秘密鍵。生成方法: gpg --export-secret-keys <key-id> | base64 -w0
  • GPG_SIGNING_KEY — 署名鍵の完全なフィンガープリント
  • GIT_USER_NAME — Git の作成者名 (例: Devin AI)
  • GIT_USER_EMAIL — Git の作成者メールアドレス。GPG キーの UID と一致している必要があります。一致しない場合、GitHub は署名を検証しません。
対応する公開鍵も、Devin がプッシュに利用する認証情報の GitHub アカウントにアップロードしてください (GitHub Settings > SSH and GPG keys から) 。GitHub がコミットを Verified と表示するのは、コミットを作成したアカウントに署名用の公開鍵が登録されている場合のみです。
スナップショットのビルド中に署名用の秘密鍵をインポートしないでください。目的の変更をステージングしたうえで、対象のシークレットが利用できるセッション内で以下のブロックを明示的に実行します。このブロックは、当該コミットにのみ適用される一時的なキーリングと Git 設定を利用します。
キーにパスフレーズが必要な場合は、操作中に承認済みの GPG エージェント/pinentry のフローを完了してください。パスフレーズやキーリングをブループリントやスナップショットに保存しないでください。以降のコミットや署名付きタグでも、一時キーリングのセットアップを都度繰り返してください。
非公開の Git サーバーにアクセスするために、Devin の Git アイデンティティと SSH キーを設定します。対応している Git プロバイダーでは Git integrations の利用を推奨します。明示的な SSH キーが必要なサーバーの場合は、秘密鍵をブループリントのビルドに含めず、以下のセッション操作でのみ利用してください。
  • GIT_USER_NAME — Git の作成者名
  • GIT_USER_EMAIL — Git の作成者メールアドレス
  • SSH_PRIVATE_KEY_B64 — Base64 エンコードされた SSH 秘密鍵。生成方法: cat ~/.ssh/id_ed25519 | base64 -w0
  • SSH_KNOWN_HOSTS_B64 — Base64 エンコードされた known hosts の項目。サーバー管理者が公開しているホストキーのフィンガープリントと照合して検証済みのもの
このブロックはセッション内で明示的に実行し、Git URL を自組織のサーバーとリポジトリに置き換えてください。
独自の SSH オプションが必要な場合は、永続的な SSH 設定やホームディレクトリに秘密鍵をコピーせず、この実行時に追加してください。操作ごとにセットアップを繰り返してください。

システム構成

Devinのデフォルトイメージに含まれていないシステムレベルのパッケージ (例:画像処理やPDF生成に必要なネイティブライブラリ) をインストールします。
すべてのセッションで利用できる永続的な、機密でない環境変数を設定します。シークレットの値やそこから派生した認証情報を $ENVRC に書き込まないでください。推奨される方法は、KEY=VALUE 形式の行を $ENVRC ファイルに書き込むことです。$ENVRC に書き込まれた変数は、以降のすべてのステップと Devin セッションで自動的にエクスポートされます (GitHub Actions の $GITHUB_ENV と同様です) 。
システム全体で利用できるように、環境変数を /etc/profile.d/ のスクリプトに書き込むこともできます。
どちらの方法でも問題ありません。ほとんどの場合は、$ENVRC のほうが簡単でおすすめです。
デフォルトのベースイメージでは、ロケール設定が正しくない場合があります。ビルドツール、Java、Python、Git で警告が表示されないように、ロケールとタイムゾーンを設定してください。
Java、Gradle、Node.js のビルドでは、デフォルトの 1024 のオープンファイル上限に頻繁に達します。ビルドの失敗を防ぐため、この上限を引き上げてください。
air-gapped または制限された環境では、デフォルトの Ubuntu APT ソースを内部ミラーに置き換えます。
  • APT_MIRROR_URL — 内部 APT ミラーの URL (例: https://artifactory.example.com/artifactory/ubuntu-remote)
一般的なAPTミラーのURLパターン:
  • Artifactory: https://artifactory.example.com/artifactory/ubuntu-remote
  • Nexus: https://nexus.example.com/repository/ubuntu-proxy

高度なパターン

Devinのベース環境には direnv が含まれています。.envrc ファイルを作成するには initialize を利用します。direnv がそれらを自動的に読み込みます。
direnv は Devin のシェルにあらかじめ組み込まれているため、.envrc の変数は自動的に読み込まれます。手動で source する必要はありません。
機密性の高い環境変数 (APIキー、トークン、データベースのパスワード) には、.envrc ファイルではなく repo secrets を利用し、それらを必要とするセッションのコマンドに明示的にバインドしてください。ビルド中にシークレットを展開してファイルに書き出すと、スナップショットに含まれてしまう可能性があります。
.nvmrc を使って、リポジトリごとに Node.js のバージョンを切り替えるには、nvm (プリインストール済み) を利用します。
nvm use はリポジトリのルートにある .nvmrc を読み取ります。リポジトリに .nvmrc があることを確認してください (例: 20 を含むもの) 。
Devin では、セッション中 に localhost:29229 の CDP エンドポイントを備えた Chrome ブラウザを利用できます。Playwright スクリプトを利用して、ブラウザベースのログインを自動化してください。
ブラウザを利用できるのはセッション中のみで、スナップショットのビルドでは利用できません。initialize で Playwright をインストールし、ログインスクリプトはリポジトリに保存してください。
ログインスクリプトの例 (scripts/login.py) :
ログイン認証情報はソースコードに含めず、シークレットとして保存してください。長期間使用する認証が必要な場合は、Devin が自動で再認証できるよう、ログインスクリプトを .agents/skills/ にコミットしてください。
initialize でシステムパッケージやカスタムバイナリをインストールし、PATH を設定します。
Devin では、GitHub Actions をブループリントの initialize セクション内で直接実行できます。これにより、CI で利用しているのと同じアクションを使って、特定のバージョンのツールをインストールできます。
setup-node や setup-python などのアクションは、PATH と環境変数を変更します。あるアクションでインストールされたバイナリは、後続のすべてのステップと maintenance で利用できます。Node.js アクションと Composite アクションはサポートされています。Docker アクションは Linux ビルドでのみサポートされます。uses ステップは maintenance では実行できません。GitHub Actions の制限事項を参照してください。
基本的なツールのセットアップに GitHub Actions は必要ありません。シェルコマンドを直接実行しても (nvm install 20、curl ... | sh、apt-get install) 、同様に機能し、多くの場合はこちらのほうが簡単です。GitHub Actions が特に有用なのは、CI のセットアップと完全に一致させたい場合や、複数のディストリビューションに対応する setup-java のようなアクションの利便性が必要な場合です。
app.example.com、api.example.com、admin.example.com のような実在しそうなホスト名で、複数のサービスを HTTPS 経由で公開できます。initialize で 1 つのリバースプロキシをインストールし、各ホスト名をそれぞれ異なるローカルのアップストリームポートにルーティングします。Caddy は、ルーティングとローカル TLS を 1 つのツールでまとめて処理します。Caddyfile では各ホスト名をアップストリームに対応付け、tls internal は Caddy に組み込まれた CA から、ホスト名ごとに信頼された証明書を自動発行します。caddy trust はその CA ルートをシステムのトラストストアにインストールし、同じルートを NSS データベースにも追加すると、ブラウザでも受け入れられるようになります。Caddyfile はブループリントエディタの File attachments セクションからアップロードしてください。アップロードすると、$FILE_CADDYFILE として利用できるようになります。
Caddyfile
/etc/hosts ループによって、セッション内では app.example.com が 127.0.0.1 に名前解決されます。Caddyfile に記述する各ホスト名について、/etc/hosts ループにもエントリを追加してください。
サービスを追加するには、Caddyfile に 3 行のブロックを追記し、/etc/hosts ループにエントリを 1 つ追加してから、そのホスト名に HTTPS でアクセスしてください。Caddy は最初のリクエスト時に証明書を発行するため、app ごとに証明書を生成する必要はありません。

フルスタックの使用例

これらの使用例では、Enterprise と org レベルの設定がどのように組み合わさるかを示しています。実際には、これらはスコープごとに分けて扱うのが一般的です。ここでは参考用にまとめて示しています。
Enterprise環境のフルセット構成例:社内CA証明書、プロキシ、Java (Maven) 、Python (pip/uv) 、Node.js (npm) 、Dockerをすべて単一のArtifactoryインスタンスに向けた設定です。
ネットワーク & 信頼設定 (アカウント全体) :
  • CORP_ROOT_CA_B64 — Base64 エンコードされた社内CA証明書
  • CORP_HTTP_PROXY — HTTP プロキシ URL
  • CORP_HTTPS_PROXY — HTTPS プロキシ URL
  • CORP_NO_PROXY — プロキシをバイパスするホスト
レジストリ認証情報 (組織全体) :
  • ARTIFACTORY_USER — Artifactory のユーザー名
  • ARTIFACTORY_TOKEN — Artifactory API トークンまたはパスワード
  • ARTIFACTORY_MAVEN_URL — Maven リポジトリ URL (例: https://artifactory.example.com/artifactory/maven-virtual)
  • ARTIFACTORY_PYPI_URL — PyPI リポジトリ URL (例: https://user:token@artifactory.example.com/artifactory/api/pypi/pypi-virtual/simple)
  • ARTIFACTORY_NPM_URL — npm リポジトリ URL (例: https://artifactory.example.com/artifactory/api/npm/npm-virtual)
  • ARTIFACTORY_DOCKER_URL — Docker レジストリ URL (例: artifactory.example.com)
これは通常、3つのスコープに分割されます:
  • アカウント全体で共通 (initialize) : 証明書とプロキシ
  • 組織全体 (initialize): 言語ランタイムのインストール
  • 組織全体 (maintenance): リテラル参照を含むレジストリ設定
  • セッションコマンド: シークレットを明示的に指定し、環境設定を source で読み込み、個々の Docker 操作ごとにログインする
参考までに、まとめて示します:
この例では、すべてのレジストリが同じ Artifactory インスタンスを参照していますが、URL パスはそれぞれ異なります。各パッケージエコシステムには、それぞれ固有のエンドポイント形式があります。Maven、PyPI、npm、Docker の URL は、同じレジストリであってもそれぞれ異なります。
言語ごとに異なる非公開レジストリを利用する場合 (例: Maven は Nexus、npm は GitHub Packages、Python は Artifactory) 。
  • NEXUS_MAVEN_URL — Nexus Maven リポジトリ URL
  • NEXUS_USER — Nexus のユーザー名
  • NEXUS_PASS — Nexus のパスワード
  • GITHUB_PACKAGES_TOKEN — read:packages スコープを持つ GitHub パーソナルアクセストークン
  • ARTIFACTORY_USER — Artifactory のユーザー名
  • ARTIFACTORY_TOKEN — Artifactory API トークン
Git provider を接続し、Git integrations を通じて Go モジュールをホストしているリポジトリへのアクセスを与えてください。
完全にエアギャップされた環境では、Devin は公開 URL に一切アクセスできません。すべてのツール、ランタイム、パッケージは内部ミラー経由で取得する必要があります。
証明書:
  • CORP_ROOT_CA_B64 — Base64 エンコードされた社内CA証明書
ミラーへのアクセス:
  • APT_MIRROR_URL — 内部 Ubuntu APT ミラーの URL
  • MIRROR_USER — ミラー認証用のユーザー名
  • MIRROR_PASS — ミラー認証用のパスワード
  • JDK_TARBALL_URL — 内部ミラーから JDK tarball をダウンロードするための URL
  • NODE_TARBALL_URL — 内部ミラーから Node.js tarball をダウンロードするための URL
パッケージレジストリ:
  • INTERNAL_MAVEN_URL — 内部 Maven レジストリの URL
  • INTERNAL_NPM_URL — 内部 npm レジストリの URL
  • INTERNAL_PYPI_URL — 内部 PyPI レジストリの URL
エアギャップ環境では、Devin が必要とするすべてのツール (言語ランタイム、CLI ツールなど) を社内ミラーで利用できるようにしておく必要があります。公開レジストリやダウンロードサイトにはアクセスできません。
VPNツール、証明書、プロキシ設定、多言語サポートを組み合わせた包括的なエンタープライズ向けセットアップです。ブループリントはツールをインストールし、リテラル参照とともに設定を保存します。内部アクセスが必要な操作を実行する際は、明示的にVPNへ接続してください。
VPN:
  • VPN_CONFIG_B64 — Base64 でエンコードされた OpenVPN 設定ファイル
ネットワークと信頼設定:
  • CORP_ROOT_CA_B64 — Base64 でエンコードされた社内CA証明書
  • CORP_HTTP_PROXY — HTTP プロキシ URL
  • CORP_HTTPS_PROXY — HTTPS プロキシ URL
  • CORP_NO_PROXY — プロキシを経由しないホスト
レジストリ認証情報:
  • MAVEN_REGISTRY_URL — Maven レジストリ URL
  • NPM_REGISTRY_URL — npm レジストリ URL
  • PYPI_REGISTRY_HOST — PyPI レジストリのホスト名
  • REGISTRY_USER — レジストリのユーザー名 (Maven と pip 用)
  • REGISTRY_PASS — レジストリのパスワード (Maven と pip 用)
  • REGISTRY_TOKEN — npm 認証トークン
ブートストラップアクセスが必要です。 トンネルを接続する前に、OpenVPN クライアントがプリインストールされているか、インストール可能である必要があります。VPN_CONFIG_B64 にはインラインの証明書/キーを含め、dev tun0 を利用し、対話的な認証なしで接続できる必要があります。ランタイムのダウンロードは 1 つのトンネルライフサイクル内で実行され、プロキシ環境を明示的に読み込みます。セッションでの操作については、ネットワークと接続性 にある VPN のセットアップ/クリーンアップブロックを繰り返してください。ブループリントはセッション開始時に VPN を再接続しません。

良い ブループリント を書くためのヒント

  • まずセッションでコマンドをテストする。 ブループリント に追加する前に、Devin のセッションでコマンドを手動で実行してください。フルビルドを待つより、そのほうが速く済みます。
  • 一度だけインストールするツールには initialize、依存関係には maintenance を利用する。 インストールに数分かかるもの (コンパイラ、大きなバイナリ、グローバルツール) は initialize に入れます。短時間で終わる依存関係コマンド (npm install、uv sync) は maintenance に入れます。
  • maintenance コマンドは高速に保つ。 2 分以内を目安にしてください。これらはビルド中に実行され、セッション開始時にエージェントに提示されます。
  • シークレット以外の環境変数には $ENVRC を利用する。 認証情報や、そこから 由来 する トークン を $ENVRC、.bashrc、.profile に書き込まないでください。シークレット に依存するシェル設定は、それを必要とするコマンド内で明示的に読み込んでください。
  • ステップには名前を付ける。 name フィールドを使う expanded form にすると、ビルドログ内の失敗箇所を特定しやすくなります。
  • モノレポ では サブシェル を利用する。 (cd packages/foo && npm install) は サブシェル 内で実行されるため、後続のステップはディレクトリ変更の影響を受けません。
  • npm ci ではなく npm install を利用する。 npm ci は node_modules を削除し、ゼロから再インストールするため、maintenance には不向きです。
  • 機密性の高い値には repo secrets を利用する。 ブループリント に直接書き込むのではなく、リポジトリのブループリントエディタの Secrets タブで設定してください。
構文の詳細については、Blueprint reference を参照してください。ビルド失敗のトラブルシューティングについては、Declarative configuration > Troubleshooting を参照してください。