Skip to main content
Blueprint pronti da copiare e incollare per i linguaggi e i casi d’uso più comuni. Combinali per comporre la tua configurazione completa. Gli esempi usano Bash su Linux; sostituisci host, ambiti e comandi di esempio con i tuoi. Per una descrizione dettagliata di ogni campo, consulta il riferimento del blueprint.
Segreti: configura i segreti indicati nella scheda Segreti all’interno di ciascun editor dei blueprint. I passaggi di build ricevono i segreti del blueprint applicabili. Durante una sessione, assicurati che ogni comando riceva i segreti di cui ha bisogno: i segreti con ambito repo richiedono binding espliciti dell’ambiente exec, ad esempio env={"REGISTRY_TOKEN": "secret:repo:owner/repo:REGISTRY_TOKEN"}. Consulta Secrets. Non inserire mai credenziali in modo hardcoded nel tuo blueprint.
I passaggi di build non sono hook di avvio della sessione. initialize e maintenance vengono eseguiti durante la creazione degli snapshot; maintenance non viene eseguito automaticamente all’avvio della sessione. knowledge fornisce istruzioni a Devin, non hook eseguibili.Tieni le credenziali fuori dai file persistenti, incluso $ENVRC. La pulizia degli snapshot rimuove i file di segreti iniettati da Devin, non i file arbitrari creati dai tuoi comandi. Usa i riferimenti letterali a variabili supportati dallo strumento che li utilizza, oppure passa le credenziali nell’ambiente del comando. Quando uno strumento richiede file di credenziali, creali per una singola operazione ed eliminali prima che si concluda. Ripeti esplicitamente questa configurazione quando serve nel corso di una sessione.

Guida rapida

Blueprint essenziali per le configurazioni più comuni. Copiane uno, incollalo nell’editor dei blueprint e il gioco è fatto.

Blueprint dei repository

Passaggi di build per ciascun repo, gestione delle dipendenze e voci di Knowledge. Configurali in Settings > Ambiente > Blueprint > [il tuo repo].

Python

Configurazione consigliata per i progetti Python che usano uv per la gestione delle dipendenze.

Node.js

Configurazione Standard di Node.js con npm.
Usa npm install (non npm ci) in maintenance. Esegue un aggiornamento incrementale, mentre npm ci elimina node_modules e reinstalla tutto da zero a ogni esecuzione del comando.

Go

Configurazione standard di Go con moduli.

Java

Configurazione di Java con Gradle.
JDK 17 è preinstallato nell’immagine di base di Devin. Salta il passaggio di installazione del JDK se OpenJDK 17 predefinito è sufficiente.

Ruby on Rails

Configurazione di Rails con PostgreSQL.

Rust

Configurazione Rust standard con Cargo.
Rust (tramite rustup) e Cargo sono preinstallati nell’immagine di base di Devin. Salta il passaggio di installazione se la toolchain stabile predefinita è sufficiente. Devi solo scaricare le dipendenze.

Monorepo

Monorepo con frontend Node.js e backend Python. Ogni sottoprogetto ha le proprie voci di Knowledge.
Usa le subshell (cd dir && command) invece di cd dir && command, così la directory di lavoro viene reimpostata tra un passaggio e l’altro.

Private package registries

Configura i gestori di pacchetti in modo che risolvano le dipendenze dai registry privati. Imposta questi valori in Settings > Environment > Blueprints > Org-wide setup (oppure sul singolo repo, se serve solo a uno).
Memorizza i riferimenti, non le credenziali espanse. I delimitatori heredoc tra apici, come <<'EOF', preservano i riferimenti alle variabili all’interno del file. npm, Yarn Berry, Maven e Gradle sono in grado di risolvere i riferimenti mostrati di seguito al momento dell’esecuzione. pip non espande le variabili di shell in pip.conf: in quel caso usa le variabili d’ambiente. I file di setup della shell devono essere caricati esplicitamente con source nello stesso comando dello strumento; non dare per scontato che una nuova shell li carichi o aggiorni le credenziali.Gli URL scritti direttamente in configurazioni persistenti, come un indice Cargo, un mirror Docker o un mirror APT, non devono contenere credenziali. Mantieni l’authentication nei segreti separati mostrati in ciascun template.Se hai usato un template più vecchio che scriveva le credenziali su disco, rimuovi quei file ed esegui il rebuild da una base pulita, non da uno snapshot che le contiene. Ruota le credenziali che potrebbero essere state acquisite.
Se il tuo registry privato usa una CA corporate, assicurati di installare prima il certificato CA a livello enterprise. La configurazione seguente presuppone che l’attendibilità HTTPS sia già stabilita.

Registry Node.js

Configura npm per risolvere i pacchetti con ambito (ad es. @myorg/*) da un registry privato, mentre i pacchetti pubblici continuano a provenire dal registry npm predefinito.
  • GITHUB_PACKAGES_TOKEN — Token di accesso personale o token GitHub App con ambito read:packages
Sostituisci @myorg con il tuo scope npm. URL comuni dei registry privati:
  • 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>

Registry Python

Configura pip e uv per recuperare i pacchetti dal tuo registry PyPI privato (ad es. Nexus, Artifactory).
  • PYPI_REGISTRY_URL — URL completo del tuo indice PyPI, incluse le credenziali se richieste (ad es. https://user:token@nexus.example.com/repository/pypi-proxy/simple)
Per precaricare le dipendenze durante un build, aggiungi lo stesso comando source ... && a maintenance dopo il passaggio di configurazione. Codifica in percent-encoding i caratteri speciali nelle credenziali dell’URL.
URL comuni dei registry PyPI:
  • 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

Registry JVM

Installa il JDK e configura Maven in modo che tutta la risoluzione delle dipendenze passi attraverso il tuo registry privato (ad es., Artifactory, Nexus).
JDK 17 è preinstallato nell’immagine di base di Devin. Salta il passaggio di installazione se l’OpenJDK 17 predefinito è sufficiente. Ti servono solo l’installazione di Maven e la configurazione del registry.
  • MAVEN_REGISTRY_URL — URL del tuo registry Maven (ad es., https://artifactory.example.com/artifactory/maven-virtual)
  • REGISTRY_USER — Nome utente del registry
  • REGISTRY_PASS — Password del registry o token API
Pattern di URL comuni dei registry 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>

Altri registry

Installa Go e configuralo per risolvere i moduli tramite un proxy di moduli privato (ad es. Athens, Artifactory o un endpoint GOPROXY).
  • GO_PROXY_URL — URL del tuo proxy di moduli Go (ad es. https://athens.corp.internal)
Collega il Git provider e concedi l’accesso ai repository che ospitano i tuoi moduli privati tramite le integrazioni Git. Usa normali git URL HTTPS con l’authentication configurata di Devin. Non incorporare un token in una riscrittura del git URL.
Per precaricare la cache dei moduli durante le build, aggiungi quel comando alla sezione maintenance del blueprint del repository, dove go.mod è disponibile. Non eseguirlo nell’org-wide setup, che viene eseguito prima della clonazione dei repo.
Pattern comuni di URL per il proxy Go:
  • Artifactory: https://artifactory.example.com/artifactory/go-virtual
  • Nexus: https://nexus.example.com/repository/go-proxy
  • Athens: https://athens.corp.internal
Configura NuGet per risolvere i package da un feed privato.
  • NUGET_SOURCE_URL — URL del tuo feed NuGet
  • NuGetPackageSourceCredentials_private — Credenziali del feed nel formato environment di NuGet: Username=any;Password=<PAT> (usa lo username richiesto dal tuo feed)
Configura Docker per effettuare il pull da un container registry privato.Il login di Docker può scrivere le credenziali nella propria directory di configurazione. Usa una directory isolata per ogni operazione e rimuovila anche se il pull non riesce. Ripeti la sequenza di login e pull ogni volta che ti serve un’altra image nella stessa sessione.
  • DOCKER_MIRROR_URL (opzionale) — URL del tuo mirror di Docker Hub (ad es. https://mirror.corp.internal)
  • DOCKER_REGISTRY_URL — URL del tuo container registry privato (ad es. registry.corp.internal:5000)
  • DOCKER_REGISTRY_USER — Nome utente del registry
  • DOCKER_REGISTRY_PASS — Password o token API del registry
Per memorizzare nella cache un’image nello snapshot, inserisci la stessa subshell completa in un passaggio di build. Non suddividere login e pulizia in passaggi diversi e verifica che la pulizia vada a buon fine prima di creare l’image. L’URL di un mirror del registry non deve contenere credentials.
URL comuni dei container registry:
  • 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
Configura Cargo per risolvere i crate da un registry privato.
Rust (tramite rustup) e Cargo sono preinstallati nell’immagine di base di Devin. Salta il passaggio di installazione se la toolchain stable predefinita è sufficiente: ti serve solo la configurazione del registry.
  • CARGO_REGISTRY_INDEX — URL dell’indice del registry privato (ad es. sparse+https://cargo.corp.internal/api/v1/crates/)
  • CARGO_REGISTRIES_PRIVATE_TOKEN — Token di autenticazione per il registry denominato private
L’URL dell’index del registry non deve contenere credenziali. Il provider cargo:token di Cargo legge dall’ambiente il token del registry indicato; non eseguire cargo login in un passaggio di build.
Se devi solo aggiungere un registry privato senza sostituire crates.io, rimuovi le sezioni [source.crates-io] e [source.private] e usa cargo install --registry private oppure [dependencies] my-crate = { version = "1.0", registry = "private" } in Cargo.toml.
Installa Ruby e configura Bundler per risolvere le gem da un gem server privato.
  • GEM_SERVER_URL — URL del tuo gem server privato (ad es. https://artifactory.example.com/artifactory/api/gems/gems-virtual)
  • BUNDLE_ARTIFACTORY__EXAMPLE__COM — username:password per artifactory.example.com; modifica il nome della variabile in base al tuo gem server
Usa un GEM_SERVER_URL senza credenziali. Per la variabile delle credenziali di Bundler, anteponi BUNDLE_ all’hostname in maiuscolo, sostituisci ogni punto con __ e ogni trattino con ___.
Pattern comuni di URL dei gem server:
  • Artifactory: https://artifactory.example.com/artifactory/api/gems/gems-virtual
  • Nexus: https://nexus.example.com/repository/rubygems-proxy
  • Gemfury: https://gem.fury.io/<org>
Installa PHP e configura Composer per risolvere i pacchetti da un registry Packagist o Satis privato.
  • COMPOSER_REGISTRY_URL — URL del tuo registry Composer privato (ad es. https://repo.packagist.com/<org>)
  • COMPOSER_AUTH — credenziali JSON per l’host del registry, ad esempio {"http-basic":{"repo.packagist.com":{"username":"<user>","password":"<token>"}}}
Usa un COMPOSER_REGISTRY_URL senza credenziali.
Pattern comuni di URL per i registry Composer:
  • 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
I token di AWS CodeArtifact scadono normalmente dopo 12 ore. Crea uno script contenente riferimenti letterali, quindi eseguine esplicitamente il source nello stesso shell command di npm, pip o Maven per ottenere un token. Salvare lo script in un blueprint non ne comporta l’esecuzione all’avvio della sessione.
awscli è pre-installato sull’immagine di base di Devin. Ti servono solo l’aggiornamento del token e la configurazione del registry.
  • AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY — credenziali IAM con le autorizzazioni codeartifact:GetAuthorizationToken e sts:GetServiceBearerToken
  • CA_DOMAIN — il nome del tuo dominio CodeArtifact
  • CA_DOMAIN_OWNER — ID dell’AWS account proprietario del dominio
  • CA_REGION — regione AWS (ad es. us-east-1)
  • CA_NPM_REPO, CA_PYPI_REPO, CA_MAVEN_REPO — nomi dei repository per ciascun ecosistema
Per precaricare una cache delle dipendenze nello snapshot, aggiungi il comando source ... && appropriato come passaggio di build successivo. Il token recuperato rimane nell’ambiente di quella shell: non renderlo persistente con aws codeartifact login, con npm config set usando un token espanso o con un file pip.conf contenente credenziali.

Infrastruttura Enterprise

Infrastruttura a livello di macchina valida per tutte le org e repo. Impostala in Settings > ambiente di base di Devin (a livello di Enterprise) oppure in Settings > Environment > blueprint > configurazione a livello di org (a livello di org).

Rete e connettività

La tua organizzazione utilizza un’autorità di certificazione privata per i servizi interni. Devin richiede il certificato radice per accedere ai registry interni e agli strumenti tramite HTTPS.
  • CORP_ROOT_CA_B64 — certificato PEM codificato in Base64 della tua CA aziendale. Genera con: cat corp-root-ca.crt | base64 -w0
Questi input sono certificati pubblici. openssl x509 scrive solo il certificato analizzato, quindi un’eventuale chiave privata inclusa per errore non viene copiata nell’archivio di attendibilità. Fornisci ogni certificato CA separatamente, come nell’esempio seguente.
Se la tua organizzazione utilizza più certificati CA (ad es. CA distinte per diversi servizi interni).
  • CORP_ROOT_CA_B64 — certificato CA principale codificato in Base64
  • CORP_INTERMEDIATE_CA_B64 — certificato CA intermedio codificato in Base64
Instrada tutto il traffico di rete tramite un proxy aziendale.
  • CORP_HTTP_PROXY — URL del proxy HTTP (ad es. http://proxy.corp.example.com:8080)
  • CORP_HTTPS_PROXY — URL del proxy HTTPS
  • CORP_NO_PROXY — elenco di host, separati da virgole, da escludere dal proxy (ad es. localhost,127.0.0.1,.corp.example.com)
Se il proxy aziendale richiede l’autenticazione tramite nome utente/password.
  • PROXY_USER — Nome utente del proxy
  • PROXY_PASS — Password del proxy
  • PROXY_HOST — hostname e porta del proxy (ad es. proxy.corp.example.com:8080)
  • CORP_NO_PROXY — host da escludere dal proxy
Applica la codifica percent-encoding ai caratteri speciali nel nome utente e nella password del proxy. Git e npm possono utilizzare le variabili d’ambiente del proxy; non copiare un URL del proxy contenente credenziali nella loro configurazione persistente.
Configurazione combinata per ambienti che richiedono sia una CA aziendale sia un proxy. Questa configurazione è comune negli ambienti enterprise in cui i servizi interni usano certificati privati e tutto il traffico deve passare tramite un proxy.
  • CORP_ROOT_CA_B64 — certificato CA aziendale codificato in Base64
  • CORP_HTTP_PROXY, CORP_HTTPS_PROXY — URL del proxy
  • CORP_NO_PROXY — host da escludere dal proxy
I tuoi registry privati, i server Git o altri servizi interni sono raggiungibili solo tramite VPN. Installa il client VPN nel blueprint. Stabilisci il tunnel esplicitamente per le operazioni che lo richiedono, quindi disconnettiti e rimuovi i file delle credenziali al termine.
OpenVPN:
  • VPN_CONFIG_B64 — file di configurazione OpenVPN (.ovpn) codificato in Base64. Genera con: cat corp.ovpn | base64 -w0
  • VPN_AUTH_USER (facoltativo) — nome utente VPN, se la VPN richiede l’autenticazione con nome utente/password
  • VPN_AUTH_PASS (facoltativo) — password VPN
WireGuard:
  • WG_CONFIG_B64 — file di configurazione WireGuard codificato in Base64. Genera con: cat wg0.conf | base64 -w0
OpenVPN:
Esegui esplicitamente questo block in una sessione in cui i segreti VPN sono disponibili. Sostituisci il comando curl con l’operazione che richiede il tunnel. La configurazione deve contenere inline i certificati e le chiavi richiesti e usare dev tun0; non abilitare un servizio VPN persistente.
WireGuard:
Esegui esplicitamente questo block con WG_CONFIG_B64 disponibile, sostituendo il comando curl con la tua operazione:
Se un build dello snapshot richiede l’accesso VPN, racchiudi tutto il lavoro dipendente nello stesso block, in modo che la pulizia venga completata prima della creazione dell’immagine. Spostare semplicemente la scrittura delle credential in maintenance non le rende temporanee. Non includere nello snapshot un tunnel attivo o una configurazione VPN privata.
Per maggiori dettagli sulla configurazione della VPN, consulta Configurazione della VPN.
I tuoi servizi interni utilizzano nomi DNS privati che non possono essere risolti dal DNS pubblico.

Identità e sicurezza

La tua organizzazione richiede che tutti i commit Git siano firmati e vuoi che GitHub contrassegni i commit di Devin come Verified.
  • GPG_PRIVATE_KEY_B64 — chiave privata GPG codificata in Base64. Generala con: gpg --export-secret-keys <key-id> | base64 -w0
  • GPG_SIGNING_KEY — impronta completa della chiave di firma
  • GIT_USER_NAME — nome dell’autore Git (ad es. Devin AI)
  • GIT_USER_EMAIL — email dell’autore Git. Deve corrispondere a un UID della chiave GPG, altrimenti GitHub non verificherà la firma.
Carica anche la chiave pubblica corrispondente sull’account GitHub le cui credenziali Devin usa per il push (in GitHub Settings > SSH and GPG keys). GitHub contrassegna i commit come Verified solo se la chiave pubblica di firma è registrata sull’account che ha creato il commit.
Non importare chiavi di firma private durante le build dello snapshot. Dopo aver preparato le modifiche desiderate, esegui esplicitamente questo blocco in una sessione in cui i segreti indicati sono disponibili. Il blocco utilizza un keyring temporaneo e impostazioni Git valide solo per questo commit:
Se la chiave richiede una passphrase, completa il flusso approvato dell’agente GPG/pinentry durante l’operazione. Non salvare la passphrase o il keyring nel blueprint o nello snapshot. Ripeti la configurazione del keyring temporaneo per i commit o i tag firmati successivi.
Configura l’identità Git e le chiavi SSH di Devin per accedere a server Git privati.Per i Git provider supportati, usa preferibilmente le Git integrations. Per un server che richiede una chiave SSH esplicita, tieni la chiave privata fuori dalla build del blueprint e usala solo per l’operazione di sessione descritta di seguito.
  • GIT_USER_NAME — nome dell’autore Git
  • GIT_USER_EMAIL — email dell’autore Git
  • SSH_PRIVATE_KEY_B64 — chiave privata SSH codificata in Base64. Generala con: cat ~/.ssh/id_ed25519 | base64 -w0
  • SSH_KNOWN_HOSTS_B64 — voci di known hosts codificate in Base64 e verificate rispetto alle impronte delle chiavi host pubblicate dall’amministratore del tuo server
Esegui esplicitamente questo blocco nella sessione, sostituendo l’URL Git con quello del tuo server e della tua repo:
Se ti servono opzioni SSH personalizzate, aggiungile a questa invocazione senza copiare una chiave privata in una configurazione SSH persistente o nella home directory. Ripeti la configurazione per ogni operazione.

Configurazione del sistema

Installa pacchetti di sistema che non sono presenti nell’immagine Devin predefinita (ad es. librerie native per l’elaborazione delle immagini o la generazione di PDF).
Imposta variabili d’ambiente persistenti e non segrete da rendere disponibili in ogni sessione. Non scrivere valori segreti o credenziali derivate in $ENVRC.L’approccio consigliato è scrivere righe KEY=VALUE nel file $ENVRC. Le variabili scritte in $ENVRC vengono esportate automaticamente per tutti i passaggi successivi e per la sessione di Devin (in modo analogo a $GITHUB_ENV di GitHub Actions).
Puoi anche scrivere le variabili d’ambiente negli script in /etc/profile.d/ per renderle disponibili a livello di sistema:
Entrambi gli approcci funzionano. $ENVRC è più semplice ed è consigliato nella maggior parte dei casi.
Le immagini di base predefinite potrebbero avere impostazioni del locale non corrette. Configura il locale e il fuso orario per evitare avvisi da strumenti di build, Java, Python e Git.
Le build Java, Gradle e Node.js raggiungono spesso il limite predefinito di 1024 file aperti. Aumentalo per evitare errori di build.
In ambienti air-gapped o soggetti a restrizioni, sostituisci i repository APT predefiniti di Ubuntu con un mirror interno.
  • APT_MIRROR_URL — URL del tuo mirror APT interno (ad es. https://artifactory.example.com/artifactory/ubuntu-remote)
Pattern di URL comuni per i mirror APT:
  • Artifactory: https://artifactory.example.com/artifactory/ubuntu-remote
  • Nexus: https://nexus.example.com/repository/ubuntu-proxy

Pattern avanzati

L’ambiente di base di Devin include direnv. Usa initialize per creare i file .envrc. Direnv li carica automaticamente.
direnv è già configurato nella shell di Devin, quindi le variabili di .envrc vengono caricate automaticamente. Non serve eseguire il source manualmente.
Per le variabili d’ambiente sensibili (API key, token, password del database), usa i segreti del repo invece dei file .envrc e associali esplicitamente ai comandi della sessione che ne hanno bisogno. Espandere un segreto in un file durante una build può comunque farlo finire nello snapshot.
Usa nvm (preinstallato) per cambiare versione di Node.js per ciascun repository tramite .nvmrc.
nvm use legge .nvmrc dalla directory radice della repo. Assicurati che il repository ne abbia uno (ad es., contenente 20).
Devin mette a disposizione un browser Chrome con un endpoint CDP su localhost:29229 durante le sessioni. Usa script Playwright per automatizzare il login nel browser.
Il browser è disponibile solo durante le sessioni, non nelle build snapshot. Installa Playwright in initialize e conserva gli script di login nella tua repo.
Esempio di script di accesso (scripts/login.py):
Conserva le credenziali di accesso come secrets, non nel codice sorgente. Per un’autenticazione a lungo termine, esegui il commit degli script di accesso in .agents/skills/ in modo che Devin possa riautenticarsi automaticamente.
Installa pacchetti di sistema, binari personalizzati e configura il PATH in initialize.
Devin supporta l’esecuzione diretta di GitHub Actions nella sezione initialize di un blueprint. Questo è utile per installare versioni specifiche degli strumenti tramite le stesse azioni usate dalla tua CI.
Azioni come setup-node e setup-python modificano il PATH e le variabili d’ambiente. I binari installati da un’azione sono disponibili in tutti i passaggi successivi e in maintenance. Le azioni Node.js e quelle composite sono supportate; le azioni Docker sono supportate solo nelle build Linux. I passaggi uses non possono essere eseguiti in maintenance. Vedi limitazioni delle GitHub Actions.
Non servono GitHub Actions per la configurazione di base degli strumenti. I comandi shell diretti (nvm install 20, curl ... | sh, apt-get install) funzionano altrettanto bene e spesso sono più semplici. Le GitHub Actions sono particolarmente utili quando vuoi replicare esattamente la configurazione della tua CI o sfruttare la comodità di azioni come setup-java, che gestiscono più distribuzioni.
Esegui più servizi dietro hostname dall’aspetto realistico su HTTPS, come app.example.com, api.example.com e admin.example.com. Installa un singolo proxy inverso in initialize e instrada ogni hostname verso una porta upstream locale diversa.Caddy gestisce il routing e il TLS locale in un unico strumento. Un Caddyfile associa ogni hostname a un upstream e tls internal emette automaticamente un certificato attendibile per ciascun hostname dalla CA integrata di Caddy. caddy trust installa la root di quella CA nell’archivio di attendibilità del sistema e, aggiungendo la stessa root al database NSS, il browser la accetterà.Carica il Caddyfile tramite la sezione File allegati dell’editor del blueprint; sarà quindi disponibile come $FILE_CADDYFILE.
Caddyfile
Il loop di /etc/hosts è ciò che consente a app.example.com di risolversi in 127.0.0.1 all’interno della sessione. Aggiungi una voce per ogni hostname che inserisci nel Caddyfile.
Per aggiungere un servizio, aggiungi un blocco di tre righe al Caddyfile e una voce al loop di /etc/hosts, quindi apri il relativo hostname tramite HTTPS. Caddy genera un certificato alla prima richiesta, quindi non è necessario generare certificati separati per ogni app.

Esempi full-stack

Questi esempi mostrano come si combinano le configurazioni Enterprise e quelle a livello di org. In pratica, le divideresti tra diversi ambiti. Qui sono riunite a scopo di riferimento.
Un ambiente enterprise completo: certificato CA aziendale, proxy, Java (Maven), Python (pip/uv), Node.js (npm) e Docker, tutti puntati a una singola istanza di Artifactory.
Rete e attendibilità (per l’intero account):
  • CORP_ROOT_CA_B64 — certificato CA aziendale codificato in Base64
  • CORP_HTTP_PROXY — URL del proxy HTTP
  • CORP_HTTPS_PROXY — URL del proxy HTTPS
  • CORP_NO_PROXY — host da escludere dal proxy
Credenziali del registry (per l’intera org):
  • ARTIFACTORY_USER — nome utente Artifactory
  • ARTIFACTORY_TOKEN — token API o password di Artifactory
  • ARTIFACTORY_MAVEN_URL — URL del repository Maven (ad es., https://artifactory.example.com/artifactory/maven-virtual)
  • ARTIFACTORY_PYPI_URL — URL del repository PyPI (ad es., https://user:token@artifactory.example.com/artifactory/api/pypi/pypi-virtual/simple)
  • ARTIFACTORY_NPM_URL — URL del repository npm (ad es., https://artifactory.example.com/artifactory/api/npm/npm-virtual)
  • ARTIFACTORY_DOCKER_URL — URL del registry Docker (ad es., artifactory.example.com)
In genere questo verrebbe suddiviso in tre ambiti:
  • A livello di account (initialize): Certificato e proxy
  • Org-wide (initialize): Installazione del runtime del linguaggio
  • A livello di org (maintenance): configurazione del registry contenente riferimenti letterali
  • Comandi di sessione: fornire esplicitamente i segreti, caricare l’environment setup ed effettuare il login per singole operazioni Docker
Di seguito il codice completo per riferimento:
In questo esempio, tutti i registry puntano alla stessa istanza di Artifactory, ma utilizzano percorsi URL diversi. Ogni ecosistema di pacchetti ha il proprio formato di endpoint. Gli URL di Maven, PyPI, npm e Docker sono tutti diversi, anche per lo stesso registry.
Quando linguaggi diversi usano registry privati diversi (ad es. Maven da Nexus, npm da GitHub Packages, Python da Artifactory).
  • NEXUS_MAVEN_URL — URL del repository Maven di Nexus
  • NEXUS_USER — nome utente di Nexus
  • NEXUS_PASS — password di Nexus
  • GITHUB_PACKAGES_TOKEN — token di accesso personale di GitHub con ambito read:packages
  • ARTIFACTORY_USER — nome utente di Artifactory
  • ARTIFACTORY_TOKEN — token API di Artifactory
Collega il tuo Git provider e concedi l’accesso ai repository che ospitano i moduli Go tramite le integrazioni Git.
In un ambiente completamente air-gapped, Devin non può accedere ad alcun URL pubblico. Tutti gli strumenti, i runtime e i pacchetti devono provenire da mirror interni.
Certificati:
  • CORP_ROOT_CA_B64 — certificato CA aziendale codificato in Base64
Accesso ai mirror:
  • APT_MIRROR_URL — URL del mirror APT interno di Ubuntu
  • MIRROR_USER — nome utente per l’autenticazione al mirror
  • MIRROR_PASS — password per l’autenticazione al mirror
  • JDK_TARBALL_URL — URL da cui scaricare il tarball JDK dal mirror interno
  • NODE_TARBALL_URL — URL da cui scaricare il tarball Node.js dal mirror interno
Registry dei pacchetti:
  • INTERNAL_MAVEN_URL — URL del registry Maven interno
  • INTERNAL_NPM_URL — URL del registry npm interno
  • INTERNAL_PYPI_URL — URL del registry PyPI interno
Negli ambienti air-gapped, tutti gli strumenti necessari a Devin (runtime dei linguaggi di programmazione, strumenti CLI, ecc.) devono essere disponibili sui vostri mirror interni. I registry pubblici e i siti di download non sono raggiungibili.
Una configurazione Enterprise completa che combina strumenti VPN, certificati, configurazione del proxy e supporto multilingua. Il blueprint installa gli strumenti e memorizza la configurazione con riferimenti letterali. Connetti esplicitamente la VPN quando esegui operazioni che richiedono accesso interno.
VPN:
  • VPN_CONFIG_B64 — file di configurazione OpenVPN codificato in Base64
Rete & attendibilità:
  • CORP_ROOT_CA_B64 — certificato CA aziendale codificato in Base64
  • CORP_HTTP_PROXY — URL del proxy HTTP
  • CORP_HTTPS_PROXY — URL del proxy HTTPS
  • CORP_NO_PROXY — host da escludere dal proxy
Credenziali del registry:
  • MAVEN_REGISTRY_URL — URL del registry Maven
  • NPM_REGISTRY_URL — URL del registry npm
  • PYPI_REGISTRY_HOST — hostname del registry PyPI
  • REGISTRY_USER — nome utente del registry (per Maven e pip)
  • REGISTRY_PASS — password del registry (per Maven e pip)
  • REGISTRY_TOKEN — token di autenticazione per npm
È richiesto l’accesso bootstrap. Il client OpenVPN deve essere preinstallato o installabile prima di stabilire il tunnel. VPN_CONFIG_B64 deve contenere certificati/chiavi inline, usare dev tun0 e connettersi senza authentication interattiva. I download dei runtime vengono eseguiti all’interno di un unico lifecycle del tunnel e caricano esplicitamente l’ambiente del proxy. Ripeti il block di setup/pulizia della VPN riportato in Rete e connettività per le operazioni di sessione; il blueprint non riconnette la VPN all’avvio della sessione.

Suggerimenti per scrivere blueprint efficaci

  • Prova prima i comandi in una sessione. Esegui i comandi manualmente in una sessione di Devin prima di aggiungerli al blueprint. È più veloce che aspettare un ciclo di build completo.
  • Usa initialize per gli strumenti da installare una sola volta, maintenance per le dipendenze. Tutto ciò che richiede minuti per essere installato (compilatori, binari di grandi dimensioni, strumenti globali) va in initialize. I comandi rapidi per le dipendenze (npm install, uv sync) vanno in maintenance.
  • Mantieni rapidi i comandi maintenance. Cerca di restare sotto i 2 minuti. Vengono eseguiti durante le build e vengono mostrati all’agente all’inizio della sessione.
  • Usa $ENVRC per le variabili d’ambiente non sensibili. Non scrivere credenziali o token derivati in $ENVRC, .bashrc o .profile. Carica esplicitamente la configurazione della shell che dipende dai segreti nel comando che ne ha bisogno.
  • Assegna un nome ai passaggi. La forma estesa con i campi name rende molto più semplice individuare gli errori nei log di build.
  • Usa le subshell per i monorepo. (cd packages/foo && npm install) viene eseguito in una subshell, così i passaggi successivi non risentono del cambio di directory.
  • Usa npm install, non npm ci. npm ci elimina node_modules e reinstalla tutto da zero, rallentando maintenance.
  • Usa i segreti del repo per i valori sensibili. Configurali nella scheda Segreti dell’editor del blueprint del repository invece di inserirli direttamente nei blueprint.
Per i dettagli sulla sintassi, consulta il riferimento del blueprint. Per risolvere gli errori di build, consulta Configurazione dichiarativa > Risoluzione dei problemi.