Get Started With Salesforce Scratch Orgs (updated For 2026)

At its core, a scratch org is a temporary Salesforce environment made for a specific development task. As part of the Salesforce DX collection of tools, these are designed for anyone working with the Salesforce CLI and VS Code – whether you’re building something from scratch (pun intended) or testing out a new feature in isolation. You may have thought in the past that scratch orgs are primarily for developers using Salesforce CLI and Visual Studio Code, but they can also be useful for admins and architects who want a clean, low-risk environment to try things out. 

In this post, we’ll attempt to demystify scratch orgs by uncovering the differences between them and sandboxes (and when to use each), org shapes, and limits. If scratch orgs have ever felt too technical or dev-focused, I promise they’re a lot more approachable than they seem! And by the end of this guide, you’ll know exactly when and how to use them – developer or not.

What Is a Scratch Org? 

A scratch org is a “source-driven and disposable deployment of Salesforce code and metadata”, according to Salesforce. In simpler terms, it’s a temporary environment that you can spin up, break apart, and throw away without guilt. 

As the name suggests, scratch orgs are empty by default, allowing you to “start from scratch”, making them perfect for testing new features, building out fresh ideas, or experimenting without worrying about clutter from old configurations. 

At some point, I’m sure we’ve all had a “scratch pad” of some sort; that random piece of paper where you can doodle ideas, map out a plan, or scribble something messy just to see if it works. It’s not meant to be pretty or permanent – it’s a safe space to explore and erase without consequences. 

Scratch orgs work the same way: a blank, low-pressure environment where you can do configurations, test logic, and experiment freely before committing anything to your real build.

I know the definition feels similar to a Sandbox right now, so…

Scratch Orgs vs Sandboxes

Let’s have a quick recap of Salesforce Sandboxes – test environments linked to your production environment. There are four different types:

1. Developer
2. Developer Pro
3. Partial Copy
4. Full 

Unlike sandboxes, scratch orgs do not follow a refresh cycle. You simply create them, use them, and toss them out when you’re done. Because they’re meant to be temporary, there is no need to “refresh” anything. 

The biggest difference between scratch orgs and sandboxes is where they get their metadata. You might know that a sandbox’s metadata is a snapshot that is cloned directly from your production environment. Scratch orgs are a bit more involved. 

To start with, there is a scratch org definition file (by default, it is called project-scratch-def.json). This contains core features and settings you want to enable in your scratch org. For instance, if you want your scratch org to automatically have the Einstein and Agentforce features enabled, you can use the scratch org definition file to enable that without having to turn it on manually. 

As for metadata on features you’ve worked on (customized objects, fields, flows, page layouts, app builder pages, etc.), this needs to be deployed to the scratch org. Normally, this would involve using the Salesforce CLI or another deployment tool that takes metadata from a project and deploys it. 

Another key distinction is edition. Sandboxes will always match the edition of your production org, but scratch orgs can be spun up in a specific edition you choose – all controlled by, again, your configuration file.

When to Use a Scratch Org Over a Sandbox

One great use for scratch orgs is for experimentation and proofs-of-concept early in the development process. Because they can be spun up (and deleted) in minutes, they’re great for experimentation or learning how new features behave isolated from your production environment.

In the world of DevOps, scratch orgs become even more powerful. You can connect them to your source control system and safely validate new changes without worrying about breaking a shared environment or holding up the deployment pipeline. 

Many teams give each developer their own scratch org for exactly this reason – everyone gets their own space to build, test, and prototype without stepping on each other’s toes, while also increasing productivity.

If a development team is building a new stand-alone feature or app for use in their production environment, a scratch org can be very helpful as well. If you imagine IT building an equipment procurement and tracking system, for instance, this likely has zero overlap with their sales or service use case. In such instances, a scratch org with a well-planned packaging strategy may work very well. 

They’re also incredibly helpful for AppExchange partners, who often need to test across different Salesforce editions.

Since scratch orgs can be configured to run on a specific edition, partners and developers can verify that features behave consistently no matter the edition where they’re installed. AppExchange apps also need to be able to run on any org. Similar to the stand-alone app example above, an environment with no customizations fits the ISV use case very well. 

On the other hand, for customers who are further along in the development cycle, a sandbox is often the right call. Sandboxes come with more storage, stable data, and, more importantly, the context of your actual Salesforce org. Because of this, they’re better suited for activities like:

• Integration testing
• User training
• User acceptance testing (UAT)
• Staging and pre-deployment checks

Finally, for a lot of long-standing Salesforce customers who began their org customization journey early on, a sandbox may be your only option (apart from early feature exploration or prototyping). Metadata dependency has no formal structure to use, and without well-planned-out packaging, deep or circular dependencies between metadata and code can make it impractical to unpick such orgs. 

Some customers have had success in pulling out elements for packaging, but such projects need to be weighed against the true business ROI.

Developer Hub 

Every scratch org starts life in a Developer Hub (Dev Hub) org.

You can think of this like the “control center” for all your scratch orgs. It is where you keep track of them, manage your permissions, and serve as the bridge between your Salesforce environments and source control. 

Your Dev Hub can either be a production org or a separate developer org. To make your org a Dev Hub org, just go to Setup → Dev Hub and enable. 

Note that this setting can no longer be changed once enabled. Only orgs on Developer (including Trailhead Playground), Enterprise, Performance, and Unlimited Editions can be Dev Hub orgs. You can’t enable Dev Hub in a sandbox, either.

How to Create a Scratch Org in Salesforce 

When you create a scratch org, you define which edition it runs: Developer, Enterprise, Group, or Professional. The creation process can be broken down into three simple steps:

1. Set up Salesforce Developer Experience (DX) tools. Make sure your CLI and VS Code (or your IDE of choice) are ready to go.
2. Create a scratch org definition file. This is basically a “recipe” that tells Salesforce what features, edition, and settings your scratch org should have.

 
{ 
  "orgName": "Trailbakers", 
  "edition": "Enterprise", 
  "features": [ 
    "EnableSetPasswordInApi",  
    "Einstein1AIPlatform",  
    "Communities",  
    "ServiceCloud",  
    "ChatBot" 
  ], 
  "settings": { 
    "lightningExperienceSettings": { 
      "enableS1DesktopEnabled": true 
    }, 
    "einsteinGptSettings": { 
         "enableEinsteinGptPlatform": true 
    }, 
    "communitiesSettings": { 
         "enableNetworksEnabled": true 
    }, 
    "omniChannelSettings": { 
         "enableOmniChannel": true 
    }, 
    "caseSettings": { 
         "systemUserEmail": "help@trailbakers.com" 
    }, 
    "mobileSettings": { 
      "enableS1EncryptedStoragePref2": false 
    } 
  } 
} 

1. Run the creation command on CLI:

 
sf org create scratch --definition-file  
config/project-scratch-def.json –-alias MyScratchOrg 

• sf org create scratch tells Salesforce CLI you want to create a scratch org.
• --definition-file config/project-scratch-def.json points to the scratch org definition file you created earlier.
• –-alias MyScratchOrg gives the scratch org an alias you can use instead of the auto-generated username.

This all spins up the org, and just like that, your scratch pad is ready for action.

1. Open your org from the command line: sf org open --target-org MyScratchOrg.
   

Org Shapes

If a scratch org definition file is a “recipe” you write by hand, an org shape is a saved “recipe card”. Because it’s copied or captured from an existing Salesforce org, it relieves you of having to manually list features, settings, and limits when doing your scratch org definition file. 

An org shape captures the core configuration of a source org and makes that configuration reusable when creating scratch orgs. You can reference an org shape to start from a known baseline that already reflects how your real org is configured.

An org shape captures key settings such as:

• Features (e.g. Person Accounts)
• Settings (e.g. for Email to Case)
• Edition (e.g. Enterprise)
• Licenses (but not the packages themselves)
• Limits

Like scratch orgs, you’ll run certain commands in Visual Studio Code or Salesforce CLI to manage shapes, such as: sf org create shape –target-org MyShapeSourceOrgAlias.

Scratch Org Snapshots

If org shapes define the structure of a scratch org, scratch org snapshots, on the other hand, capture its state at a specific point in time. It’s similar to reporting snapshots!

A scratch org snapshot is a saved version of a scratch org’s configuration after setup steps have already been applied. For example, after metadata has been pushed, settings enabled, or sample data loaded. 

Instead of rebuilding the same setup every time, you can create new scratch orgs directly from that snapshot. It’s a nice tool that can help you skip repetitive setup work. Keep in mind that snapshots are associated with a Dev Hub org, so you must use the same Dev Hub org when you create the scratch org from the snapshot. 

Snapshots vs. Shapes

While both org shapes and snapshots help you standardize scratch org creation, they serve different purposes:

• Org shapes define what an org’s “shell” is supposed to look like (features, settings, edition, licenses, limits), perfect for spinning up new scratch orgs.
• Snapshots capture what an org has become after configuration and setup.

The former is great for defining a baseline, while the latter is perfect when you need to reuse a ready-to-go environment. And once again, snapshots are managed via VS Code or the Salesforce CLI. For instance, to create a scratch org using the org snapshot, MyOrgSnapshot, you would use the following command: sf org create scratch --snapshot MyOrgSnapshot.

Scratch Org Limits

The limits for scratch orgs are split into two parts based on your Salesforce edition: 

1. Number of scratch orgs that can be created daily.
2. Number of scratch orgs that can be active at one time.

Looking at the limits tripped me up at first, got me thinking: how are we able to have a daily limit of six but only have an Active limit that’s half that number? The answer is because having a higher daily limit than active limit allows iteration, not accumulation.

It’s important to note that a scratch org is considered “active” from the moment it’s successfully created until it’s deleted or expires. It doesn’t matter whether anyone is currently logged into it or using it. If it exists, it counts. So, for example, in a single day, you could do the following:

1. Create Scratch Org A (active count = 1).
2. Test something, delete it.
3. Create Scratch Org B (active count = still 1).
4. Delete it.
5. Repeat.

By the end of the day, you might have created six scratch orgs in total, but never had more than 3 active at once.

These above are the commonly observed allocations, but your specific limits can vary based on your Salesforce contract (especially if you’re an ISV partner or have special allocations, like partner orgs, for example, that can have much higher daily allocations tied to packaging).

Scratch orgs have a maximum lifespan of 30 days. You can select a duration lower than that at the time of creation if preferred, with the default set at seven days. After the scratch org has expired, you can’t restore it.

A scratch org also has much tighter limits than sandboxes, as they can only hold up to 200MB of data (records) and 50MB of files. These limits reinforce the idea of a scratch org being temporary, so you should be intentional about the data you add to it. If you need realistic data volumes, integrations, or longer-lived environments, a sandbox should be the better choice.

As for snapshots, daily limits are the same as the active limit, depending on the edition.

You can view your scratch org and snapshot usage with Salesforce CLI by running the command: sf org list limits --target-org <Dev Hub username or alias>.

Final Thoughts 

If scratch orgs have ever felt “developer-only” or intimidating, I hope this article helped demystify them for you! The key takeaway is that they’re never meant to replace sandboxes, but instead, complement them.

Scratch orgs are Salesforce’s answer to fast, flexible, and source-driven development. Their being lightweight is intentional, because they’re meant to embody a “scratch pad” or temporary environment that can give you a clean slate every time. So if you’re an experimenter or feature builder, these are perfect for validating changes early in the development cycle. 

When paired with other DevOps tools, scratch orgs fit naturally into modern DevOps workflows where speed, isolation, and repeatability matter.

The post Get Started With Salesforce Scratch Orgs (Updated for 2026) appeared first on Salesforce Ben.