Skip to main content
Blueprints prontos para copiar e colar, voltados a linguagens e casos de uso comuns. Combine-os para montar sua configuração completa. Os exemplos usam Bash no Linux; substitua os hosts, escopos e comandos de exemplo pelos seus. Para um detalhamento completo de cada campo, consulte a Referência de blueprints.
Segredos: configure os segredos nomeados na aba Secrets dentro de cada editor de blueprint. As etapas de build recebem os segredos aplicáveis do blueprint. Durante uma sessão, garanta que cada comando receba os segredos de que precisa: segredos com escopo de repo exigem vínculos explícitos de ambiente no exec, como env={"REGISTRY_TOKEN": "secret:repo:owner/repo:REGISTRY_TOKEN"}. Consulte Segredos. Nunca deixe credenciais fixas no código do seu blueprint.
Etapas de build não são hooks de inicialização de sessão. initialize e maintenance são executados durante a criação de snapshots; maintenance não é executado automaticamente no início da sessão. knowledge fornece instruções ao Devin, não hooks executáveis.Mantenha credenciais fora de arquivos persistentes, inclusive do $ENVRC. A limpeza de snapshot remove os arquivos de segredo injetados pelo Devin, não arquivos arbitrários criados pelos seus comandos. Use referências literais de variáveis suportadas pela ferramenta que as consome, ou passe as credenciais no ambiente do comando. Quando uma ferramenta exigir arquivos de credenciais, crie-os para uma única operação e apague-os antes que ela termine. Repita essa configuração explicitamente quando necessário dentro de uma sessão.

Início rápido

Blueprints mínimos para as configurações mais comuns. Copie um, cole no editor de blueprints e pronto.

Blueprints de repositório

Etapas de build por repositório, gerenciamento de dependências e entradas do Knowledge. Defina isso em Configurações > Ambiente > blueprint > [seu repositório].

Python

Configuração recomendada para projetos em Python que usam uv para gerenciamento de dependências.

Node.js

Configuração padrão do Node.js com npm.
Use npm install (não npm ci) em maintenance. Ele faz uma atualização incremental, enquanto npm ci exclui node_modules e reinstala tudo do zero a cada execução do comando.

Go

Configuração padrão de Go com módulos.

Java

Configuração do Java com Gradle.
O JDK 17 já vem pré-instalado na imagem base do Devin. Pule a etapa de instalação do JDK se o OpenJDK 17 padrão for suficiente.

Ruby on Rails

Configuração do Rails com PostgreSQL.

Rust

Configuração padrão do Rust com Cargo.
Rust (via rustup) e Cargo já vêm pré-instalados na imagem base do Devin. Pule a etapa de instalação se a toolchain estável padrão for suficiente. Você só precisa baixar as dependências.

Monorepos

Monorepo com frontend em Node.js e backend em Python. Cada subprojeto recebe suas próprias entradas no Knowledge.
Use subshells (cd dir && command) em vez de cd dir && command, para que o diretório de trabalho seja redefinido entre as etapas.

Registros privados de pacotes

Configure os gerenciadores de pacotes para resolver dependências a partir de registros privados. Defina isso em Configurações > Ambiente > Blueprints > configuração em nível da organização (ou por repositório, se apenas um repositório precisar).
Armazene referências, não credenciais expandidas. Delimitadores de heredoc entre aspas, como <<'EOF', preservam as referências de variáveis no arquivo. npm, Yarn Berry, Maven e Gradle conseguem resolver as referências mostradas abaixo quando são executados. O pip não expande variáveis de shell em pip.conf, então use variáveis de ambiente nesse caso. Os arquivos de configuração do shell precisam ser carregados explicitamente com source no mesmo comando da ferramenta; não presuma que um novo shell os carregue ou atualize as credenciais.URLs gravadas diretamente em configurações persistentes, como um índice do Cargo, um mirror do Docker ou um mirror do APT, não podem conter credenciais. Mantenha a autenticação nos segredos separados mostrados em cada template.Se você usou um template mais antigo que gravava credenciais em disco, remova esses arquivos e refaça o build a partir de uma base limpa, e não de um snapshot que as contenha. Rotacione as credenciais que possam ter sido capturadas.
Se o seu registro privado usa uma CA corporativa, verifique antes se o certificado de CA está instalado no nível Enterprise. A configuração abaixo pressupõe que a confiança HTTPS já foi estabelecida.

Registros do Node.js

Configure o npm para resolver pacotes com escopo (por exemplo, @myorg/*) a partir de um registro privado, enquanto os pacotes públicos continuam vindo do registro padrão do npm.
  • GITHUB_PACKAGES_TOKEN — Token de acesso pessoal ou token do GitHub App com o escopo read:packages
Substitua @myorg pelo seu escopo do npm. URLs comuns de registros privados:
  • 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>

Registros do Python

Configure o pip e o uv para resolver pacotes do seu registro PyPI privado (por exemplo, Nexus, Artifactory).
  • PYPI_REGISTRY_URL — URL completa do seu índice PyPI, incluindo credenciais, se necessário (por exemplo, https://user:token@nexus.example.com/repository/pypi-proxy/simple)
Para pré-carregar dependências durante um build, adicione o mesmo comando source ... && em maintenance após a etapa de configuração. Codifique em percent-encoding os caracteres especiais nas credenciais da URL.
Padrões comuns de URL para registros 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

Registros da JVM

Instale o JDK e configure o Maven para usar seu registro privado como espelho para toda a resolução de dependências (por exemplo, Artifactory, Nexus).
O JDK 17 vem pré-instalado na imagem base do Devin. Pule a etapa de instalação se o OpenJDK 17 padrão for suficiente. Você só precisa instalar o Maven e configurar o registro.
  • MAVEN_REGISTRY_URL — URL do seu registro Maven (por exemplo, https://artifactory.example.com/artifactory/maven-virtual)
  • REGISTRY_USER — Nome de usuário do registro
  • REGISTRY_PASS — Senha do registro ou token de API
Padrões comuns de URL de registro do 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>

Outros registros

Instale o Go e configure-o para resolver módulos por meio de um proxy de módulos privado (por exemplo, Athens, Artifactory ou um endpoint GOPROXY).
  • GO_PROXY_URL — URL do seu proxy de módulos Go (por exemplo, https://athens.corp.internal)
Conecte o Git provider e conceda acesso aos repositórios que hospedam seus módulos privados por meio das integrações com o Git. Use URLs do git HTTPS comuns com a autenticação já configurada do Devin. Não inclua um token em uma regra de reescrita de URL do git.
Para aquecer o cache de módulos durante os builds, adicione esse comando ao maintenance do blueprint do repositório, onde o go.mod está disponível. Não o execute na configuração de nível da organização, que é executada antes de os repositórios serem clonados.
Padrões comuns de URL de proxy Go:
  • Artifactory: https://artifactory.example.com/artifactory/go-virtual
  • Nexus: https://nexus.example.com/repository/go-proxy
  • Athens: https://athens.corp.internal
Configure o NuGet para resolver pacotes de um feed privado.
  • NUGET_SOURCE_URL — URL do seu feed NuGet
  • NuGetPackageSourceCredentials_private — Credenciais do feed no formato de ambiente do NuGet: Username=any;Password=<PAT> (use o nome de usuário exigido pelo seu feed)
Configure o Docker para fazer pull de um registro de contêineres privado.O login do Docker pode gravar credenciais no seu diretório de configuração. Use um diretório isolado para cada operação e remova-o mesmo que o pull falhe. Execute a sequência de login e pull novamente sempre que precisar de outra imagem em uma sessão.
  • DOCKER_MIRROR_URL (opcional) — URL do seu mirror do Docker Hub (ex.: https://mirror.corp.internal)
  • DOCKER_REGISTRY_URL — URL do seu registro de contêineres privado (ex.: registry.corp.internal:5000)
  • DOCKER_REGISTRY_USER — Nome de usuário do registro
  • DOCKER_REGISTRY_PASS — Senha do registro ou token de API
Para armazenar uma image em cache no snapshot, coloque o mesmo subshell completo em uma etapa de build. Não divida o login e a limpeza em etapas separadas e verifique se a limpeza foi concluída com sucesso antes de gerar a image. A URL de um mirror de registro não pode conter credentials.
URLs comuns de 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
Configure o Cargo para resolver crates de um registro privado.
Rust (via rustup) e Cargo já vêm pré-instalados na imagem base do Devin. Pule a etapa de instalação se a toolchain stable padrão for suficiente. Você só precisa da configuração do registro.
  • CARGO_REGISTRY_INDEX — URL do índice do registro privado (por exemplo, sparse+https://cargo.corp.internal/api/v1/crates/)
  • CARGO_REGISTRIES_PRIVATE_TOKEN — Token de autenticação do registro chamado private
A URL do índice do registro não deve conter credenciais. O provedor cargo:token do Cargo lê o token do registro nomeado a partir do ambiente; não execute cargo login em uma etapa de build.
Se você só precisa adicionar um registro privado sem substituir o crates.io, remova as seções [source.crates-io] e [source.private] e use cargo install --registry private ou [dependencies] my-crate = { version = "1.0", registry = "private" } no Cargo.toml.
Instale o Ruby e configure o Bundler para resolver gems a partir de um servidor de gems privado.
  • GEM_SERVER_URL — URL do seu servidor de gems privado (ex.: https://artifactory.example.com/artifactory/api/gems/gems-virtual)
  • BUNDLE_ARTIFACTORY__EXAMPLE__COM — username:password de artifactory.example.com; altere o nome da variável para corresponder ao seu servidor de gems
Use uma GEM_SERVER_URL sem credenciais. Para a variável de credencial do Bundler, adicione o prefixo BUNDLE_ ao hostname em maiúsculas, substitua cada ponto por __ e cada hífen por ___.
Padrões comuns de URL de 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>
Instale o PHP e configure o Composer para resolver pacotes de um registro privado do Packagist ou Satis.
  • COMPOSER_REGISTRY_URL — URL do seu registro privado do Composer (por exemplo, https://repo.packagist.com/<org>)
  • COMPOSER_AUTH — credenciais JSON do host do registro, como {"http-basic":{"repo.packagist.com":{"username":"<user>","password":"<token>"}}}
Use uma COMPOSER_REGISTRY_URL sem credenciais.
Padrões comuns de URL de registro do 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
Os tokens do AWS CodeArtifact normalmente expiram após 12 horas. Crie um script contendo referências literais e depois carregue-o explicitamente com source no mesmo shell command que npm, pip ou Maven para obter um token. Salvar o script em um blueprint não faz com que ele seja executado no início da sessão.
O awscli já vem pré-instalado na imagem base do Devin. Você só precisa cuidar da atualização do token e da configuração do registro.
  • AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY — credenciais do IAM com as permissões codeartifact:GetAuthorizationToken e sts:GetServiceBearerToken
  • CA_DOMAIN — o nome do seu domínio no CodeArtifact
  • CA_DOMAIN_OWNER — ID da AWS account proprietária do domínio
  • CA_REGION — região da AWS (por exemplo, us-east-1)
  • CA_NPM_REPO, CA_PYPI_REPO, CA_MAVEN_REPO — nomes dos repositórios de cada ecossistema
Para pré-aquecer um cache de dependências no snapshot, adicione o comando source ... && apropriado como uma etapa posterior do build. O token obtido permanece no ambiente daquele shell; não o torne persistente com aws codeartifact login, com npm config set usando um token expandido ou com um pip.conf que contenha credenciais.

Infraestrutura do Enterprise

Infraestrutura no nível da máquina que se aplica a todas as org e repositórios. Configure isso em Configurações > ambiente base do Devin (para toda a Enterprise) ou em Configurações > ambiente > Blueprints > configuração em nível da organização (no nível da organização).

Rede e conectividade

Sua organização usa uma autoridade certificadora privada para serviços internos. Devin precisa do certificado raiz para acessar registros e ferramentas internos via HTTPS.
  • CORP_ROOT_CA_B64 — certificado PEM codificado em Base64 da sua CA corporativa. Gere com: cat corp-root-ca.crt | base64 -w0
Essas entradas são certificados públicos. O openssl x509 grava apenas o certificado analisado, de modo que uma chave privada incluída acidentalmente não é copiada para o repositório de confiança. Forneça cada certificado de CA separadamente, como no próximo exemplo.
Se a sua organização usar vários certificados de CA (por exemplo, CAs separadas para diferentes serviços internos).
  • CORP_ROOT_CA_B64 — certificado de CA principal codificado em Base64
  • CORP_INTERMEDIATE_CA_B64 — certificado de CA intermediário codificado em Base64
Encaminhe todo o tráfego de rede por meio de um proxy corporativo.
  • CORP_HTTP_PROXY — URL do proxy HTTP (por exemplo, http://proxy.corp.example.com:8080)
  • CORP_HTTPS_PROXY — URL do proxy HTTPS
  • CORP_NO_PROXY — Lista de hosts separados por vírgula que devem ignorar o proxy (por exemplo, localhost,127.0.0.1,.corp.example.com)
Se o seu proxy corporativo exigir autenticação com nome de usuário e senha.
  • PROXY_USER — Nome de usuário do proxy
  • PROXY_PASS — Senha do proxy
  • PROXY_HOST — Host e porta do proxy (por exemplo, proxy.corp.example.com:8080)
  • CORP_NO_PROXY — Hosts que devem ignorar o proxy
Aplique percent-encoding aos caracteres especiais no nome de usuário e na senha do proxy. Git e npm podem usar variáveis de ambiente de proxy; não copie uma URL de proxy com credenciais para a configuração persistente dessas ferramentas.
Configuração combinada para ambientes que exigem tanto uma CA corporativa quanto um proxy. Isso é comum em ambientes corporativos em que serviços internos usam certificados privados e todo o tráfego precisa passar por um proxy.
  • CORP_ROOT_CA_B64 — certificado de CA corporativa codificado em Base64
  • CORP_HTTP_PROXY, CORP_HTTPS_PROXY — URLs do proxy
  • CORP_NO_PROXY — Hosts que ignoram o proxy
Seus registros privados, servidores Git ou outros serviços internos só podem ser acessados por VPN. Instale o cliente VPN no blueprint. Estabeleça o túnel explicitamente para as operações que precisam dele e, depois, desconecte e remova os arquivos de credenciais.
OpenVPN:
  • VPN_CONFIG_B64 — Arquivo de configuração do OpenVPN (.ovpn) codificado em Base64. Gere com: cat corp.ovpn | base64 -w0
  • VPN_AUTH_USER (opcional) — Nome de usuário da VPN, caso sua VPN exija autenticação com nome de usuário e senha
  • VPN_AUTH_PASS (opcional) — Senha da VPN
WireGuard:
  • WG_CONFIG_B64 — Arquivo de configuração do WireGuard codificado em Base64. Gere com: cat wg0.conf | base64 -w0
OpenVPN:
Execute este bloco explicitamente em uma sessão com os segredos da VPN disponíveis. Substitua o comando curl pelo trabalho que precisa do túnel. A configuração deve conter inline os certificados e as chaves necessários e usar dev tun0; não ative um serviço de VPN persistente.
WireGuard:
Execute este bloco explicitamente com WG_CONFIG_B64 disponível, substituindo o comando curl pela sua operação:
Se um build do snapshot precisar de acesso à VPN, agrupe todo o trabalho dependente no mesmo block para que a limpeza termine antes da geração da imagem. Apenas mover a gravação de credenciais para maintenance não as torna temporárias. Não faça snapshot de um túnel ativo nem de uma configuração de VPN privada.
Para mais detalhes sobre a configuração da VPN, consulte Configuração da VPN.
Seus serviços internos usam nomes de DNS privados que não são resolvidos pelo DNS público.

Identidade e segurança

Sua organização exige que todos os commits Git sejam assinados, e você quer que o GitHub marque os commits do Devin como Verified.
  • GPG_PRIVATE_KEY_B64 — chave privada GPG codificada em Base64. Gere com: gpg --export-secret-keys <key-id> | base64 -w0
  • GPG_SIGNING_KEY — impressão digital completa da chave de assinatura
  • GIT_USER_NAME — nome do autor no Git (ex.: Devin AI)
  • GIT_USER_EMAIL — e-mail do autor no Git. Deve corresponder a um UID da chave GPG, caso contrário o GitHub não verificará a assinatura.
Importe também a chave pública correspondente para a conta do GitHub cujas credenciais o Devin usa para fazer push (em Configurações do GitHub > SSH and GPG keys). O GitHub só marca commits como Verified quando a chave pública de assinatura está registrada na conta que criou o commit.
Não importe chaves privadas de assinatura durante builds do snapshot. Depois de preparar as alterações desejadas, execute explicitamente este bloco em uma sessão com os segredos nomeados disponíveis. Ele usa um keyring temporário e configurações do Git válidas apenas para este commit:
Se sua chave exigir uma senha, conclua o fluxo aprovado de agente GPG/pinentry durante a operação. Não salve a senha nem o keyring no blueprint ou no snapshot. Repita a configuração do keyring temporário para commits posteriores ou tags assinadas.
Configure a identidade Git e as chaves SSH do Devin para acessar servidores Git privados.Prefira as integrações com o Git nos Git providers compatíveis. Para um servidor que exija uma chave SSH explícita, mantenha a chave privada fora do build do blueprint e use-a apenas na operação de sessão abaixo.
  • GIT_USER_NAME — nome do autor no Git
  • GIT_USER_EMAIL — e-mail do autor no Git
  • SSH_PRIVATE_KEY_B64 — chave privada SSH codificada em Base64. Gere com: cat ~/.ssh/id_ed25519 | base64 -w0
  • SSH_KNOWN_HOSTS_B64 — entradas de known hosts codificadas em Base64, verificadas com as impressões digitais das chaves de host publicadas pelo administrador do seu servidor
Execute este bloco explicitamente na sessão, substituindo a URL do Git pela do seu servidor e repositório:
Se precisar de opções SSH personalizadas, adicione-as a esta invocação sem copiar uma chave privada para um arquivo de configuração SSH persistente ou para o diretório home. Repita a configuração a cada operação.

Configuração do sistema

Instale pacotes no nível do sistema que não estão na imagem padrão do Devin (por exemplo, bibliotecas nativas para processamento de imagens ou geração de PDF).
Defina variáveis de ambiente persistentes e não sensíveis que devem estar disponíveis em todas as sessões. Não grave valores de segredos ou credenciais derivadas em $ENVRC.A abordagem recomendada é gravar linhas KEY=VALUE no arquivo $ENVRC. As variáveis gravadas em $ENVRC são exportadas automaticamente para todas as etapas seguintes e para a sessão do Devin (semelhante ao $GITHUB_ENV do GitHub Actions).
Você também pode definir variáveis de ambiente em scripts de /etc/profile.d/ para que fiquem disponíveis em todo o sistema:
As duas abordagens funcionam. $ENVRC é mais simples e recomendado na maioria dos casos.
As imagens base padrão podem ter configurações de localidade incorretas. Configure a localidade e o fuso horário para evitar avisos de ferramentas de build, Java, Python e Git.
Builds em Java, Gradle e Node.js frequentemente esbarram no limite padrão de 1024 arquivos abertos. Aumente esse limite para evitar falhas de build.
Em ambientes sem conexão com a internet ou restritos, substitua as fontes APT padrão do Ubuntu por um espelho interno.
  • APT_MIRROR_URL — URL do seu espelho APT interno (por exemplo, https://artifactory.example.com/artifactory/ubuntu-remote)
Padrões comuns de URL de espelhos APT:
  • Artifactory: https://artifactory.example.com/artifactory/ubuntu-remote
  • Nexus: https://nexus.example.com/repository/ubuntu-proxy

Padrões avançados

O ambiente base do Devin inclui direnv. Use initialize para criar arquivos .envrc. O direnv os carrega automaticamente.
O direnv já vem integrado ao shell do Devin, então as variáveis de .envrc são carregadas automaticamente. Não é preciso executar source manualmente.
Para variáveis de ambiente sensíveis (chaves de API, tokens, senhas de banco de dados), use segredos do repositório em vez de arquivos .envrc, e vincule-os explicitamente aos comandos de sessão que precisam deles. Expandir um segredo em um arquivo durante um build ainda pode colocá-lo no snapshot.
Use o nvm (pré-instalado) para alternar entre versões do Node.js em cada repositório via .nvmrc.
nvm use lê o .nvmrc na raiz do repositório. Certifique-se de que seu repositório tenha esse arquivo (por exemplo, com 20).
O Devin fornece um navegador Chrome com um endpoint CDP em localhost:29229 durante as sessões. Use scripts do Playwright para automatizar o login no navegador.
O navegador só está disponível durante as sessões, não em builds do snapshot. Instale o Playwright em initialize e mantenha os scripts de login no seu repositório.
Exemplo de script de login (scripts/login.py):
Armazene as credenciais de login como segredos, não no código-fonte. Para autenticação de longo prazo, faça commit dos scripts de login em .agents/skills/ para que o Devin possa se reautenticar automaticamente.
Instale pacotes do sistema, binários personalizados e configure o PATH em initialize.
Devin oferece suporte à execução de GitHub Actions diretamente na seção initialize de um blueprint. Isso é útil para instalar versões específicas de ferramentas usando as mesmas actions usadas pela sua CI.
Ações como setup-node e setup-python alteram o PATH e as variáveis de ambiente. Os binários instalados por uma ação ficam disponíveis em todas as etapas seguintes e em maintenance. GitHub Actions baseadas em Node.js e compostas são compatíveis; ações Docker são compatíveis apenas em builds Linux. Etapas uses não podem ser executadas em maintenance. Veja limitações do GitHub Actions.
Você não precisa de GitHub Actions para a configuração básica de ferramentas. Comandos shell diretos (nvm install 20, curl ... | sh, apt-get install) funcionam tão bem quanto e geralmente são mais simples. GitHub Actions são mais úteis quando você quer replicar exatamente sua configuração de CI ou precisa da praticidade de ações como setup-java, que lidam com várias distribuições.
Execute vários serviços por trás de nomes de host com aparência real em HTTPS, como app.example.com, api.example.com e admin.example.com. Instale um único proxy reverso em initialize e roteie cada nome de host para uma porta upstream local diferente.Caddy gerencia o roteamento e o TLS local em uma única ferramenta. Um Caddyfile mapeia cada nome de host para um upstream, e tls internal emite automaticamente um certificado confiável por nome de host a partir da CA integrada do Caddy. caddy trust instala essa raiz da CA no repositório de confiança do sistema, e adicionar a mesma raiz ao banco de dados NSS permite que o navegador a aceite.Importe seu Caddyfile pela seção File attachments do editor de blueprint; ele então fica disponível como $FILE_CADDYFILE.
Caddyfile
O loop do /etc/hosts é o que faz app.example.com resolver para 127.0.0.1 dentro da sessão. Adicione uma entrada para cada hostname que você colocar no Caddyfile.
Para adicionar um serviço, acrescente um bloco de três linhas ao Caddyfile e uma entrada ao loop do /etc/hosts, depois acesse o hostname por HTTPS. O Caddy emite um certificado na primeira requisição, então não é necessária a geração de certificado por app.

Exemplos full-stack

Estes exemplos mostram como as configurações do Enterprise e no nível da organização se combinam. Na prática, você as dividiria entre diferentes escopos. Elas são apresentadas juntas aqui como referência.
Um ambiente Enterprise completo: certificado de CA corporativo, proxy, Java (Maven), Python (pip/uv), Node.js (npm) e Docker, todos apontando para uma única instância do Artifactory.
Rede & confiança (nível da conta):
  • CORP_ROOT_CA_B64 — certificado de CA corporativa codificado em Base64
  • CORP_HTTP_PROXY — URL do proxy HTTP
  • CORP_HTTPS_PROXY — URL do proxy HTTPS
  • CORP_NO_PROXY — hosts que devem ignorar o proxy
Credenciais do registro (nível da organização):
  • ARTIFACTORY_USER — nome de usuário do Artifactory
  • ARTIFACTORY_TOKEN — token de API ou senha do Artifactory
  • ARTIFACTORY_MAVEN_URL — URL do repositório Maven (por exemplo, https://artifactory.example.com/artifactory/maven-virtual)
  • ARTIFACTORY_PYPI_URL — URL do repositório PyPI (por exemplo, https://user:token@artifactory.example.com/artifactory/api/pypi/pypi-virtual/simple)
  • ARTIFACTORY_NPM_URL — URL do repositório npm (por exemplo, https://artifactory.example.com/artifactory/api/npm/npm-virtual)
  • ARTIFACTORY_DOCKER_URL — URL do registro do Docker (por exemplo, artifactory.example.com)
Isso normalmente seria dividido em três escopos:
  • Nível da conta (initialize): Certificado e proxy
  • Nível da organização (initialize): Instalação de runtimes de linguagem
  • Nível da organização (maintenance): Configuração do registro contendo referências literais
  • Comandos de sessão: Forneça os segredos explicitamente, carregue a configuração do ambiente e faça login para operações individuais do Docker
Exibido aqui de forma combinada para referência:
Neste exemplo, todos os registros apontam para a mesma instância do Artifactory, mas usam caminhos de URL diferentes. Cada ecossistema de pacotes tem seu próprio formato de endpoint. As URLs de Maven, PyPI, npm e Docker são diferentes entre si, mesmo no mesmo registro.
Quando diferentes linguagens usam registros privados diferentes (por exemplo, Maven no Nexus, npm no GitHub Packages, Python no Artifactory).
  • NEXUS_MAVEN_URL — URL do repositório Maven no Nexus
  • NEXUS_USER — nome de usuário do Nexus
  • NEXUS_PASS — senha do Nexus
  • GITHUB_PACKAGES_TOKEN — token de acesso pessoal do GitHub com escopo read:packages
  • ARTIFACTORY_USER — nome de usuário do Artifactory
  • ARTIFACTORY_TOKEN — token de API do Artifactory
Conecte seu Git provider e conceda acesso aos repositórios que hospedam os módulos Go por meio das integrações com o Git.
Em um ambiente totalmente isolado, o Devin não consegue acessar URLs públicas. Todas as ferramentas, runtimes e pacotes devem vir de mirrors internos.
Certificados:
  • CORP_ROOT_CA_B64 — certificado de CA corporativa codificado em Base64
Acesso ao mirror:
  • APT_MIRROR_URL — URL do mirror APT interno do Ubuntu
  • MIRROR_USER — nome de usuário para autenticação no mirror
  • MIRROR_PASS — senha para autenticação no mirror
  • JDK_TARBALL_URL — URL para baixar o tarball do JDK do mirror interno
  • NODE_TARBALL_URL — URL para baixar o tarball do Node.js do mirror interno
Registros de pacotes:
  • INTERNAL_MAVEN_URL — URL do registro Maven interno
  • INTERNAL_NPM_URL — URL do registro npm interno
  • INTERNAL_PYPI_URL — URL do registro PyPI interno
Em ambientes isolados da internet, todas as ferramentas de que o Devin precisa (runtimes de linguagem, ferramentas de CLI etc.) devem estar disponíveis nos seus mirrors internos. Registros públicos e sites de download não podem ser acessados.
Uma configuração Enterprise completa que combina ferramentas de VPN, certificados, configuração de proxy e suporte a múltiplos idiomas. O blueprint instala as ferramentas e armazena a configuração com referências literais. Conecte a VPN explicitamente ao executar operações que exijam acesso interno.
VPN:
  • VPN_CONFIG_B64 — arquivo de configuração do OpenVPN codificado em Base64
Rede & confiança:
  • CORP_ROOT_CA_B64 — certificado de CA corporativa codificado em Base64
  • CORP_HTTP_PROXY — URL do proxy HTTP
  • CORP_HTTPS_PROXY — URL do proxy HTTPS
  • CORP_NO_PROXY — hosts que devem ignorar o proxy
Credenciais do registro:
  • MAVEN_REGISTRY_URL — URL do registro do Maven
  • NPM_REGISTRY_URL — URL do registro do npm
  • PYPI_REGISTRY_HOST — hostname do registro do PyPI
  • REGISTRY_USER — nome de usuário do registro (para Maven e pip)
  • REGISTRY_PASS — senha do registro (para Maven e pip)
  • REGISTRY_TOKEN — token de autenticação do npm
É necessário ter acesso de bootstrap. O cliente OpenVPN deve estar pré-instalado ou ser instalável antes de conectar o túnel. VPN_CONFIG_B64 deve conter certificados/chaves inline, usar dev tun0 e conectar sem autenticação interativa. Os downloads de runtime são executados dentro de um único ciclo de vida do túnel e carregam explicitamente o ambiente de proxy. Repita o bloco de configuração/limpeza da VPN descrito em Rede e conectividade para as operações de sessão; o blueprint não reconecta a VPN no início da sessão.

Dicas para escrever bons blueprints

  • Teste os comandos primeiro em uma sessão. Execute os comandos manualmente em uma sessão do Devin antes de adicioná-los ao blueprint. Isso é mais rápido do que esperar um ciclo completo de build.
  • Use initialize para ferramentas instaladas uma única vez e maintenance para dependências. Tudo o que leva minutos para instalar (compiladores, binários grandes, ferramentas globais) deve ficar em initialize. Comandos rápidos de dependência (npm install, uv sync) entram em maintenance.
  • Mantenha os comandos de maintenance rápidos. Procure ficar abaixo de 2 minutos. Eles são executados durante os builds e apresentados ao agente no início da sessão.
  • Use $ENVRC para variáveis de ambiente que não sejam segredos. Não escreva credenciais nem tokens derivados em $ENVRC, .bashrc ou .profile. Carregue explicitamente a configuração de shell dependente de segredos no comando que precisa dela.
  • Dê nomes às suas etapas. A forma expandida com campos name facilita muito identificar falhas nos logs de build.
  • Use subshells para monorepos. (cd packages/foo && npm install) é executado em um subshell, então as etapas seguintes não são afetadas pela mudança de diretório.
  • Use npm install, não npm ci. npm ci apaga node_modules e reinstala tudo do zero em cada sessão, o que é lento para maintenance.
  • Use secrets do repositório para valores sensíveis. Configure-os na aba Secrets do editor de blueprint do repositório, em vez de embuti-los nos blueprints.
Para detalhes de sintaxe, consulte a Referência de blueprints. Para solucionar problemas de falhas de build, consulte Configuração declarativa > Solução de problemas.