Development as a Service (DaaS)
Development as a Service (DaaS) is the cloud-delivered tooling model that Salesforce embraces for modern application development.
Definition
Development as a Service (DaaS) is the cloud-delivered tooling model that Salesforce embraces for modern application development. Instead of installing IDEs, version control servers, and build infrastructure locally, you use Salesforce-hosted services and CLIs to spin up scratch orgs, run automated tests, deploy metadata, and manage source through Git. Salesforce DX is the umbrella name for Salesforce's DaaS approach, paired with the Salesforce CLI (sf), the Dev Hub, second-generation packaging, and integrations with VS Code, GitHub Actions, and third-party DevOps platforms.
The term is also used more broadly across the cloud-services industry to describe any model where developers consume infrastructure and tooling rather than owning it. Salesforce's specific DaaS lineage runs through its 2017 release of Salesforce DX and continues with every release that expands the CLI, the scratch-org definition format, and the Dev Hub capacity. For Salesforce developers in 2026, DaaS is the default model: you barely touch local infrastructure outside the editor and the Git client.
What Salesforce's DaaS model includes in practice
Salesforce DX as the core DaaS surface
Salesforce DX (introduced 2017) is the developer experience layer that turns Salesforce into a DaaS platform. Its components: scratch orgs (disposable dev environments), Dev Hub (the org that authorizes scratch org creation), the Salesforce CLI (sf), source-driven development (metadata as files in Git), and second-generation packaging (versioned releases). Each piece is consumed as a service: scratch orgs spin up on Salesforce's infrastructure, the CLI authenticates against your Dev Hub, packages publish to a shared AppExchange listing.
Scratch orgs and disposable environments
Scratch orgs are at the heart of DaaS for Salesforce. You define an org's shape in a JSON file (project-scratch-def.json), and the CLI creates a fresh org on demand. The lifespan defaults to 7 days, max 30. When you delete it, the resources return to your Dev Hub. This is conceptually identical to ephemeral environments in Kubernetes or Heroku review apps: provision per feature, destroy when done.
Dev Hub: the DaaS quota provider
Every Salesforce DaaS workflow requires a Dev Hub: a production org with the Dev Hub feature enabled. The Dev Hub holds your scratch-org allocation (typical: 100 active scratch orgs and 200 daily creations on Enterprise Edition). Without a Dev Hub, the CLI cannot create scratch orgs and DX workflows break. Setting it up is usually a one-time activity: Setup, then Dev Hub, then enable.
The Salesforce CLI as the DaaS client
The Salesforce CLI (sf, formerly sfdx) is the command-line interface that talks to all DaaS services. It manages org authentication, scratch org creation and deletion, metadata deployment and retrieval, package builds and installs, Apex test execution, and data import/export. Every continuous integration pipeline that does anything with Salesforce ends up calling the CLI. Updates ship roughly monthly.
Source-driven development versus metadata-driven
Pre-DaaS Salesforce development was metadata-driven: you connected to a sandbox, changed things in place, then promoted via Change Sets. DaaS introduces source-driven development: your project lives in Git, the CLI deploys to orgs from source, and your sandboxes are effectively snapshots of what is in Git. This is closer to how mainstream software development works and is what makes Salesforce code review, branching, and pull-request workflows tractable.
Continuous integration and DaaS pipelines
With scratch orgs, the CLI, and Git, you can build a pipeline: a pull request triggers GitHub Actions, which creates a scratch org, deploys the branch's metadata, runs the Apex tests, and reports back. This is standard practice on modern Salesforce teams. The same scratch-org pattern supports parallel feature branches, isolated test environments, and reproducible CI runs that do not pollute long-lived sandboxes.
Third-party DaaS platforms on top of Salesforce DX
Copado, Gearset, Flosum, and AutoRABIT layer enterprise DevOps on top of Salesforce DX's DaaS primitives. They add merge management, conflict detection, approval workflows, automated environment promotion, and compliance audit trails. For solo developers and small teams, the CLI and GitHub Actions are enough; for organizations with 50 or more developers and regulatory requirements, the third-party platforms are usually worth the cost.
How to set up a Salesforce DaaS workflow
Setting up Salesforce DaaS means enabling a Dev Hub, installing the Salesforce CLI, structuring a Git repository, and creating your first scratch org. From there, you build on the same primitives.
- Enable Dev Hub in production
Setup, then Dev Hub, then Enable Dev Hub. Confirm the warning (the feature cannot be disabled later) and save. The org is now your scratch-org quota provider.
- Install the Salesforce CLI
Download from developer.salesforce.com/tools/sfdxcli. Verify with sf --version. The CLI installs globally and updates monthly.
- Authenticate the CLI against your Dev Hub
Run sf org login web --alias DevHub --set-default-dev-hub. A browser opens; log in with the Dev Hub admin credentials. The CLI stores the authorization and uses it for every scratch-org operation.
- Create a Salesforce DX project
Run sf project generate --name MyProject. The CLI scaffolds a Git-friendly directory structure with force-app/main/default, sfdx-project.json, and config/project-scratch-def.json.
- Spin up your first scratch org
From the project directory, run sf org create scratch --definition-file config/project-scratch-def.json --alias myorg --duration-days 7. In about 60 seconds you have a fresh org you can deploy to.
- Deploy and test against the scratch org
Run sf project deploy start --target-org myorg to push metadata. Run sf apex test run --target-org myorg --result-format human to execute tests. Both commands work the same way against any org the CLI knows about.
The production org that authorizes scratch-org creation. Required for any DaaS workflow.
The unified command-line tool. Authenticates against orgs, deploys metadata, manages scratch orgs.
Disposable Salesforce orgs, defined by project files. Default 7-day lifespan.
The DaaS packaging model. Versioned, dependency-aware, deployable via the CLI.
- Dev Hub cannot be disabled. Enabling it on a sensitive production org is a one-way door; consider enabling it on a dedicated sandbox parent org if you have one.
- Scratch orgs are NOT sandboxes. They cannot accept Change Sets and they expire automatically. Long-running QA environments still need actual sandboxes.
- CLI authentication tokens expire. Refresh them with sf org login web when you start a new day or move to a new machine.
- DaaS workflows fall apart without Git discipline. Source-driven development assumes the source IS the truth; orgs are projections of the source. Treating sandboxes as the truth is the pre-DaaS pattern.
Trust & references
Straight from the source - Salesforce's reference material on Development as a Service (DaaS).
- Salesforce CLI DownloadSalesforce Developers
- Salesforce DX Developer GuideSalesforce Developers
Hands-on resources to go deeper on Development as a Service (DaaS).
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 does Development as a Service mean in MuleSoft?
Q2. What's the value of the DaaS model?
Q3. Which Anypoint tools support DaaS?
Discussion
Loading discussion…