Enabling Dev Hub is a one-click toggle in Setup. The real work is choosing the right org to designate, authenticating the Salesforce CLI to it, and building the monitoring around scratch org usage. Plan once and the setup serves the whole team for years.
- Choose the org to designate as Dev Hub
Most teams: use production. Solo developers: use a free Developer Edition org. Avoid sandboxes because refresh wipes Dev Hub enablement. The choice persists, so plan deliberately.
- Enable Dev Hub in Setup
Setup > Dev Hub > Enable Dev Hub. The toggle is irreversible (you cannot disable Dev Hub once enabled). Read the warning carefully before flipping. Enable Unlocked Packages and Second-Generation Managed Packages if your team plans to use 2GP.
- Create a service-account user for CI authentication
Setup > Users > New User. Create a dedicated user with permissions to create scratch orgs. This user becomes the CI authentication identity. Avoid using a human user''s credentials for CI because employee departures break the pipeline.
- Authenticate the Salesforce CLI to the Dev Hub
sf org login web --set-default-dev-hub. A browser opens for OAuth login. The CLI remembers the Dev Hub for future commands.
- Configure JWT Bearer auth for CI/CD pipelines
Generate a certificate, upload the public key to a Connected App, and configure the CI pipeline to authenticate via JWT Bearer using the certificate''s private key. This avoids storing user credentials in CI.
- Create a test scratch org to validate setup
sf org create scratch --definition-file config/project-scratch-def.json --alias test-org. If the org provisions successfully, the Dev Hub setup is working. Tear down with sf org delete scratch.
- Build the monitoring dashboard
Create a Salesforce report on ScratchOrgInfo grouped by CreatedBy.Name, with active scratch org counts and expiration dates. Add it to an internal dashboard for team visibility into usage.
- Document the Dev Hub workflow
Write a one-page guide for the team: which org is the Dev Hub, how to authenticate the CLI, what the active and daily allocations are, where to find ScratchOrgInfo monitoring. The doc onboards new developers without verbal handoff.
Production for established teams. Developer Edition for solo work. Avoid sandboxes because refresh wipes the enablement.
Scales with edition. Track usage via ScratchOrgInfo. Request elevated limits for high-volume CI/CD.
JWT Bearer flow with a Connected App and certificate. The standard pattern for headless CI pipeline authentication to the Dev Hub.
- Dev Hub enablement is irreversible. Once enabled, you cannot disable it. Read the Setup warning carefully and confirm the right org before flipping the switch.
- Sandbox refresh wipes Dev Hub enablement. Designate production or a Developer Edition org as Dev Hub, never a sandbox.
- Daily and active scratch org limits cap usage. Hit them and new org creation fails until existing orgs are deleted or expire. Plan allocation for the team.
- Orphaned scratch orgs (created and forgotten) consume the active allocation until expiration. Monitor ScratchOrgInfo and clean up orphaned orgs periodically.
- CI pipelines that authenticate via username-password break when MFA enforcement reaches the integration user. Use JWT Bearer flow from the start.