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 |
+-----------------------------------------+
| Tier | Who manages it | Scope |
|---|
| Enterprise | Enterprise admins | All organizations, all repositories |
| Organization | Org admins | All repositories in the org |
| Repository | Org admins or repo config | A 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.
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"
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
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. Health check, then snapshot is saved
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 on the Enterprise-wide setup page, the same page where you configure the enterprise blueprint. Navigate to Settings > Devin’s base environment to manage both the blueprint and secrets in one place.
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.
Related pages