Enterprise rollout states
The enterprise has three top-level states that control how blueprints are available to organizations:| State | What it means | Effect on organizations |
|---|---|---|
| Disabled | Blueprints are not enabled for the enterprise | No orgs see the environment pages. All orgs use classic setup. |
| Default Off | Blueprints are available but not the default | Orgs can be individually opted in by the enterprise admin. New orgs start on classic setup. |
| Default On | Blueprints are the default for all orgs | All orgs use blueprints unless explicitly overridden to classic setup. New orgs start on blueprints. |
Default Off details
In the Default Off state, organizations that haven’t been opted in continue to use classic setup and see no changes to their experience. The enterprise admin can opt individual orgs in from the Rollout page. Only those orgs switch to declarative configuration. There is an additional toggle: Show migration nudge to all organizations. When enabled, org admins who are still on classic setup see a callout on their Machine Configuration page encouraging them to migrate to declarative configuration. This doesn’t change their setup or give them access to the full environment configuration pages. It simply makes them aware that blueprints are available and provides a path to opt in. This is useful for building awareness before you start migrating orgs. When this toggle is disabled, orgs that haven’t been explicitly opted in see nothing new. Their experience is unchanged.Per-org overrides
Enterprise admins can override the rollout state for individual organizations from the Rollout page:- In Default Off: Opt specific orgs in to blueprints. These orgs switch from classic setup to declarative configuration immediately.
- In Default On: Opt specific orgs out back to classic setup. These orgs continue using their classic configuration.
Automatic classic overrides
When transitioning from Default Off to Default On, a safety mechanism prevents disruption: any org that is currently on classic setup and has repositories configured automatically receives an explicit classic override. This means the transition doesn’t change anything for orgs that are actively using classic setup. They continue as-is until you explicitly migrate them. Orgs without repositories (or orgs already on blueprints) are unaffected by this guard.Recommended migration playbook
The best approach is to build and validate your configuration in isolation before opening it up to org admins. Don’t do a big-bang migration. Start controlled, verify, then expand.Phase 1: Build and verify in isolation (Default Off)
Start with the enterprise in Default Off mode. Orgs cannot opt in on their own, so you have full control.- Enable blueprints at the enterprise level by transitioning from Disabled to Default Off.
- Create a dedicated test org for environment configuration testing. This org exists solely for validating your blueprints.
- Enable declarative configuration for this test org only (via per-org override on the Rollout page).
- Configure your enterprise blueprint: install all shared language runtimes, security tools, corporate certificates, internal CLIs, proxy settings, and registry auth. This is your base layer that every org will inherit.
- Configure an org blueprint for the test org with any org-level tools or registry config.
- Add repository blueprints for a representative set of repositories. Pick repos that cover your most common tech stacks.
- Verify end-to-end: start Devin sessions on these repos and confirm everything works. Repos should be cloned, dependencies installed, lint/test/build commands running correctly, and all tools at expected versions.
Phase 2: Enable opt-in for org admins
Once you’ve confirmed that your enterprise → org → repo blueprint stack composes correctly and produces working environments:- Communicate internally to org admins that declarative configuration is available and ready.
- Enable the migration nudge: toggle “Show migration nudge to all organizations” so org admins on classic setup see a callout encouraging them to migrate.
- Org admins can now migrate their own organizations. Because the enterprise blueprint already provides the base layer (runtimes, tools, certs, registries), org admins only need to configure what’s specific to their team and repos.
Phase 3: Expand and clean up
- Transition to Default On when most orgs are on blueprints. Orgs that were on classic setup with repos get automatic classic overrides, so nothing changes for them.
- New orgs created after this point start on blueprints by default.
- Monitor the Rollout page for build health across all orgs. Filter by “Classic” to see who hasn’t migrated yet.
- Work with remaining org admins to migrate stragglers. The migration assistant makes this straightforward.
- Remove classic overrides once all orgs are verified on blueprints.
Classic configuration is always preserved. Nothing is deleted when an org switches to blueprints. If something goes wrong, enterprise admins can switch any org back to classic setup instantly from the Rollout page.
Rolling back
Things don’t always go smoothly. The rollout system supports rollback at every level.Per-org rollback
Enterprise admins can toggle any individual org back to classic setup from the Rollout page:- The org immediately reverts to using its classic setup snapshot.
- Classic configuration is preserved. Nothing is lost when an org switches to blueprints, so switching back is safe.
- Active sessions are not affected. The change takes effect on the next session.
Enterprise-wide rollback
Enterprise admins can transition from Default On back to Default Off:- Orgs that had explicit blueprint overrides keep them. They stay on blueprints.
- Orgs that were on blueprints by default (no override) revert to classic setup.
- This is a safe operation. No configuration data is lost in either direction.
Rollback doesn’t delete blueprints or classic configurations. Both are preserved regardless of which mode is active, so you can switch back and forth without losing work.
Monitoring rollout health
The Rollout page provides a dashboard for tracking migration progress across your enterprise.KPI row
At the top of the page, summary metrics give you a quick read on rollout status:- Blueprint orgs: Number of organizations currently on blueprints
- Rollout percentage: Percentage of orgs on blueprints out of the total
- Build health: Aggregate build status across blueprint orgs
Per-org table
Below the KPIs, a detailed table shows every organization:| Column | Description |
|---|---|
| Organization | Org name |
| State | Current mode: Blueprints or Classic |
| Override | Whether the org’s state is an explicit override vs. enterprise default |
| Classic repos | Number of repos with classic setup configuration |
| Blueprint repos | Number of repos with blueprints |
| Latest build | Status of the most recent build (Success, Partial, Failed, etc.) |
Filtering
Filter the table by:- All: Every org in the enterprise
- Blueprints: Orgs currently on blueprints
- Classic: Orgs currently on classic setup
- Overrides: Orgs with explicit state overrides (either direction)
Concurrency safety
State transitions are protected against simultaneous changes. If another admin changes the enterprise state between when you loaded the page and when you submit your change, the request is rejected with a conflict error. This prevents accidental overwrites when multiple enterprise admins act at the same time. If your change is rejected, refresh the page to see the current state and resubmit if still appropriate.Audit logging
All rollout state transitions are recorded in audit logs:- Enterprise state changes (Disabled → Default Off, Default Off → Default On, etc.)
- Per-org override changes (org opted in, org opted out, override removed)
- Which admin made the change and when