Source push not allowed in this org. Source tracking is not enabled.
You ran `sf project deploy start` (or `sfdx force:source:push`) against an org that doesn't have source tracking — production, a fully-copied sandbox, or a developer-edition org without the right setting. Source push only works in scratch orgs and (since 2022) sandboxes with source tracking enabled. For non-tracked orgs, use `sf project deploy start` in *target-only* mode or use change sets.
Also seen asSource tracking is not enabled·Source push not allowed·Source tracking not available in this org·sf project deploy start cannot push
The sf CLI distinguishes two deploy modes:
| Mode | Command | What it does |
|---|---|---|
| Source-tracked push | sf project deploy start (in a scratch org or tracked sandbox) | Calculates the diff between local and remote, pushes only the changed files |
| Plain deploy | sf project deploy start --source-dir force-app (anywhere) | Deploys exactly what's in the directory, no diff calculation |
Source tracking is only available where the platform stores per-source-element timestamps:
- Scratch orgs (always)
- Sandboxes with Source Tracking enabled at creation time (Setup → Sandboxes → Edit → Track Source Changes)
- Developer Edition orgs that have explicitly enabled it
Production orgs and most older sandboxes don't have source tracking. If you push there, you get this error.
The fix for production / non-tracked sandboxes
Use the explicit-deploy form, naming the source you want to ship:
sf project deploy start --source-dir force-app/main/default --target-org production
This deploys exactly what's in the directory regardless of tracking. The CLI doesn't compute a diff; it sends everything in the source directory and lets the server decide what changed.
For very large source trees, that's slow. Alternatives:
- Build a smaller package. Use
sf project deploy start --metadata ApexClass:MyClassto deploy a specific component. - Generate a delta package with a Git-aware tool like sfdx-git-delta, which builds a
package.xmlfrom the diff between two commits. - Use change sets — the UI alternative for orgs where CLI is blocked.
Enabling source tracking on a sandbox
For sandboxes (not production), source tracking can be enabled:
- Setup → Dev Hub → make sure Dev Hub is enabled in production.
- Setup → Sandbox → click your sandbox → check Track Source Changes → Save.
- Refresh the sandbox.
After refresh, source tracking is available — but only on new changes from that point. Anything already deployed before tracking was enabled won't show in sf project deploy preview.
Production never gets source tracking
By design. Production deploys are change-controlled events; source tracking would let any developer with the CLI push undocumented changes. Use a CI pipeline that builds a deploy package and runs sf project deploy start --source-dir ... --target-org production against the validated payload.
A common diagnostic confusion
If you've been working in scratch orgs and sf project deploy start always Just Worked, switching to a sandbox or production without specifying --source-dir will surprise you with this error. The explicit form is what experienced teams use everywhere; reserve the bare sf project deploy start for scratch-org-only work.