Skip to main content
Enterprise environment configuration is for infrastructure that all teams across your organization need: VPN connections, CA certificates, proxy configuration, and DNS overrides. This page covers enterprise-specific concepts. For general environment configuration, see the Environment Configuration guide.

​
What belongs at the enterprise level

Navigate to Enterprise Settings > Environment (or click “Enterprise-wide setup” from any org’s Environment Settings page). The YAML format is identical to org and repo-level configuration — the same initialize, maintenance, and knowledge sections apply.
Use caseEnterpriseOrg-wideRepo-level
VPN / network access✓
CA certificates✓
Proxy configuration✓
DNS overrides✓
GPG commit signing✓
Shared language runtimes✓
Org-wide CLI tools✓
Private registry auth✓
Repo dependencies✓
Repo-specific test/lint✓
Enterprise changes are high-impact. Saving triggers builds for all organizations. Test infrastructure commands in a single org first (using org-wide config) before applying them at the enterprise level.
Enterprise-level configuration cannot clone repositories — repository cloning requires org-level access. Use enterprise config for shared infrastructure only (VPN, certificates, tools). Repo cloning is handled automatically at the org level.
For VPN, CA certificate, proxy, and private registry examples, see Enterprise examples on the Configuration Examples page.

​
Enterprise permissions

ActionRequired role
View/edit enterprise configEnterprise Admin
View/edit org configOrg Admin or Enterprise Admin
View repo configAny org member
Edit repo configMember with ManageOrgSnapshots permission

​
Build cascading

When you change enterprise configuration:
  1. A new build is triggered for every organization
  2. Each org’s build includes: enterprise config → org config → all repo configs
  3. Builds run independently per org — one org’s failure doesn’t affect others
  4. Each org gets its own machine image
Order matters for enterprise initialize steps. VPN must come first (so internal hosts are reachable), then DNS (so names resolve), then certificates (so HTTPS works), then proxy (so traffic routes correctly), and finally any tools that download from internal sources.

​
Multi-organization management

Recommended setup order:
  1. Enterprise config first — set up shared infrastructure (VPN, certs, proxy)
  2. Org-wide config second — each org admin configures shared tools and registry access
  3. Repo-specific config last — teams configure their individual repositories
Each org gets its own machine image. Enterprise config is shared and additive, but org-level and repo-level configs are scoped — Org A’s config doesn’t affect Org B, and build failures in one org don’t affect others. For more on org structure, see Understanding Organizations. The configuration hierarchy (Enterprise → Org → Repo) is strictly additive. Each level’s commands run in sequence after the previous level finishes. Lower levels cannot override or modify what higher levels configure.

​
Enterprise migration

For enterprises migrating from the legacy interactive setup to declarative configuration:
  1. Configure the enterprise-level YAML first — shared infrastructure like VPN, certificates, and proxy settings.
  2. Migrate one org at a time. Each org has its own “Use legacy machine snapshot” toggle, so you can migrate progressively without affecting other teams.
  3. Consider a test org. For large enterprises, create a dedicated test organization to validate the declarative configuration before rolling out to production orgs.
  4. Use Devin for scale. Devin can configure repos via parallel sessions — launch one session per repo and Devin will auto-generate configuration proposals. This works well for onboarding 10–100+ repos.
For the full migration guide (including the step-by-step workflow and testing approach), see Migrating from interactive setup.

​
Next steps