Why This Is Useful
You’ve probably been developing in a Developer Edition org or a sandbox. Both work. Both also accumulate junk: half-finished experiments, test data from six months ago, a field somebody added and forgot.
A scratch org is a disposable, source-driven Salesforce environment you spin up in about a minute, use, and throw away.
The key word is source-driven. A scratch org is built entirely from a config file and your repository. Which means everything about it is defined in code you can commit, review and share. If your environment breaks, you delete it and make another one.
That’s a genuinely different way of working, and it’s the foundation of everything modern in Salesforce DevOps.
Scratch Org vs Dev Org vs Sandbox
Developer Edition org – free, permanent, yours. Fine for learning. Accumulates cruft, and its configuration exists only in that org.
Sandbox – a copy of production. Essential for testing against real config and data. Slow to refresh, and you’re usually sharing it.
Scratch org – disposable, defined in a file, expires in up to 30 days. Every developer gets their own. Starts clean every time.
They’re not competitors. A sensible setup uses scratch orgs for feature development and sandboxes for integration testing against production-like config.
Step 1: Enable Dev Hub
Scratch orgs are created by another org, called the Dev Hub. In real life that’s production. For learning, a Developer Edition org works fine.
Setup → Dev Hub → Enable Dev Hub
Fair warning: you cannot turn this off again. It’s harmless, but it’s permanent, so don’t flip it in production without telling anyone.
While you’re there, enable Unlocked Packages and Second-Generation Managed Packages too. You’ll want it later.
Step 2: Authorise It
sf org login web --set-default-dev-hub --alias DevHubOr in VS Code: Ctrl+Shift+P → SFDX: Authorize a Dev Hub.
You only do this once per machine.
Step 3: The Definition File
This is the interesting part. Your scratch org’s shape lives in config/project-scratch-def.json:
{
"orgName": "Coding With The Force",
"edition": "Developer",
"features": ["EnableSetPasswordInApi", "PersonAccounts"],
"settings": {
"lightningExperienceSettings": {
"enableS1DesktopEnabled": true
},
"securitySettings": {
"passwordPolicies": {
"enableSetPasswordInApi": true
}
}
}
}Think about what that file means. Your entire environment configuration is now version controlled. A new developer clones the repo and gets an identical org to yours. No “works on my machine,” because the machine is defined in the repo.features switches on things like Person Accounts or Sites. settings configures org preferences that would otherwise be clicking through Setup.
The full list of available features is in Salesforce’s scratch org definition reference, and it’s worth a browse because there’s a lot in there.
Step 4: Create And Use It
# Create one, 30 day lifespan, set as default
sf org create scratch --definition-file config/project-scratch-def.json
--alias MyScratchOrg --duration-days 30 --set-default
# Push your source into it
sf project deploy start
# Load some sample data
sf data import tree --plan data/sample-data-plan.json
# Open it
sf org open
# When you're done with it
sf org delete scratch --target-org MyScratchOrgThat whole cycle takes a couple of minutes, and the delete at the end is the point. Scratch orgs are meant to be thrown away. Broken something badly? Delete it, make another, push your source. Two minutes and you’re clean.
The data import tree step is worth setting up properly. A committed sample dataset means every developer starts with the same test data, which removes a surprising amount of “it works for me” friction.
Push And Pull, Not Deploy And Retrieve
Scratch orgs have source tracking, which changes how you work.
sf project deploy start # push local changes up
sf project retrieve start # pull org changes down
sf project deploy preview # what's changed on each side?The org remembers what’s changed on both sides, so you never manually maintain a package.xml. Make a field in the UI, run retrieve, and it lands in your project ready to commit.
That last workflow is genuinely lovely and it’s the thing people miss most when they go back to an org-based model.
The Limits, Honestly
They expire. 30 days maximum, 7 by default. Not a bug, but don’t leave anything in one you can’t recreate.
You get an allowance. Based on your Dev Hub edition, both active at once and created per day. Check with sf org list limits. It’s easy to burn through if you’re creating them casually.
No production data. They start empty. You import sample data, which is arguably better for testing but is an adjustment.
Not everything works. Some features and some managed packages don’t install in scratch orgs. Test early if you depend on one.
Setup takes real effort. Getting the definition file and sample data right for a complex org is a project, not an afternoon.
Is It Worth It?
If you’re a solo developer on a small org, honestly, maybe not. A dev org is simpler.
If you’re on a team, absolutely. Every developer gets an isolated environment, your config is reviewable in pull requests, and your CI/CD pipeline can spin up a fresh org, deploy, run tests and tear it down on every commit.
That last one is the real prize. Testing against a clean org every single time means “it passed because of leftover data” stops being a thing that happens to you.
Get Coding With The Force Merch!!
We now have a redbubble store setup so you can buy cool Coding With The Force merchandise! Please check it out! Every purchase goes to supporting the blog and YouTube channel.
Get Shirts Here!
Get Cups, Artwork, Coffee Cups, Bags, Masks and more here!
Check Out More Coding With The Force Stuff!
If you liked this post make sure to follow us on all our social media outlets to stay as up to date as possible with everything!
Youtube
Patreon
Github
Facebook
Twitter
Instagram
Salesforce Development Books I Recommend
Advanced Apex Programming
Salesforce Lightning Platform Enterprise Architecture
Mastering Salesforce DevOps
Good Non-SF Specific Development Books:
Clean Code
Clean Architecture
