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.
Plantillas mínimas para las configuraciones más habituales. Copia uno, pégalo en el editor de plantillas y listo.
Full-stack (Node + Python)
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].
uv (recomendado)
pip + venv
Configuración recomendada para proyectos de Python que usan uv para gestionar dependencias. Configuración tradicional para Python con pip y venv. Úsalo cuando tu proyecto dependa de requirements.txt.
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.
Para proyectos que usan pnpm.
Configuración estándar de Go con módulos.
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.
Configuración de Java con Maven.JDK 17 viene preinstalado en la imagen base de Devin. Omite el paso de instalación de JDK si OpenJDK 17 predeterminado es suficiente.
Configuración de Rails con PostgreSQL.
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.
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.
Monorepo de Java en el que distintos servicios requieren distintas versiones de JDK. Instala ambos JDK durante la configuración y luego usa entradas de knowledge para indicarle a Devin qué JAVA_HOME debe usar para cada servicio.
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.
npm (scoped)
npm (réplica completa)
pnpm
Yarn
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>
Redirige todos los paquetes de npm a través de tu registro privado (no solo los paquetes con ámbito).
NPM_REGISTRY_URL — URL completa de tu registro de npm (p. ej., https://artifactory.example.com/artifactory/api/npm/npm-virtual)
NPM_REGISTRY_HOST — Solo el nombre de host, sin protocolo (p. ej., artifactory.example.com)
REGISTRY_TOKEN — token de autenticación de npm para el registro
Configura pnpm para resolver paquetes desde un registro privado.
NPM_REGISTRY_URL — URL completa de tu registro de npm
NPM_REGISTRY_HOST — Solo el nombre de host, sin protocolo
REGISTRY_TOKEN — token de autenticación de npm para el registro
Configura Yarn (Classic v1 o Berry v2+) para resolver paquetes desde un registro privado.
NPM_REGISTRY_URL — URL completa de tu registro de npm/Yarn
REGISTRY_TOKEN — token de autenticación para el registro
Yarn Classic (v1):Sustituye registry.example.com por el host de tu registro. Yarn Classic lee el archivo .npmrc de npm.Yarn Berry (v2+):
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
Configura Poetry para resolver paquetes desde un registro privado de PyPI.
POETRY_REGISTRY_URL — URL completa de tu registro compatible con PyPI
REGISTRY_USER — nombre de usuario del registro
REGISTRY_PASS — contraseña del registro o token de API
Para la instalación de dependencias, declara también el origen de paquetes private en el pyproject.toml de tu proyecto. poetry config repositories.private configura el repositorio de publicación; las credenciales del entorno se aplican al nombre de origen coincidente.
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>
Instala el JDK y configura Gradle para resolver todas las dependencias a través de tu registro privado.JDK 17 viene preinstalado en la imagen base de Devin. Omite el paso de instalación del JDK si el predeterminado es suficiente.
GRADLE_REGISTRY_URL — URL de tu registro de Gradle/Maven
REGISTRY_USER — Nombre de usuario del registro
REGISTRY_PASS — Contraseña del registro o token de API
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
Renovación del token de AWS CodeArtifact
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).
Certificado de autoridad de certificación corporativa
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. Múltiples certificados de CA
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. Certificado de la CA + proxy (combinados)
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. Resolución de DNS personalizada
Tus servicios internos usan nombres DNS privados que no se pueden resolver mediante DNS público.
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. Identidad de Git y claves SSH
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). Variables de entorno personalizadas
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. Configuración regional y zona horaria
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. Límites de recursos (ulimits)
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. Reemplazo del mirror de APT
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
Variables de entorno con direnv
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. Cambio de versión de Node según el repositorio
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).
Autenticación en el navegador (Playwright)
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.
Herramientas personalizadas del sistema y PATH
Instala paquetes del sistema, binarios personalizados y configura la variable PATH en initialize. GitHub Actions para configurar herramientas
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.
Proxy inverso HTTPS local para múltiples apps
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.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.
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.
Stack empresarial completo (Artifactory)
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.
Varios lenguajes con distintos repositorios
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. Entorno aislado de la red con réplicas privadas
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.
VPN + certificados + proxy + lenguajes
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.