Skip to main content
Prerequisites: This guide assumes familiarity with declarative environment configuration. See Declarative environment configuration for an introduction.
Before configuring environments, ensure your SCM provider is connected (Enterprise Settings > Integrations) and each organization has been granted access to its repositories (Enterprise Settings > Repository Permissions). Orgs cannot add repos to their environment until access is explicitly granted. See Git Integrations for details.
Enterprise admins can define a base environment that applies to every organization in the enterprise. This gives you centralized control over the tools, runtimes, and security infrastructure that Devin uses, while still letting individual orgs and repos customize their own setup on top.

​
The blueprint hierarchy

Devin’s environment configuration follows a three-tier hierarchy. Each tier builds on the one above it:
The relationship is additive: org and repo blueprints build on top of the enterprise blueprint, they don’t replace it. During every build, the enterprise blueprint runs first, establishing the baseline. Then the org blueprint runs, adding team-specific config. Finally, each repo’s blueprint runs with project-specific setup. See Blueprint scope for how org and repo blueprints relate.

​
Configuring the enterprise blueprint

Navigate to Settings > Devin’s base environment to define the enterprise blueprint. This uses the same format as org and repo blueprints, with initialize, maintenance, and knowledge sections. Enterprise and org blueprints also support a post-build section for commands that run after all repos are cloned and set up. The enterprise blueprint runs first during every build, before org and repo blueprints. This means tools and runtimes installed at the enterprise level are available to all downstream blueprints.

​
What to put in the enterprise blueprint

The enterprise blueprint is for tools and configuration that every organization needs. Common use cases:

​
Standard language runtimes

Pin language versions across the enterprise so every team works with the same toolchain:

​
Security tools and compliance scanning

Install scanners and audit tools that every project must use:

​
Internal CLI tools and utilities

Distribute company-specific tools to every environment:

​
Shared package registry configuration

Point package managers at your internal registries:

​
Corporate proxy and certificate setup

Install corporate CA certificates and configure proxy settings:

​
How tiers interact

During a build, each tier’s steps run in a fixed sequence. The output of earlier tiers is available to later ones. Tools installed at the enterprise level are ready to use in org and repo blueprints without reinstallation. A build creates a new snapshot in this order:
post-build steps run after every repo has been cloned and set up, so they can validate the fully assembled environment. A non-zero exit code from a post-build step fails the build and no snapshot is produced. See post-build in the blueprint reference. Tiers are additive: repo blueprints can use tools installed by the org or enterprise blueprint. Lower tiers cannot override what a higher tier set up. Builds typically take 5–15 minutes. Individual commands time out after 1 hour. knowledge items from all tiers are collected and made available to Devin. If multiple tiers define a knowledge item with the same name, all of them are included. They don’t overwrite each other.

​
Enterprise secrets

Enterprise admins can define secrets at the enterprise level. These secrets are available as environment variables during every build and every session across all organizations, in enterprise, org, and repo blueprint steps alike. Use enterprise secrets for credentials that are shared across the entire company:
  • Internal package registry tokens
  • Corporate proxy authentication
  • Shared API keys for internal services
  • License keys for enterprise tools
Enterprise secrets are managed in the Secrets tab within the enterprise blueprint editor. Navigate to Settings > Devin’s base environment and switch to the Secrets tab to manage enterprise-wide secrets alongside your blueprint configuration.
Managing enterprise secrets requires the ManageAccountResources permission.
If an org secret has the same name as an enterprise secret, the org secret takes precedence. This lets individual organizations override enterprise-wide defaults when needed.

​
Enterprise-wide rebuilds

Enterprise admins can trigger a rebuild that cascades to all organizations. This is useful when:
  • You update the enterprise blueprint (e.g., upgrade Python from 3.11 to 3.12)
  • You rotate an enterprise secret
  • You need to refresh all environments after a security patch
Trigger an enterprise-wide rebuild from Settings > Devin’s base environment. Each organization’s build runs with the updated enterprise blueprint, followed by its own org and repo blueprints.
Enterprise-wide rebuilds respect each org’s build queue. If an org already has a build in progress, the enterprise-triggered rebuild queues behind it. If a build is already queued, it gets cancelled and replaced by the enterprise-triggered one.

​
Managing rollout across organizations

The enterprise admin controls which organizations use declarative configuration versus classic environment setup. The Rollout page provides visibility into adoption status across all orgs and lets you progressively migrate organizations. See Migrating your enterprise for a detailed walkthrough of the rollout states, per-org overrides, and a phased migration playbook.