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: 
+-----------------------------------------+
|  Enterprise Blueprint                   |
|  Python 3.12, Node 20, security tools   |
+-----------------------------------------+
|  Organization Blueprint                 |
|  private npm registry, team linting     |
+-----------------------------------------+
|  Repository Blueprint                   |
|  npm install, project-specific config   |
+-----------------------------------------+
TierWho manages itScope
EnterpriseEnterprise adminsAll organizations, all repositories
OrganizationOrg adminsAll repositories in the org
RepositoryOrg admins or repo configA single repository
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: 
initialize:
  - name: "Install Python 3.12"
    uses: github.com/actions/setup-python@v5
    with:
      python-version: "3.12"

  - name: "Install Node.js 20"
    uses: github.com/actions/setup-node@v4
    with:
      node-version: "20"

  - name: "Install Go 1.22"
    uses: github.com/actions/setup-go@v5
    with:
      go-version: "1.22"

​
Security tools and compliance scanning

Install scanners and audit tools that every project must use: 
initialize:
  - name: "Install security tools"
    run: |
      npm install -g snyk
      pip install safety bandit
      curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh

​
Internal CLI tools and utilities

Distribute company-specific tools to every environment: 
initialize:
  - name: "Install internal CLI"
    run: |
      curl -L https://internal.example.com/cli/latest/linux-amd64 \
        -o /usr/local/bin/internal-cli
      chmod +x /usr/local/bin/internal-cli

​
Shared package registry configuration

Point package managers at your internal registries: 
initialize:
  - name: "Configure internal registries"
    run: |
      npm config set registry https://npm.internal.example.com/
      pip config set global.index-url https://pypi.internal.example.com/simple/

​
Corporate proxy and certificate setup

Install corporate CA certificates and configure proxy settings: 
initialize:
  - name: "Install corporate certificates"
    run: |
      cp "$FILE_CORPORATE_CA_CERT" /usr/local/share/ca-certificates/corporate-ca.crt
      update-ca-certificates
      echo 'export NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/corporate-ca.crt' >> ~/.bashrc

​
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: 
1. Enterprise blueprint (runs in ~):
   a. initialize
   b. maintenance
2. Organization blueprint (runs in ~):
   a. initialize
   b. maintenance
3. Clone all repositories (up to 10 concurrent)
4. For each configured repo, in the order shown in Settings
   (runs in ~/repos/<repo-name>):
   a. initialize
   b. maintenance
5. post-build (org- and enterprise-level; runs in ~)
6. Health check, then snapshot is saved
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.