Dev Hub
A Dev Hub is a Salesforce org that has been authorized to create and manage scratch orgs.
Definition
A Dev Hub is a Salesforce org that has been authorized to create and manage scratch orgs. It is the parent that provisions ephemeral development environments on behalf of the Salesforce CLI, tracks their lifecycle, and enforces usage limits. Every project that uses scratch orgs needs exactly one designated Dev Hub for the team or org; most established teams designate the production org as the Dev Hub because it already has the right edition and licensing.
Enabling Dev Hub is a one-click toggle in Setup. Once enabled, the org can authorize the Salesforce CLI to create scratch orgs against it, each with its own allocation against the Dev Hub's daily and active limits. The limits scale with edition: a Developer Edition Dev Hub allows three active scratch orgs at any time; paid plans allow many more. Dev Hub also exposes ScratchOrgInfo records in the data layer for monitoring and reporting on the active scratch org population, which is useful for tracking team usage against the entitlement.
How Dev Hub enables modern Salesforce DX workflows
Why one org has to be the Dev Hub
Scratch orgs are billed against an entitlement; that entitlement lives on a Dev Hub. Without a Dev Hub, the Salesforce CLI has no source of authority to provision scratch orgs against. The Dev Hub also tracks the active scratch org population, enforces daily creation limits, and provides the SOQL-queryable ScratchOrgInfo records that admins use for monitoring. The architecture forces a single designated source of truth per org or team, which is usually a good thing operationally.
Which org to designate
Most established teams designate production as the Dev Hub. Production has the right edition, has full licensing, and naturally aligns with team membership. For solo developers or trial projects, a free Developer Edition org can serve as Dev Hub, with the lower limits of three active scratch orgs at a time. Avoid designating a long-lived sandbox as Dev Hub because sandbox refresh wipes the Dev Hub enablement and breaks the team''s ability to create scratch orgs.
Allocation: daily and active scratch org limits
Each Dev Hub edition has a daily allotment (number of scratch orgs that can be created per day) and an active allotment (number of scratch orgs that can exist at the same time). Developer Edition: 3 active and 6 daily. Enterprise Edition: 25 active and 50 daily. Unlimited Edition: 100 active and 200 daily. ISV Partners can request elevated limits. When the allocation is hit, new scratch org creation fails until existing orgs are deleted or expire. Track usage via SOQL on ScratchOrgInfo.
Dev Hub and CI/CD pipelines
Continuous Integration pipelines often create and destroy scratch orgs per pipeline run. The pipeline authenticates to the Dev Hub via a JWT Bearer flow with a Connected App and certificate, then uses the authentication to create scratch orgs. Pipeline-driven scratch orgs typically have very short lifetimes (a few hours), so the daily allocation rather than the active allocation usually constrains throughput. For high-volume CI, request elevated daily limits from Salesforce.
ScratchOrgInfo and monitoring active orgs
Every scratch org creation produces a ScratchOrgInfo record in the Dev Hub. The record stores the creator, expiration date, edition, status, and other metadata. Query ScratchOrgInfo in SOQL to audit active orgs: SELECT Id, ScratchOrg, Status, ExpirationDate, CreatedBy.Name FROM ScratchOrgInfo WHERE Status = ''Active''. Most teams build a simple dashboard against this object to track usage against the allocation and identify orphaned scratch orgs that should be cleaned up.
Dev Hub and Second-Generation Packaging
Dev Hub is also the home for Second-Generation Managed Packages (2GP). The package metadata lives on the Dev Hub, package versions are created from the Dev Hub, and the dependency graph for 2GP packages is tracked in the Dev Hub data layer. ISVs and orgs building unlocked packages need Dev Hub enabled to use the 2GP workflows. This dual role (scratch orgs and 2GP) is why production is often the right Dev Hub: it keeps the package source of truth aligned with the production runtime.
Pitfalls and best practices
Pitfalls: designating a sandbox as Dev Hub then refreshing it (loses enablement); running multiple Dev Hubs across the team (fragments allocation); embedding Dev Hub credentials in source control instead of using JWT for CI. Best practices: one Dev Hub per team, enable on production, authenticate CI via JWT Bearer with a service-account user, monitor ScratchOrgInfo for usage and orphan cleanup, document the Dev Hub authentication path so new team members know how to authenticate.
How to set up and use a Dev Hub
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.
Trust & references
Cross-checked against the following references.
- Dev Hub OverviewSalesforce Developer
- Enable Dev HubSalesforce Developer
- Scratch OrgsSalesforce Developer
Straight from the source - Salesforce's reference material on Dev Hub.
- Enable Dev Hub in ProductionSalesforce Developer
- JWT Bearer Flow for CISalesforce Developer
- Second-Generation PackagingSalesforce Developer
Hands-on resources to go deeper on Dev Hub.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Dev Hub?
Q2. What can serve as a Dev Hub?
Q3. Why is Dev Hub a prerequisite for modern Salesforce DX workflows?
Discussion
Loading discussion…