Skip to main content
Blueprints listos para copiar y pegar para lenguajes y casos de uso comunes. Combínalos para armar tu configuración completa. Los ejemplos usan Bash en Linux; sustituye los hosts, ámbitos y comandos de muestra por los tuyos. Para ver el desglose completo de cada campo, consulta la Blueprint reference.
Secretos: configura los secretos con nombre en la pestaña Secrets de cada editor de blueprint. Los pasos de compilación reciben los secretos aplicables del blueprint. Durante una sesión, asegúrate de que cada comando reciba los secretos que necesita: los secretos con ámbito de repo requieren enlaces de entorno explícitos en exec, como env={"REGISTRY_TOKEN": "secret:repo:owner/repo:REGISTRY_TOKEN"}. Consulta Secrets. Nunca incluyas credenciales directamente en tu blueprint.
Los pasos de compilación no son hooks de inicio de sesión. initialize y maintenance se ejecutan durante la creación de instantáneas; maintenance no se ejecuta automáticamente al inicio de la sesión. knowledge aporta instrucciones a Devin, no hooks ejecutables.Mantén las credenciales fuera de los archivos persistentes, incluido $ENVRC. La limpieza de instantáneas elimina los archivos de secretos inyectados por Devin, no los archivos arbitrarios que escriban tus comandos. Usa referencias literales a variables compatibles con la herramienta que las consume, o pasa las credenciales en el entorno del comando. Cuando una herramienta requiera archivos de credenciales, créalos para una sola operación y elimínalos antes de que esta termine. Repite esa configuración de forma explícita cuando lo necesites en una sesión.

Inicio rápido

Plantillas mínimas para las configuraciones más habituales. Copia uno, pégalo en el editor de plantillas y listo.

Plantillas de repositorios

Pasos de compilación para cada repositorio, gestión de dependencias y entradas de Knowledge. Configúralos en Settings > Environment > Blueprints > [tu repo].

Python

Configuración recomendada para proyectos de Python que usan uv para gestionar dependencias.

Node.js

Configuración estándar de Node.js con npm.
Usa npm install (no npm ci) en maintenance. Realiza una actualización incremental, mientras que npm ci elimina node_modules y reinstala todo desde cero cada vez que se ejecuta el comando.

Go

Configuración estándar de Go con módulos.

Java

Configuración de Java con Gradle.
JDK 17 viene preinstalado en la imagen base de Devin. Omite el paso de instalación de JDK si OpenJDK 17 predeterminado es suficiente.

Ruby on Rails

Configuración de Rails con PostgreSQL.

Rust

Configuración estándar de Rust con Cargo.
Rust (mediante rustup) y Cargo vienen preinstalados en la imagen base de Devin. Omite el paso de instalación si la cadena de herramientas estable predeterminada es suficiente. Solo necesitas descargar las dependencias.

Monorepos

Monorepo con un frontend en Node.js y un backend en Python. Cada subproyecto tiene sus propias entradas de Knowledge.
Usa subshells (cd dir && command) en lugar de cd dir && command para que el directorio de trabajo se restablezca entre pasos.

Registros privados de paquetes

Configura los gestores de paquetes para resolver dependencias desde registros privados. Define esto en Settings > Environment > Blueprints > Org-wide setup (o por repositorio, si solo uno lo necesita).
Almacena referencias, no credenciales expandidas. Los delimitadores heredoc entrecomillados como <<'EOF' conservan las referencias a variables dentro del archivo. npm, Yarn Berry, Maven y Gradle pueden resolver las referencias que se muestran a continuación al ejecutarse. pip no expande variables de shell en pip.conf, así que usa variables de entorno en su lugar. Los archivos de configuración del shell deben cargarse explícitamente con source en el mismo comando que la herramienta; no des por hecho que un shell nuevo los carga o actualiza las credenciales.Las URL escritas directamente en configuraciones persistentes, como un índice de Cargo, un mirror de Docker o un mirror de APT, no deben contener credenciales. Mantén la autenticación en los secretos separados que muestra cada plantilla.Si usaste una plantilla antigua que escribía credenciales en disco, elimina esos archivos y vuelve a compilar desde una base limpia, no desde una instantánea que las contenga. Rota las credenciales que puedan haber quedado expuestas.
Si tu registro privado usa una CA corporativa, asegúrate de instalar primero el certificado de CA a nivel de enterprise. La configuración que aparece a continuación asume que la confianza HTTPS ya está establecida.

Registros de Node.js

Configura npm para resolver paquetes con ámbito (p. ej., @myorg/*) desde un registro privado, mientras que los paquetes públicos se siguen obteniendo del registro predeterminado de npm.
  • GITHUB_PACKAGES_TOKEN — Personal Access Token o token de GitHub App con ámbito read:packages
Sustituye @myorg por tu ámbito de npm. URLs habituales 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 de Python

Configura pip y uv para resolver paquetes desde tu registro privado de PyPI (p. ej., Nexus, Artifactory).
  • PYPI_REGISTRY_URL — URL completa de tu índice de PyPI, incluidas las credenciales si son necesarias (p. ej., https://user:token@nexus.example.com/repository/pypi-proxy/simple)
Para precargar las dependencias durante una compilación, agrega el mismo comando source ... && a maintenance después del paso de configuración. Codifica en porcentaje los caracteres especiales de las credenciales en la URL.
Patrones habituales de URL para registros de 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

Registro de JVM

Instala el JDK y configura Maven para redirigir toda la resolución de dependencias a través de tu registro privado (p. ej., Artifactory, Nexus).
JDK 17 está preinstalado en la imagen base de Devin. Omite el paso de instalación si el OpenJDK 17 predeterminado es suficiente. Solo necesitas instalar Maven y configurar el registro.
  • MAVEN_REGISTRY_URL — URL de tu registro de Maven (p. ej., https://artifactory.example.com/artifactory/maven-virtual)
  • REGISTRY_USER — Nombre de usuario del registro
  • REGISTRY_PASS — Contraseña del registro o token de API
Patrones comunes de URL de registros para 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>

Otros registros

Instala Go y configúralo para resolver módulos a través de un proxy de módulos privado (p. ej., Athens, Artifactory o un endpoint GOPROXY).
  • GO_PROXY_URL — URL de tu proxy de módulos de Go (p. ej., https://athens.corp.internal)
Conecta el Git provider y otorga acceso a los repositorios que alojan tus módulos privados mediante las integraciones con Git. Usa URLs de Git HTTPS convencionales con la autenticación configurada en Devin. No incrustes un token en una reescritura de URL de Git.
Para precalentar la caché de módulos durante las compilaciones, agrega ese comando a la sección maintenance del blueprint del repositorio, donde go.mod está disponible. No lo ejecutes en la configuración de la organización, ya que esta se ejecuta antes de clonar los repositorios.
Patrones habituales de URL de proxy de Go:
  • Artifactory: https://artifactory.example.com/artifactory/go-virtual
  • Nexus: https://nexus.example.com/repository/go-proxy
  • Athens: https://athens.corp.internal
Configura NuGet para resolver paquetes desde un feed privado.
  • NUGET_SOURCE_URL — URL de tu feed de NuGet
  • NuGetPackageSourceCredentials_private — Credenciales del feed en el formato de entorno de NuGet: Username=any;Password=<PAT> (usa el nombre de usuario que requiera tu feed)
Configura Docker para descargar imágenes desde un registry de contenedores privado.El inicio de sesión de Docker puede escribir credenciales en su directorio de configuración. Usa un directorio aislado para cada operación y elimínalo incluso si la descarga falla. Vuelve a ejecutar la secuencia de inicio de sesión y descarga cuando necesites otra imagen en una sesión.
  • DOCKER_MIRROR_URL (opcional) — URL de tu mirror de Docker Hub (p. ej., https://mirror.corp.internal)
  • DOCKER_REGISTRY_URL — URL de tu registry de contenedores privado (p. ej., registry.corp.internal:5000)
  • DOCKER_REGISTRY_USER — Nombre de usuario del registry
  • DOCKER_REGISTRY_PASS — Contraseña del registry o token de API
Para almacenar en caché una image en la instantánea, coloca ese mismo subshell completo en un step de compilación. No separes el inicio de sesión y la limpieza en steps distintos, y comprueba que la limpieza finalice correctamente antes de crear la image. La URL de un mirror de registry no debe contener credentials.
URLs habituales 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
Configura Cargo para resolver crates desde un registro privado.
Rust (mediante rustup) y Cargo vienen preinstalados en la imagen base de Devin. Omite el paso de instalación si el toolchain stable predeterminado es suficiente. Solo necesitas la configuración del registro.
  • CARGO_REGISTRY_INDEX — URL del índice del registro privado (p. ej., sparse+https://cargo.corp.internal/api/v1/crates/)
  • CARGO_REGISTRIES_PRIVATE_TOKEN — Token de autenticación para el registro llamado private
La URL del índice del registro no debe contener credenciales. El proveedor cargo:token de Cargo lee el token del registro indicado desde el entorno; no ejecutes cargo login en un paso de compilación.
Si solo necesitas agregar un registro privado sin reemplazar crates.io, elimina las secciones [source.crates-io] y [source.private] y usa cargo install --registry private o [dependencies] my-crate = { version = "1.0", registry = "private" } en Cargo.toml.
Instala Ruby y configura Bundler para resolver gems desde un servidor de gems privado.
  • GEM_SERVER_URL — URL de tu servidor de gems privado (por ejemplo, https://artifactory.example.com/artifactory/api/gems/gems-virtual)
  • BUNDLE_ARTIFACTORY__EXAMPLE__COM — username:password para artifactory.example.com; cambia el nombre de la variable para que coincida con tu servidor de gems
Usa una GEM_SERVER_URL sin credenciales. Para la variable de credenciales de Bundler, antepón BUNDLE_ al nombre de host en mayúsculas, reemplaza cada punto por __ y cada guion por ___.
Patrones habituales de URL de servidores de gems:
  • Artifactory: https://artifactory.example.com/artifactory/api/gems/gems-virtual
  • Nexus: https://nexus.example.com/repository/rubygems-proxy
  • Gemfury: https://gem.fury.io/<org>
Instala PHP y configura Composer para resolver packages desde un registry privado de Packagist o Satis.
  • COMPOSER_REGISTRY_URL — URL de tu registry privado de Composer (por ejemplo, https://repo.packagist.com/<org>)
  • COMPOSER_AUTH — credenciales en JSON para el host del registry, como {"http-basic":{"repo.packagist.com":{"username":"<user>","password":"<token>"}}}
Usa una COMPOSER_REGISTRY_URL sin credenciales.
Patrones habituales de URL de registry de 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
Los tokens de AWS CodeArtifact normalmente caducan a las 12 horas. Crea un script con referencias literales y luego cárgalo explícitamente con source en el mismo comando de shell que npm, pip o Maven para obtener un token. Guardar el script en un blueprint no hace que se ejecute al inicio de la sesión.
awscli viene preinstalado en la imagen base de Devin. Solo necesitas la renovación del token y la configuración del registro.
  • AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY — credenciales de IAM con los permisos codeartifact:GetAuthorizationToken y sts:GetServiceBearerToken
  • CA_DOMAIN — el nombre de tu dominio de CodeArtifact
  • CA_DOMAIN_OWNER — el ID de la cuenta de AWS propietaria del dominio
  • CA_REGION — región de AWS (por ejemplo, us-east-1)
  • CA_NPM_REPO, CA_PYPI_REPO, CA_MAVEN_REPO — nombres de los repositorios de cada ecosistema
Para precalentar una caché de dependencias en la instantánea, agrega el comando source ... && correspondiente como un paso de compilación posterior. El token obtenido permanece en el environment de ese shell; no lo hagas persistente con aws codeartifact login, con npm config set usando un token expandido ni con un pip.conf que contenga credenciales.

Infraestructura de Enterprise

Infraestructura a nivel de máquina que se aplica a todas las organizaciones y repositorios. Configúrala en Settings > entorno base de Devin (a nivel Enterprise) o Settings > Environment > Blueprints > configuración de la organización (a nivel de organización).

Red y conectividad

Tu organización usa una autoridad certificadora privada para los servicios internos. Devin necesita el certificado raíz para conectarse a los repositorios y herramientas internos mediante HTTPS.
  • CORP_ROOT_CA_B64 — Certificado PEM codificado en Base64 de tu CA corporativa. Genéralo con: cat corp-root-ca.crt | base64 -w0
Estas entradas son certificados públicos. openssl x509 escribe únicamente el certificado analizado, por lo que una clave privada incluida accidentalmente no se copia en el almacén de confianza. Proporciona cada certificado de CA por separado, como en el siguiente ejemplo.
Si tu organización usa múltiples certificados de CA (p. ej., CAs separadas para distintos servicios internos).
  • CORP_ROOT_CA_B64 — certificado de CA principal codificado en Base64
  • CORP_INTERMEDIATE_CA_B64 — certificado de CA intermedio codificado en Base64
Dirige todo el tráfico de red a través de un proxy corporativo.
  • CORP_HTTP_PROXY — URL del proxy HTTP (p. ej., http://proxy.corp.example.com:8080)
  • CORP_HTTPS_PROXY — URL del proxy HTTPS
  • CORP_NO_PROXY — Lista de hosts separados por comas para omitir el proxy (p. ej., localhost,127.0.0.1,.corp.example.com)
Si tu proxy corporativo requiere autenticación con nombre de usuario y contraseña.
  • PROXY_USER — Nombre de usuario del proxy
  • PROXY_PASS — Contraseña del proxy
  • PROXY_HOST — Host y puerto del proxy (p. ej., proxy.corp.example.com:8080)
  • CORP_NO_PROXY — Hosts que deben omitir el proxy
Codifica en porcentaje los caracteres especiales del nombre de usuario y la contraseña del proxy. Git y npm pueden usar variables de entorno de proxy; no copies una URL de proxy que contenga credenciales en su configuración persistente.
Configuración combinada para entornos que necesitan tanto una CA corporativa como un proxy. Esto es habitual en entornos empresariales donde los servicios internos usan certificados privados y todo el tráfico debe pasar por un proxy.
  • CORP_ROOT_CA_B64 — Certificado de CA corporativa codificado en Base64
  • CORP_HTTP_PROXY, CORP_HTTPS_PROXY — URL del proxy
  • CORP_NO_PROXY — Hosts que deben omitir el proxy
Solo se puede acceder a tus registros privados, servidores Git u otros servicios internos a través de una VPN. Instala el cliente de VPN en el blueprint. Establece el túnel explícitamente para las operaciones que lo necesiten y, después, desconéctalo y elimina los archivos de credenciales.
OpenVPN:
  • VPN_CONFIG_B64 — Archivo de configuración de OpenVPN codificado en Base64 (.ovpn). Genéralo con: cat corp.ovpn | base64 -w0
  • VPN_AUTH_USER (opcional) — Nombre de usuario de la VPN, si tu VPN requiere autenticación con nombre de usuario y contraseña
  • VPN_AUTH_PASS (opcional) — Contraseña de la VPN
WireGuard:
  • WG_CONFIG_B64 — Archivo de configuración de WireGuard codificado en Base64. Genéralo con: cat wg0.conf | base64 -w0
OpenVPN:
Ejecuta este bloque de forma explícita en una sesión donde los secretos de la VPN estén disponibles. Sustituye el comando curl por el trabajo que necesita el túnel. La configuración debe incluir inline los certificados y las claves requeridos y usar dev tun0; no habilites un servicio de VPN persistente.
WireGuard:
Ejecuta este bloque explícitamente con WG_CONFIG_B64 disponible, sustituyendo el comando curl por tu operación:
Si una compilación de instantánea necesita acceso a la VPN, agrupa todo el trabajo dependiente en el mismo block para que la limpieza termine antes de crear la imagen. Mover las escrituras de credenciales a maintenance no basta para hacerlas temporales. No crees instantáneas de un túnel activo ni de una configuración de VPN privada.
Para más información sobre la configuración de la VPN, consulta VPN configuration.
Tus servicios internos usan nombres DNS privados que no se pueden resolver mediante DNS público.

Identidad y seguridad

Tu organización exige que todos los commits de Git estén firmados y quieres que GitHub marque los commits de Devin como Verified.
  • GPG_PRIVATE_KEY_B64 — clave privada GPG codificada en Base64. Genérala con: gpg --export-secret-keys <key-id> | base64 -w0
  • GPG_SIGNING_KEY — huella digital completa de la clave de firma
  • GIT_USER_NAME — nombre del autor de Git (p. ej., Devin AI)
  • GIT_USER_EMAIL — correo del autor de Git. Debe coincidir con un UID de la clave GPG; de lo contrario, GitHub no verificará la firma.
Sube también la clave pública correspondiente a la cuenta de GitHub cuyas credenciales usa Devin para hacer push (en GitHub Settings > SSH and GPG keys). GitHub solo marca los commits como Verified cuando la clave pública de firma está registrada en la cuenta que creó el commit.
No importes claves privadas de firma durante las compilaciones de instantánea. Después de preparar los cambios previstos, ejecuta explícitamente este bloque en una sesión donde estén disponibles los secretos indicados. Utiliza un llavero temporal y ajustes de Git que solo se aplican a este commit:
Si tu clave requiere una frase de contraseña, completa su flujo aprobado de agente GPG/pinentry durante la operación. No guardes la frase de contraseña ni el llavero en el blueprint ni en la instantánea. Repite la configuración del llavero temporal para commits o etiquetas firmadas posteriores.
Configura la identidad de Git y las claves SSH de Devin para acceder a servidores Git privados.Da preferencia a las integraciones con Git en los proveedores de Git compatibles. Si un servidor requiere una clave SSH explícita, mantén la clave privada fuera de la compilación del blueprint y úsala solo para la operación de sesión que se describe a continuación.
  • GIT_USER_NAME — nombre del autor de Git
  • GIT_USER_EMAIL — correo del autor de Git
  • SSH_PRIVATE_KEY_B64 — clave privada SSH codificada en Base64. Genérala con: cat ~/.ssh/id_ed25519 | base64 -w0
  • SSH_KNOWN_HOSTS_B64 — entradas de known hosts codificadas en Base64 y verificadas con las huellas digitales de claves de host publicadas por el administrador de tu servidor
Ejecuta este bloque explícitamente en la sesión, sustituyendo la URL de Git por la de tu servidor y repositorio:
Si necesitas opciones SSH personalizadas, agrégalas a esta invocación sin copiar una clave privada en una configuración SSH persistente ni en el directorio de inicio. Repite la configuración en cada operación.

Configuración del sistema

Instale paquetes del sistema que no estén en la imagen predeterminada de Devin (p. ej., bibliotecas nativas para el procesamiento de imágenes o la generación de PDF).
Establece variables de entorno persistentes y no secretas que deben estar disponibles en cada sesión. No escribas valores secretos ni credenciales derivadas en $ENVRC.La forma recomendada es escribir líneas KEY=VALUE en el archivo $ENVRC. Las variables escritas en $ENVRC se exportan automáticamente para todos los pasos posteriores y para la sesión de Devin (de forma similar a $GITHUB_ENV de GitHub Actions).
También puedes escribir variables de entorno en scripts de /etc/profile.d/ para que estén disponibles en todo el sistema:
Ambos métodos funcionan. $ENVRC es más sencillo y se recomienda en la mayoría de los casos.
Las imágenes base predeterminadas pueden tener la configuración regional mal configurada. Configure la configuración regional y la zona horaria para evitar advertencias de las herramientas de compilación, Java, Python y Git.
Las compilaciones de Java, Gradle y Node.js suelen alcanzar el límite predeterminado de 1024 archivos abiertos. Auméntelo para evitar fallos de compilación.
En entornos aislados o restringidos, sustituye los repositorios APT predeterminados de Ubuntu por un mirror interno.
  • APT_MIRROR_URL — URL de tu mirror interno de APT (p. ej., https://artifactory.example.com/artifactory/ubuntu-remote)
Patrones comunes de URL para mirrors de APT:
  • Artifactory: https://artifactory.example.com/artifactory/ubuntu-remote
  • Nexus: https://nexus.example.com/repository/ubuntu-proxy

Patrones avanzados

El Environment base de Devin incluye direnv. Usa initialize para crear archivos .envrc. Direnv los carga automáticamente.
direnv ya viene integrado en el shell de Devin, por lo que las variables de .envrc se cargan automáticamente. No necesitas hacer source manualmente.
Para las variables de entorno sensibles (API keys, tokens, contraseñas de bases de datos), usa secretos del repositorio en lugar de archivos .envrc, y vincúlalos explícitamente a los comandos de la sesión que los necesiten. Expandir un secreto en un archivo durante una compilación puede terminar incluyéndolo en la instantánea.
Usa nvm (preinstalado) para cambiar la versión de Node.js de cada repositorio mediante .nvmrc.
nvm use lee el archivo .nvmrc de la raíz del repositorio. Asegúrate de que tu repositorio incluya ese archivo (p. ej., con 20).
Devin proporciona un navegador Chrome con un endpoint de CDP en localhost:29229 durante las sesiones. Usa scripts de Playwright para automatizar el inicio de sesión en el navegador.
El navegador solo está disponible durante las sesiones, no en las compilaciones de instantánea. Instala Playwright en initialize y mantén los scripts de inicio de sesión en tu repositorio.
Script de ejemplo para iniciar sesión (scripts/login.py):
Guarda las credenciales de inicio de sesión como secretos, no en el código fuente. Para mantener la autenticación a largo plazo, confirma los scripts de inicio de sesión en .agents/skills/ para que Devin pueda autenticarse de nuevo automáticamente.
Instala paquetes del sistema, binarios personalizados y configura la variable PATH en initialize.
Devin permite ejecutar GitHub Actions directamente en la sección initialize de un blueprint. Esto es útil para instalar versiones específicas de herramientas mediante las mismas acciones que usa tu CI.
Acciones como setup-node y setup-python modifican PATH y las variables de entorno. Los binarios instalados por una acción están disponibles en todos los pasos posteriores y en maintenance. Se admiten las acciones de Node.js y las compuestas; las acciones de Docker solo se admiten en compilaciones de Linux. Los pasos uses no pueden ejecutarse en maintenance. Consulta las limitaciones de GitHub Actions.
No necesitas GitHub Actions para la configuración básica de herramientas. Los comandos directos de shell (nvm install 20, curl ... | sh, apt-get install) funcionan igual de bien y suelen ser más sencillos. Las GitHub Actions resultan más útiles cuando quieres reproducir exactamente tu configuración de CI o necesitas la comodidad de acciones como setup-java, que gestionan múltiples distribuciones.
Ejecuta varios servicios detrás de hostnames de apariencia real mediante HTTPS, como app.example.com, api.example.com y admin.example.com. Instala un único proxy inverso en initialize y enruta cada hostname a un puerto upstream local distinto.Caddy gestiona el enrutamiento y el TLS local en una sola herramienta. Un Caddyfile asigna cada hostname a un upstream, y tls internal emite automáticamente un certificado de confianza para cada hostname desde la CA integrada de Caddy. caddy trust instala esa raíz de CA en el almacén de confianza del sistema, y agregar la misma raíz a la base de datos NSS permite que el navegador la acepte.Sube tu Caddyfile mediante la sección de Archivos adjuntos del editor de blueprint; después estará disponible como $FILE_CADDYFILE.
Caddyfile
El mapeo de /etc/hosts es lo que hace que app.example.com se resuelva como 127.0.0.1 dentro de la sesión. Agrega una entrada por cada hostname que incluyas en el Caddyfile.
Para agregar un servicio, añade un bloque de tres líneas al Caddyfile y una entrada al mapeo de /etc/hosts, y luego visita su hostname por HTTPS. Caddy emite un certificado en la primera solicitud, así que no hace falta generar certificados por aplicación.

Ejemplos de full stack

Estos ejemplos muestran cómo se combinan las configuraciones de Enterprise y a nivel de org. En la práctica, se dividirían entre distintos ámbitos. Se muestran juntas aquí como referencia.
Un Environment empresarial completo: certificado CA corporativo, proxy, Java (Maven), Python (pip/uv), Node.js (npm) y Docker, todos apuntando a una única instancia de Artifactory.
Red y confianza (para toda la cuenta):
  • CORP_ROOT_CA_B64 — certificado de la CA corporativa codificado en Base64
  • CORP_HTTP_PROXY — URL del proxy HTTP
  • CORP_HTTPS_PROXY — URL del proxy HTTPS
  • CORP_NO_PROXY — hosts que deben omitir el proxy
Credenciales del registro (para toda la organización):
  • ARTIFACTORY_USER — nombre de usuario de Artifactory
  • ARTIFACTORY_TOKEN — token de API o contraseña de Artifactory
  • ARTIFACTORY_MAVEN_URL — URL del repositorio de Maven (p. ej., https://artifactory.example.com/artifactory/maven-virtual)
  • ARTIFACTORY_PYPI_URL — URL del repositorio de PyPI (p. ej., https://user:token@artifactory.example.com/artifactory/api/pypi/pypi-virtual/simple)
  • ARTIFACTORY_NPM_URL — URL del repositorio de npm (p. ej., https://artifactory.example.com/artifactory/api/npm/npm-virtual)
  • ARTIFACTORY_DOCKER_URL — URL del registro de Docker (p. ej., artifactory.example.com)
Esto normalmente se dividiría en tres ámbitos:
  • Para toda la cuenta (initialize): Certificado y proxy
  • En toda la organización (initialize): Instalación de los entornos de ejecución de los lenguajes
  • Para toda la organización (maintenance): Configuración del registry con referencias literales
  • Comandos de sesión: Proporcionar explícitamente los secretos, cargar la configuración del entorno e iniciar sesión para operaciones concretas de Docker
Se muestra aquí de forma combinada como referencia:
En este ejemplo, todos los registries apuntan a la misma instancia de Artifactory, pero usan rutas de URL diferentes. Cada ecosistema de paquetes tiene su propio formato de endpoint. Las URL de Maven, PyPI, npm y Docker son diferentes incluso para el mismo registry.
Cuando distintos lenguajes usan diferentes repositorios privados (p. ej., Maven desde Nexus, npm desde GitHub Packages, Python desde Artifactory).
  • NEXUS_MAVEN_URL — URL del repositorio Maven de Nexus
  • NEXUS_USER — nombre de usuario de Nexus
  • NEXUS_PASS — contraseña de Nexus
  • GITHUB_PACKAGES_TOKEN — token de acceso personal de GitHub con el ámbito read:packages
  • ARTIFACTORY_USER — nombre de usuario de Artifactory
  • ARTIFACTORY_TOKEN — token de API de Artifactory
Conecta tu proveedor de Git y otorga acceso a los repositorios que alojan los módulos de Go mediante las integraciones con Git.
En un entorno completamente aislado de la red, Devin no puede acceder a ninguna URL pública. Todas las herramientas, los entornos de ejecución y los paquetes deben provenir de mirrors internos.
Certificados:
  • CORP_ROOT_CA_B64 — Certificado de CA corporativa codificado en Base64
Acceso al mirror:
  • APT_MIRROR_URL — URL del mirror interno de Ubuntu APT
  • MIRROR_USER — Nombre de usuario para autenticarse en el mirror
  • MIRROR_PASS — Contraseña para autenticarse en el mirror
  • JDK_TARBALL_URL — URL para descargar el archivo tar del JDK desde el mirror interno
  • NODE_TARBALL_URL — URL para descargar el archivo tar de Node.js desde el mirror interno
Registros de paquetes:
  • INTERNAL_MAVEN_URL — URL del registro interno de Maven
  • INTERNAL_NPM_URL — URL del registro interno de npm
  • INTERNAL_PYPI_URL — URL del registro interno de PyPI
En entornos aislados de la red, todas las herramientas que Devin necesita (entornos de ejecución, herramientas de CLI, etc.) deben estar disponibles en tus repositorios espejo internos. No se puede acceder a los repositorios públicos ni a los sitios de descarga.
Una configuración empresarial completa que combina herramientas de VPN, certificados, configuración de proxy y compatibilidad con varios lenguajes. El blueprint instala las herramientas y almacena la configuración con referencias literales. Conecta la VPN de forma explícita cuando ejecutes operaciones que requieran acceso interno.
VPN:
  • VPN_CONFIG_B64 — Archivo de configuración de OpenVPN codificado en Base64
Red y confianza:
  • CORP_ROOT_CA_B64 — Certificado de la CA corporativa codificado en Base64
  • CORP_HTTP_PROXY — URL del proxy HTTP
  • CORP_HTTPS_PROXY — URL del proxy HTTPS
  • CORP_NO_PROXY — Hosts excluidos del proxy
Credenciales del registro:
  • MAVEN_REGISTRY_URL — URL del registro de Maven
  • NPM_REGISTRY_URL — URL del registro de npm
  • PYPI_REGISTRY_HOST — Nombre de host del registro de PyPI
  • REGISTRY_USER — Nombre de usuario del registro (para Maven y pip)
  • REGISTRY_PASS — Contraseña del registro (para Maven y pip)
  • REGISTRY_TOKEN — Token de autenticación de npm
Se requiere acceso de arranque. El cliente de OpenVPN debe estar preinstalado o poder instalarse antes de establecer el túnel. VPN_CONFIG_B64 debe contener certificados/claves inline, usar dev tun0 y conectarse sin autenticación interactiva. Las descargas de los entornos de ejecución se realizan dentro de un mismo ciclo de vida del túnel y cargan explícitamente el entorno del proxy. Repite el bloque de configuración/limpieza de la VPN de Red y conectividad para las operaciones de la sesión; el blueprint no vuelve a conectar la VPN al inicio de la sesión.

Consejos para escribir buenos blueprints

  • Prueba primero los comandos en una sesión. Ejecuta los comandos manualmente en una sesión de Devin antes de agregarlos a tu blueprint. Es más rápido que esperar un ciclo completo de compilación.
  • Usa initialize para herramientas que se instalan una sola vez y maintenance para dependencias. Todo lo que tarde varios minutos en instalarse (compiladores, binarios grandes, herramientas globales) debe ir en initialize. Los comandos rápidos de dependencias (npm install, uv sync) van en maintenance.
  • Haz que los comandos de maintenance sean rápidos. Procura que tarden menos de 2 minutos. Se ejecutan durante las compilaciones y se muestran al agente al inicio de la sesión.
  • Usa $ENVRC para las variables de entorno que no sean secretas. No escribas credenciales ni tokens derivados en $ENVRC, .bashrc ni .profile. Carga explícitamente la configuración de shell que dependa de secretos en el comando que la necesite.
  • Pon nombre a tus pasos. La forma expandida con campos name hace que los fallos en los registros de compilación sean mucho más fáciles de identificar.
  • Usa subshells para monorepos. (cd packages/foo && npm install) se ejecuta en una subshell para que los pasos posteriores no se vean afectados por el cambio de directorio.
  • Usa npm install, no npm ci. npm ci elimina node_modules y reinstala todo desde cero, lo que lo hace lento para maintenance.
  • Usa secretos del repo para los valores sensibles. Configúralos en la pestaña Secrets del editor de blueprint del repositorio, en lugar de incluirlos directamente en los blueprints.
Para conocer los detalles de la sintaxis, consulta la referencia de blueprint. Para solucionar fallos de compilación, consulta Configuración declarativa > Solución de problemas.