Skip to main content
Blueprints zum Kopieren und Einfügen für gängige Sprachen und Anwendungsfälle. Kombinieren Sie sie zu Ihrer vollständigen Konfiguration. Die Beispiele verwenden Bash unter Linux; ersetzen Sie die Beispiel-Hosts, -Scopes und -Befehle durch Ihre eigenen. Eine vollständige Übersicht aller Felder finden Sie in der Blueprint-Referenz.
Secrets: Konfigurieren Sie die benannten Secrets im Tab Secrets des jeweiligen Blueprint-Editors. Build-Schritte erhalten die jeweils zutreffenden Blueprint-Secrets. Stellen Sie während einer Sitzung sicher, dass jeder Befehl die benötigten Secrets erhält: Repo-bezogene Secrets erfordern explizite exec-Umgebungsbindungen, etwa env={"REGISTRY_TOKEN": "secret:repo:owner/repo:REGISTRY_TOKEN"}. Siehe Secrets. Hinterlegen Sie Anmeldedaten niemals fest codiert in Ihrem Blueprint.
Build-Schritte sind keine Startup-Hooks für Sitzungen. initialize und maintenance laufen während der Erstellung von Snapshots; maintenance wird beim Sitzungsstart nicht automatisch ausgeführt. knowledge liefert Devin Anweisungen, keine ausführbaren Hooks.Halten Sie Anmeldedaten aus persistenten Dateien heraus, einschließlich $ENVRC. Die Snapshot-Bereinigung entfernt die von Devin eingefügten Secret-Dateien, nicht jedoch beliebige Dateien, die Ihre Befehle schreiben. Verwenden Sie wörtliche Variablenreferenzen, die das nutzende Tool unterstützt, oder übergeben Sie Anmeldedaten in der Umgebung des Befehls. Wenn ein Tool Dateien mit Anmeldedaten benötigt, erstellen Sie diese für eine einzelne Operation und löschen Sie sie, bevor diese abgeschlossen ist. Wiederholen Sie dieses Setup bei Bedarf innerhalb einer Sitzung explizit.

Schnellstart

Minimale Blueprints für die gängigsten Setups. Kopieren Sie einen, fügen Sie ihn in den Blueprint-Editor ein, und Sie sind fertig.

Repository-Blueprints

Repo-spezifische Build-Schritte, Abhängigkeitsmanagement und Knowledge-Einträge. Lege diese unter Settings > Environment > Blueprints > [dein Repo] fest.

Python

Empfohlene Einrichtung für Python-Projekte, die uv für die Abhängigkeitsverwaltung verwenden.

Node.js

Standard-Node.js-Setup mit npm.
Verwenden Sie in maintenance npm install (nicht npm ci). Dadurch wird ein inkrementelles Update durchgeführt, während npm ci node_modules löscht und bei jeder Ausführung des Befehls alles von Grund auf neu installiert.

Go

Standard-Setup für Go mit Modulen.

Java

Java-Einrichtung mit Gradle.
JDK 17 ist vorinstalliert im Basis-Image von Devin. Überspringen Sie die JDK-Installation, wenn das Standard-OpenJDK 17 ausreicht.

Ruby on Rails

Rails-Setup mit PostgreSQL.

Rust

Standardmäßiges Rust-Setup mit Cargo.
Rust (über rustup) und Cargo sind im Basis-Image von Devin vorinstalliert. Überspringen Sie den Installationsschritt, wenn die standardmäßige stabile Toolchain ausreicht. Sie müssen nur die Abhängigkeiten abrufen.

Monorepos

Monorepo mit einem Node.js-Frontend und einem Python-Backend. Jedes Teilprojekt erhält eigene Knowledge-Einträge.
Verwende Subshells (cd dir && command) anstelle von cd dir && command, damit das Arbeitsverzeichnis zwischen den Schritten zurückgesetzt wird.

Private Package-Registries

Konfiguriere Package Manager so, dass sie Dependencies aus privaten Registries beziehen. Lege dies unter Settings > Environment > Blueprints > Org-wide setup fest (oder pro Repo, falls nur ein Repo es benötigt).
Speichere Referenzen, keine aufgelösten Anmeldedaten. Heredoc-Begrenzer in Anführungszeichen wie <<'EOF' erhalten die Variablenreferenzen in der Datei. npm, Yarn Berry, Maven und Gradle können die unten gezeigten Referenzen zur Laufzeit auflösen. pip expandiert in pip.conf keine Shell-Variablen, verwende dort also stattdessen Umgebungsvariablen. Shell-Setup-Dateien müssen im selben Befehl wie das Tool explizit mit source eingebunden werden; gehe nicht davon aus, dass eine neue Shell sie automatisch einliest oder Anmeldedaten aktualisiert.URLs, die direkt in persistente Konfigurationen geschrieben werden, etwa ein Cargo-Index, ein Docker-Mirror oder ein APT-Mirror, dürfen keine Anmeldedaten enthalten. Bewahre die Authentifizierung in den separaten Secrets auf, die in der jeweiligen Vorlage gezeigt werden.Falls du eine ältere Vorlage verwendet hast, die Anmeldedaten auf die Festplatte geschrieben hat, entferne diese Dateien und baue von einer sauberen Basis neu auf, statt von einem Snapshot, der sie enthält. Rotiere Anmeldedaten, die möglicherweise abgegriffen wurden.
Wenn deine private Registry eine Unternehmens-CA verwendet, stelle sicher, dass das CA-Zertifikat zuvor auf Enterprise-Ebene installiert wurde. Die folgende Konfiguration setzt voraus, dass das HTTPS-Vertrauen bereits hergestellt ist.

Node.js-Registries

Konfigurieren Sie npm so, dass Packages mit Scope (z. B. @myorg/*) aus einer privaten Registry bezogen werden, während öffentliche Packages weiterhin aus der Standard-npm-Registry kommen.
  • GITHUB_PACKAGES_TOKEN — Personal Access Token oder GitHub-App-Token mit dem Geltungsbereich read:packages
Ersetzen Sie @myorg durch Ihren npm-Scope. Gängige private Registry-URLs:
  • 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-Registries

Konfigurieren Sie pip und uv so, dass sie Pakete aus Ihrer privaten PyPI-Registry beziehen (z. B. Nexus, Artifactory).
  • PYPI_REGISTRY_URL — Vollständige URL Ihres PyPI-Index, einschließlich Anmeldedaten, falls erforderlich (z. B. https://user:token@nexus.example.com/repository/pypi-proxy/simple)
Um Abhängigkeiten bereits während eines Builds vorzuladen, fügen Sie denselben source ... &&-Befehl nach dem Konfigurationsschritt in maintenance ein. Sonderzeichen in Anmeldedaten innerhalb der URL müssen prozentkodiert werden.
Gängige URL-Muster für PyPI-Registries:
  • 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-Registries

Installieren Sie das JDK und konfigurieren Sie Maven so, dass die Auflösung aller Abhängigkeiten über Ihre private Registry erfolgt (z. B. Artifactory, Nexus).
JDK 17 ist auf Devins Basis-Image vorinstalliert. Überspringen Sie den Installationsschritt, wenn das Standard-OpenJDK 17 ausreicht. Sie benötigen nur die Maven-Installation und die Konfiguration der Registry.
  • MAVEN_REGISTRY_URL — URL Ihrer Maven-Registry (z. B. https://artifactory.example.com/artifactory/maven-virtual)
  • REGISTRY_USER — Registry-Nutzername
  • REGISTRY_PASS — Registry-Passwort oder API-Token
Gängige Registry-URL-Muster für Maven:
  • 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>

Weitere Registries

Installieren Sie Go und konfigurieren Sie es so, dass Module über einen privaten Modul-Proxy bezogen werden (z. B. Athens, Artifactory oder ein GOPROXY-Endpunkt).
  • GO_PROXY_URL — URL Ihres Go-Modul-Proxys (z. B. https://athens.corp.internal)
Verbinden Sie den Git-Anbieter und gewähren Sie über Git-Integrationen Zugriff auf die Repositorys, in denen Ihre privaten Module liegen. Verwenden Sie normale HTTPS-Git-URLs mit der in Devin konfigurierten Authentifizierung. Betten Sie kein Token in ein Git-URL-Rewrite ein.
Um den Modul-Cache während der Builds vorzuwärmen, fügen Sie diesen Befehl im Abschnitt maintenance des Repository-Blueprints hinzu, wo go.mod verfügbar ist. Führen Sie ihn nicht im Org-wide setup aus, da dieses vor dem Klonen der Repositorys ausgeführt wird.
Gängige Muster für Go-Proxy-URLs:
  • Artifactory: https://artifactory.example.com/artifactory/go-virtual
  • Nexus: https://nexus.example.com/repository/go-proxy
  • Athens: https://athens.corp.internal
Konfigurieren Sie NuGet so, dass Pakete aus einem privaten Feed bezogen werden.
  • NUGET_SOURCE_URL — URL Ihres NuGet-Feeds
  • NuGetPackageSourceCredentials_private — Feed-Anmeldedaten im Umgebungsformat von NuGet: Username=any;Password=<PAT> (verwenden Sie den von Ihrem Feed geforderten Nutzernamen)
Konfigurieren Sie Docker so, dass Images aus einer privaten Container-Registry abgerufen werden.docker login kann Anmeldedaten in sein Konfigurationsverzeichnis schreiben. Verwenden Sie für jeden Vorgang ein isoliertes Verzeichnis und entfernen Sie es auch dann, wenn der Pull fehlschlägt. Führen Sie die Login-und-Pull-Sequenz erneut aus, wenn Sie in einer Sitzung ein weiteres Image benötigen.
  • DOCKER_MIRROR_URL (optional) — URL Ihres Docker-Hub-Mirrors (z. B. https://mirror.corp.internal)
  • DOCKER_REGISTRY_URL — URL Ihrer privaten Container-Registry (z. B. registry.corp.internal:5000)
  • DOCKER_REGISTRY_USER — Registry-Nutzername
  • DOCKER_REGISTRY_PASS — Registry-Passwort oder API-Token
Um ein Image im Snapshot zwischenzuspeichern, verwenden Sie dieselbe vollständige Subshell in einem Build-Step. Verteilen Sie Login und Cleanup nicht auf mehrere Steps und stellen Sie sicher, dass das Cleanup erfolgreich war, bevor Sie das Image erstellen. Eine Registry-Mirror-URL darf keine Anmeldedaten enthalten.
Gängige Container-Registry-URLs:
  • 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
Konfigurieren Sie Cargo so, dass Crates aus einer privaten Registry bezogen werden.
Rust (über rustup) und Cargo sind im Basis-Image von Devin bereits vorinstalliert. Überspringen Sie den Installationsschritt, wenn die standardmäßige stabile Toolchain ausreicht. Sie benötigen lediglich die Registry-Konfiguration.
  • CARGO_REGISTRY_INDEX — URL des privaten Registry-Index (z. B. sparse+https://cargo.corp.internal/api/v1/crates/)
  • CARGO_REGISTRIES_PRIVATE_TOKEN — Auth-Token für die Registry mit dem Namen private
Die Index-URL der Registry darf keine Anmeldedaten enthalten. Der cargo:token-Anbieter von Cargo liest das benannte Registry-Token aus der Umgebung; führen Sie cargo login nicht in einem Build-Schritt aus.
Wenn Sie lediglich eine private Registry hinzufügen möchten, ohne crates.io zu ersetzen, entfernen Sie die Abschnitte [source.crates-io] und [source.private] und verwenden Sie cargo install --registry private oder [dependencies] my-crate = { version = "1.0", registry = "private" } in Cargo.toml.
Installieren Sie Ruby und konfigurieren Sie Bundler so, dass Gems von einem privaten Gem-Server bezogen werden.
  • GEM_SERVER_URL — URL Ihres privaten Gem-Servers (z. B. https://artifactory.example.com/artifactory/api/gems/gems-virtual)
  • BUNDLE_ARTIFACTORY__EXAMPLE__COM — username:password für artifactory.example.com; passen Sie den Variablennamen an Ihren Gem-Server an
Verwenden Sie eine GEM_SERVER_URL ohne Credentials. Stellen Sie für die Credential-Variable von Bundler dem Hostname in Großbuchstaben das Präfix BUNDLE_ voran, ersetzen Sie jeden Punkt durch __ und jeden Bindestrich durch ___.
Gängige Muster für Gem-Server-URLs:
  • Artifactory: https://artifactory.example.com/artifactory/api/gems/gems-virtual
  • Nexus: https://nexus.example.com/repository/rubygems-proxy
  • Gemfury: https://gem.fury.io/<org>
Installieren Sie PHP und konfigurieren Sie Composer so, dass Pakete aus einer privaten Packagist- oder Satis-Registry bezogen werden.
  • COMPOSER_REGISTRY_URL — URL Ihrer privaten Composer-Registry (z. B. https://repo.packagist.com/<org>)
  • COMPOSER_AUTH — JSON-Anmeldedaten für den Registry-Host, etwa {"http-basic":{"repo.packagist.com":{"username":"<user>","password":"<token>"}}}
Verwenden Sie eine COMPOSER_REGISTRY_URL ohne Credentials.
Gängige Muster für Composer-Registry-URLs:
  • 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-Token laufen normalerweise nach 12 Stunden ab. Erstellen Sie ein Skript mit literalen Referenzen und binden Sie es dann explizit per source im selben Shell-Befehl wie npm, pip oder Maven ein, um ein Token zu erhalten. Wird das Skript in einem Blueprint gespeichert, wird es beim Start der Sitzung nicht ausgeführt.
awscli ist vorinstalliert im Base-Image von Devin. Sie müssen lediglich die Token-Aktualisierung und die Registry-Konfiguration einrichten.
  • AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY — IAM-Anmeldedaten mit den Berechtigungen codeartifact:GetAuthorizationToken und sts:GetServiceBearerToken
  • CA_DOMAIN — Ihr CodeArtifact-Domainname
  • CA_DOMAIN_OWNER — ID des AWS-Kontos, dem die Domain gehört
  • CA_REGION — AWS-Region (z. B. us-east-1)
  • CA_NPM_REPO, CA_PYPI_REPO, CA_MAVEN_REPO — Repository-Namen für das jeweilige Ökosystem
Um einen Abhängigkeits-Cache im Snapshot vorzuwärmen, fügen Sie den passenden Befehl source ... && als späteren Build-Schritt hinzu. Das abgerufene Token bleibt in der Environment dieser Shell erhalten; speichern Sie es nicht dauerhaft mit aws codeartifact login, npm config set mit einem expandierten Token oder einer pip.conf, die Credentials enthält.

Enterprise-Infrastruktur

Infrastruktur auf Maschinenebene, die für alle Orgs und Repos gilt. Legen Sie diese in Settings > Devin’s base environment (unternehmensweit) oder Settings > Environment > Blueprints > Org-wide setup (org-weit) fest.

Netzwerk und Konnektivität

Ihre Organisation verwendet eine private Zertifizierungsstelle für interne Dienste. Devin benötigt das Stammzertifikat, um interne Registries und Tools über HTTPS zu erreichen.
  • CORP_ROOT_CA_B64 — Base64-kodiertes PEM-Zertifikat von der CA Ihres Unternehmens. erzeugen mit: cat corp-root-ca.crt | base64 -w0
Diese Eingaben sind öffentliche Zertifikate. openssl x509 schreibt nur das geparste Zertifikat, sodass ein versehentlich enthaltener privater Schlüssel nicht in den Trust Store kopiert wird. Geben Sie jedes CA-Zertifikat separat an, wie im nächsten Beispiel.
Wenn Ihre Organisation mehrere CA-Zertifikate verwendet (z. B. separate CAs für unterschiedliche interne Dienste).
  • CORP_ROOT_CA_B64 — Base64-codiertes primäres CA-Zertifikat
  • CORP_INTERMEDIATE_CA_B64 — Base64-codiertes Zwischenzertifikat
Leiten Sie den gesamten Netzwerkverkehr über einen Unternehmensproxy.
  • CORP_HTTP_PROXY — HTTP-Proxy-URL (z. B. http://proxy.corp.example.com:8080)
  • CORP_HTTPS_PROXY — HTTPS-Proxy-URL
  • CORP_NO_PROXY — kommagetrennte Liste der Hosts, die den Proxy umgehen sollen (z. B. localhost,127.0.0.1,.corp.example.com)
Wenn Ihr Unternehmens-Proxy eine Authentifizierung per Nutzername/Passwort erfordert.
  • PROXY_USER — Proxy-Nutzername
  • PROXY_PASS — Proxy-Passwort
  • PROXY_HOST — Proxy-Hostname und -Port (z. B. proxy.corp.example.com:8080)
  • CORP_NO_PROXY — Hosts, für die der Proxy umgangen werden soll
Kodieren Sie Sonderzeichen im Proxy-Nutzernamen und -Passwort als Prozentkodierung. Git und npm können Proxy-Umgebungsvariablen nutzen; übernehmen Sie keine Proxy-URL mit Credentials in deren dauerhafte Konfiguration.
Kombinierte Einrichtung für Umgebungen, die sowohl eine Unternehmens-CA als auch einen Proxy benötigen. Das ist in Unternehmensumgebungen üblich, in denen interne Dienste private Zertifikate verwenden und der gesamte Datenverkehr über einen Proxy geleitet werden muss.
  • CORP_ROOT_CA_B64 — Base64-kodiertes Unternehmens-CA-Zertifikat
  • CORP_HTTP_PROXY, CORP_HTTPS_PROXY — Proxy-URLs
  • CORP_NO_PROXY — Hosts, die den Proxy umgehen
Ihre privaten Registries, Git-Server oder anderen internen Dienste sind nur über ein VPN erreichbar. Installieren Sie den VPN-Client im Blueprint. Bauen Sie den Tunnel explizit für die Operationen auf, die ihn benötigen, und trennen Sie die Verbindung anschließend und entfernen Sie die Credential-Dateien.
OpenVPN:
  • VPN_CONFIG_B64 — Base64-kodierte OpenVPN-Konfigurationsdatei (.ovpn). Erzeugen mit: cat corp.ovpn | base64 -w0
  • VPN_AUTH_USER (optional) — VPN-Nutzername, falls Ihr VPN eine Authentifizierung per Nutzername/Passwort erfordert
  • VPN_AUTH_PASS (optional) — VPN-Passwort
WireGuard:
  • WG_CONFIG_B64 — Base64-kodierte WireGuard-Konfigurationsdatei. Erzeugen mit: cat wg0.conf | base64 -w0
OpenVPN:
Führen Sie diesen Block explizit in einer Sitzung aus, in der die VPN-Secrets verfügbar sind. Ersetzen Sie den curl-Befehl durch die Arbeit, die den Tunnel benötigt. Die Konfiguration muss die erforderlichen Zertifikate und Keys inline enthalten und dev tun0 verwenden; aktivieren Sie keinen dauerhaften VPN-Dienst.
WireGuard:
Führen Sie diesen Block explizit mit verfügbarem WG_CONFIG_B64 aus und ersetzen Sie den curl-Befehl durch Ihre Operation:
Wenn ein Snapshot-Build VPN-Zugriff benötigt, fassen Sie alle davon abhängigen Schritte im selben Block zusammen, damit die Bereinigung vor der Image-Erstellung abgeschlossen ist. Das bloße Verschieben von Credential-Schreibvorgängen nach maintenance macht sie nicht temporär. Erstellen Sie keinen Snapshot eines aktiven Tunnels oder einer privaten VPN-Konfiguration.
Weitere Informationen zur VPN-Einrichtung finden Sie unter VPN-Konfiguration.
Ihre internen Dienste verwenden private DNS-Namen, die über öffentliches DNS nicht aufgelöst werden können.

Identität und Sicherheit

Ihre Organisation verlangt, dass alle Git-Commits signiert sind, und Sie möchten, dass GitHub die Commits von Devin als Verified kennzeichnet.
  • GPG_PRIVATE_KEY_B64 — Base64-kodierter privater GPG-Schlüssel. Erzeugen mit: gpg --export-secret-keys <key-id> | base64 -w0
  • GPG_SIGNING_KEY — Vollständiger Fingerabdruck des Signaturschlüssels
  • GIT_USER_NAME — Git-Autorenname (z. B. Devin AI)
  • GIT_USER_EMAIL — Git-Autoren-E-Mail. Muss mit einer UID des GPG-Schlüssels übereinstimmen, sonst verifiziert GitHub die Signatur nicht.
Laden Sie außerdem den passenden öffentlichen Schlüssel in das GitHub-Konto hoch, dessen Anmeldedaten Devin zum Pushen verwendet (unter GitHub Settings > SSH and GPG keys). GitHub kennzeichnet Commits nur dann als Verified, wenn der öffentliche Signaturschlüssel in dem Konto hinterlegt ist, das den Commit erstellt hat.
Importieren Sie während Snapshot-Builds keine privaten Signaturschlüssel. Führen Sie diesen Block nach dem Staging der gewünschten Änderungen explizit in einer Sitzung aus, in der die genannten Secrets verfügbar sind. Er verwendet einen temporären Schlüsselbund und Git-Einstellungen, die nur für diesen Commit gelten:
Wenn Ihr Schlüssel eine Passphrase erfordert, durchlaufen Sie während des Vorgangs den dafür freigegebenen GPG-Agent-/Pinentry-Ablauf. Speichern Sie weder die Passphrase noch den Schlüsselbund im Blueprint oder Snapshot. Richten Sie den temporären Schlüsselbund für spätere Commits oder signierte Tags jeweils erneut ein.
Konfigurieren Sie die Git-Identität und die SSH-Schlüssel von Devin für den Zugriff auf private Git-Server.Nutzen Sie für unterstützte Git-Anbieter bevorzugt Git integrations. Bei einem Server, der einen expliziten SSH-Schlüssel erfordert, halten Sie den privaten Schlüssel aus dem Blueprint-Build heraus und verwenden Sie ihn nur für den unten beschriebenen Vorgang in der Sitzung.
  • GIT_USER_NAME — Git-Autorenname
  • GIT_USER_EMAIL — Git-Autoren-E-Mail
  • SSH_PRIVATE_KEY_B64 — Base64-kodierter privater SSH-Schlüssel. Erzeugen mit: cat ~/.ssh/id_ed25519 | base64 -w0
  • SSH_KNOWN_HOSTS_B64 — Base64-kodierte Known-Hosts-Einträge, abgeglichen mit den von Ihrem Serveradministrator veröffentlichten Host-Key-Fingerabdrücken
Führen Sie diesen Block explizit in der Sitzung aus und ersetzen Sie die Git-URL durch Ihren Server und Ihr Repository:
Wenn Sie eigene SSH-Optionen benötigen, fügen Sie diese direkt bei diesem Aufruf hinzu, ohne einen privaten Schlüssel in eine dauerhafte SSH-Konfiguration oder das Home-Verzeichnis zu kopieren. Wiederholen Sie das Setup für jeden Vorgang.

Systemkonfiguration

Installieren Sie Systempakete, die im Standard-Image von Devin nicht enthalten sind (z. B. native Bibliotheken für die Bildverarbeitung oder PDF-Generierung).
Legen Sie persistente, nicht geheime Umgebungsvariablen fest, die in jeder Sitzung verfügbar sein sollen. Schreiben Sie keine Secret-Werte oder abgeleiteten Anmeldedaten in $ENVRC.Es wird empfohlen, Zeilen im Format KEY=VALUE in die Datei $ENVRC zu schreiben. In $ENVRC geschriebene Variablen werden automatisch für alle nachfolgenden Schritte und die Devin-Sitzung exportiert (ähnlich wie bei $GITHUB_ENV in GitHub Actions’).
Sie können Umgebungsvariablen auch in Skripte unter /etc/profile.d/ schreiben, damit sie systemweit verfügbar sind:
Beide Ansätze funktionieren. $ENVRC ist jedoch einfacher und wird in den meisten Fällen empfohlen.
Standard-Basis-Images können fehlerhafte Locale-Einstellungen aufweisen. Konfigurieren Sie Locale und Zeitzone, um Warnungen durch Build-Tools, Java, Python und Git zu vermeiden.
Java-, Gradle- und Node.js-Builds stoßen häufig an das Standardlimit von 1024 offenen Dateien. Erhöhen Sie es, um Build-Fehler zu vermeiden.
In Air-Gap- oder eingeschränkten Umgebungen ersetzen Sie die Standard-Ubuntu-APT-Quellen durch einen internen Mirror.
  • APT_MIRROR_URL — URL Ihres internen APT-Mirrors (z. B. https://artifactory.example.com/artifactory/ubuntu-remote)
Gängige URL-Muster für APT-Mirror:
  • Artifactory: https://artifactory.example.com/artifactory/ubuntu-remote
  • Nexus: https://nexus.example.com/repository/ubuntu-proxy

Fortgeschrittene Nutzungsmuster

Devins Basisumgebung enthält direnv. Verwenden Sie initialize, um .envrc-Dateien zu erstellen. Direnv lädt sie automatisch.
direnv ist in Devins Shell bereits eingebunden, sodass .envrc-Variablen automatisch geladen werden. Ein manuelles Sourcing ist nicht nötig.
Für vertrauliche Umgebungsvariablen (API-Schlüssel, Tokens, Datenbankpasswörter) sollten Sie statt .envrc-Dateien Repo-Secrets verwenden und diese explizit an die Sitzungsbefehle binden, die sie benötigen. Wenn ein Secret während eines Builds in eine Datei expandiert wird, kann es trotzdem im Snapshot landen.
Verwenden Sie das vorinstallierte nvm, um Node.js-Versionen pro Repository über .nvmrc zu wechseln.
nvm use liest die .nvmrc aus dem Repo-Stammverzeichnis. Stellen Sie sicher, dass Ihr Repository eine solche Datei enthält (z. B. mit 20 als Inhalt).
Devin stellt während Sitzungen einen Chrome-Browser mit einem CDP-Endpunkt unter localhost:29229 bereit. Verwenden Sie Playwright-Skripte, um browserbasierte Anmeldungen zu automatisieren.
Der Browser ist nur während Sitzungen verfügbar, nicht in Snapshot-Builds. Installieren Sie Playwright in initialize und legen Sie die Anmeldeskripte in Ihrem Repo ab.
Beispielskript für die Anmeldung (scripts/login.py):
Speichern Sie Zugangsdaten als Secrets, nicht im Quellcode. Für eine dauerhafte Authentifizierung committen Sie Login-Skripte in .agents/skills/, damit Devin sich automatisch erneut authentifizieren kann.
Installieren Sie Systempakete, benutzerdefinierte Binärdateien und konfigurieren Sie den PATH in initialize.
Devin unterstützt das direkte Ausführen von GitHub Actions im initialize-Abschnitt eines Blueprints. Das ist nützlich, um bestimmte Tool-Versionen über dieselben Actions zu installieren, die auch in Ihrer CI verwendet werden.
Actions wie setup-node und setup-python ändern PATH und Umgebungsvariablen. Von einer Action installierte Binärdateien sind in allen nachfolgenden Schritten und in maintenance verfügbar. Node.js- und Composite-Actions werden unterstützt; Docker-Actions werden nur in Linux-Builds unterstützt. uses-Schritte können nicht in maintenance ausgeführt werden. Siehe Einschränkungen von GitHub Actions.
Für die grundlegende Einrichtung von Tools benötigen Sie keine GitHub Actions. Direkte Shell-Befehle (nvm install 20, curl ... | sh, apt-get install) funktionieren genauso gut und sind oft einfacher. GitHub Actions sind besonders nützlich, wenn Sie Ihr CI-Setup exakt nachbilden möchten oder den Komfort von Actions wie setup-java nutzen wollen, die mehrere Distributionen unterstützen.
Betreiben Sie mehrere Services unter realistisch wirkenden Hostnames per HTTPS, etwa app.example.com, api.example.com und admin.example.com. Installieren Sie in initialize einen einzelnen Reverse-Proxy und leiten Sie jeden Hostname an einen anderen lokalen Upstream-Port weiter.Caddy übernimmt Routing und lokales TLS in einem einzigen Tool. Eine Caddyfile weist jeden Hostname einem Upstream zu, und tls internal stellt automatisch für jeden Hostname ein vertrauenswürdiges Zertifikat von Caddys integrierter CA aus. caddy trust installiert dieses CA-Root im System-Trust-Store, und wenn Sie dasselbe Root auch zur NSS-Datenbank hinzufügen, akzeptiert es der Browser ebenfalls.Laden Sie Ihre Caddyfile über den Abschnitt Dateianhänge im Blueprint-Editor hoch; sie ist dann als $FILE_CADDYFILE verfügbar.
Caddyfile
Die /etc/hosts-Schleife sorgt dafür, dass app.example.com innerhalb der Sitzung auf 127.0.0.1 verweist. Fügen Sie für jeden Hostnamen, den Sie in die Caddyfile eintragen, einen Eintrag hinzu.
Um einen Service hinzuzufügen, hängen Sie einen dreizeiligen Block an die Caddyfile und fügen Sie der /etc/hosts-Schleife einen Eintrag hinzu. Rufen Sie dann den Hostnamen über HTTPS auf. Caddy stellt beim ersten Request ein Zertifikat aus, sodass keine Zertifikatserstellung pro App nötig ist.

Full-Stack-Beispiele

Diese Beispiele zeigen, wie Konfigurationen auf Enterprise- und Org-Ebene zusammenwirken. In der Praxis würden Sie diese auf verschiedene Geltungsbereiche aufteilen. Sie sind hier der Übersicht halber zusammen dargestellt.
Eine vollständige Unternehmensumgebung: Unternehmens-CA-Zertifikat, Proxy, Java (Maven), Python (pip/uv), Node.js (npm) und Docker – alles auf eine einzige Artifactory-Instanz ausgerichtet.
Netzwerk & Vertrauenseinstellungen (kontoweit):
  • CORP_ROOT_CA_B64 — Base64-kodiertes Unternehmens-CA-Zertifikat
  • CORP_HTTP_PROXY — HTTP-Proxy-URL
  • CORP_HTTPS_PROXY — HTTPS-Proxy-URL
  • CORP_NO_PROXY — Hosts, die den Proxy umgehen sollen
Registry-Anmeldedaten (organisationsweit):
  • ARTIFACTORY_USER — Artifactory-Nutzername
  • ARTIFACTORY_TOKEN — Artifactory-API-Token oder Passwort
  • ARTIFACTORY_MAVEN_URL — Maven-Repository-URL (z. B. https://artifactory.example.com/artifactory/maven-virtual)
  • ARTIFACTORY_PYPI_URL — PyPI-Repository-URL (z. B. https://user:token@artifactory.example.com/artifactory/api/pypi/pypi-virtual/simple)
  • ARTIFACTORY_NPM_URL — npm-Repository-URL (z. B. https://artifactory.example.com/artifactory/api/npm/npm-virtual)
  • ARTIFACTORY_DOCKER_URL — Docker-Registry-URL (z. B. artifactory.example.com)
Dies würde typischerweise auf drei Geltungsbereiche verteilt:
  • Kontoweit (initialize): Zertifikat und Proxy
  • Organisationsweit (initialize): Installationen von Laufzeitumgebungen für Programmiersprachen
  • Organisationsweit (maintenance): Registry-Konfiguration mit literalen Referenzen
  • Sitzungsbefehle: Secrets explizit bereitstellen, Environment-Setup per source laden und sich für einzelne Docker-Operationen anmelden
Hier zur Übersicht zusammengefasst:
In diesem Beispiel verweisen alle Registries auf dieselbe Artifactory-Instanz, verwenden jedoch unterschiedliche URL-Pfade. Jedes Paket-Ökosystem verwendet ein eigenes Endpunktformat. Maven-, PyPI-, npm- und Docker-URLs unterscheiden sich selbst bei derselben Registry.
Wenn verschiedene Sprachen unterschiedliche private Registries verwenden (z. B. Maven über Nexus, npm über GitHub Packages, Python über Artifactory).
  • NEXUS_MAVEN_URL — URL des Nexus-Maven-Repositorys
  • NEXUS_USER — Nexus-Nutzername
  • NEXUS_PASS — Nexus-Passwort
  • GITHUB_PACKAGES_TOKEN — GitHub Personal Access Token mit dem Geltungsbereich read:packages
  • ARTIFACTORY_USER — Artifactory-Nutzername
  • ARTIFACTORY_TOKEN — Artifactory-API-Token
Verbinden Sie Ihren Git-Anbieter und gewähren Sie über Git-Integrationen Zugriff auf die Repositorys, in denen die Go-Module liegen.
In einer vollständig air-gapped Umgebung kann Devin keine öffentlichen URLs erreichen. Alle Tools, Laufzeitumgebungen und Pakete müssen aus internen Mirrorn stammen.
Zertifikate:
  • CORP_ROOT_CA_B64 — Base64-kodiertes Unternehmens-CA-Zertifikat
Mirror-Zugriff:
  • APT_MIRROR_URL — URL des internen Ubuntu-APT-Mirrors
  • MIRROR_USER — Nutzername für die Authentifizierung am Mirror
  • MIRROR_PASS — Passwort für die Authentifizierung am Mirror
  • JDK_TARBALL_URL — URL zum Herunterladen des JDK-Tarballs vom internen Mirror
  • NODE_TARBALL_URL — URL zum Herunterladen des Node.js-Tarballs vom internen Mirror
Paket-Registries:
  • INTERNAL_MAVEN_URL — URL der internen Maven-Registry
  • INTERNAL_NPM_URL — URL der internen npm-Registry
  • INTERNAL_PYPI_URL — URL der internen PyPI-Registry
In Air-Gap-Umgebungen müssen alle Tools, die Devin benötigt (Laufzeitumgebungen, CLI-Tools usw.), auf Ihren internen Mirrors verfügbar sein. Öffentliche Registries und Downloadseiten sind nicht erreichbar.
Ein umfassendes Enterprise-Setup, das VPN-Tooling, Zertifikate, Proxy-Konfiguration und Mehrsprachigkeitsunterstützung kombiniert. Der Blueprint installiert Tools und speichert die Konfiguration mit literalen Referenzen. Stellen Sie die VPN-Verbindung explizit her, wenn Sie Operationen ausführen, die internen Zugriff benötigen.
VPN:
  • VPN_CONFIG_B64 — Base64-kodierte OpenVPN-Konfigurationsdatei
Netzwerk & Vertrauenseinstellungen:
  • CORP_ROOT_CA_B64 — Base64-kodiertes Unternehmens-CA-Zertifikat
  • CORP_HTTP_PROXY — HTTP-Proxy-URL
  • CORP_HTTPS_PROXY — HTTPS-Proxy-URL
  • CORP_NO_PROXY — Hosts, die den Proxy umgehen
Registry-Anmeldedaten:
  • MAVEN_REGISTRY_URL — Maven-Registry-URL
  • NPM_REGISTRY_URL — npm-Registry-URL
  • PYPI_REGISTRY_HOST — PyPI-Registry-Hostname
  • REGISTRY_USER — Registry-Nutzername (für Maven und pip)
  • REGISTRY_PASS — Registry-Passwort (für Maven und pip)
  • REGISTRY_TOKEN — npm-Auth-Token
Bootstrap-Zugriff ist erforderlich. Der OpenVPN-Client muss vorinstalliert oder installierbar sein, bevor der Tunnel aufgebaut wird. VPN_CONFIG_B64 muss Inline-Zertifikate/-Schlüssel enthalten, dev tun0 verwenden und sich ohne interaktive Authentifizierung verbinden. Die Runtime-Downloads laufen innerhalb eines Tunnel-Lifecycles und laden die Proxy-Umgebung explizit. Wiederholen Sie den VPN-Setup-/Cleanup-Block unter Netzwerk und Konnektivität für Sitzungsvorgänge; der Blueprint stellt die VPN-Verbindung zu Sitzungsbeginn nicht erneut her.

Tipps zum Schreiben guter Blueprints

  • Teste Befehle zuerst in einer Sitzung. Führe Befehle manuell in einer Devin-Sitzung aus, bevor du sie deinem Blueprint hinzufügst. Das geht schneller, als auf einen vollständigen Build-Zyklus zu warten.
  • Verwende initialize für Tools, die nur einmal installiert werden, und maintenance für Abhängigkeiten. Alles, was mehrere Minuten für die Installation braucht (Compiler, große Binärdateien, globale Tools), gehört in initialize. Schnelle Befehle für Abhängigkeiten (npm install, uv sync) gehören in maintenance.
  • Halte maintenance-Befehle schnell. Sie sollten nach Möglichkeit in unter 2 Minuten laufen. Diese Befehle werden während Builds ausgeführt und dem Agenten zu Sitzungsbeginn angezeigt.
  • Verwende $ENVRC für Umgebungsvariablen, die keine Secrets enthalten. Schreibe keine Anmeldedaten oder abgeleiteten Tokens in $ENVRC, .bashrc oder .profile. Lade Shell-Setup, das von Secrets abhängt, explizit in dem Befehl, der es benötigt.
  • Gib deinen Schritten Namen. Die erweiterte Form mit name-Feldern macht Fehler in Build-Logs deutlich leichter auffindbar.
  • Verwende Subshells für Monorepos. (cd packages/foo && npm install) läuft in einer Subshell, sodass nachfolgende Schritte nicht von der Verzeichnisänderung betroffen sind.
  • Verwende npm install, nicht npm ci. npm ci löscht node_modules und installiert alles von Grund auf neu, was für maintenance zu langsam ist.
  • Verwende Repo-Secrets für sensible Werte. Konfiguriere sie im Secrets-Tab des Blueprint-Editors des Repos, statt sie fest in Blueprints zu hinterlegen.
Details zur Syntax findest du in der Blueprint-Referenz. Hilfe zur Behebung von Build-Fehlern findest du unter Deklarative Konfiguration > Fehlerbehebung.