What is Salesforce CLI Deploy?<\/h2>\n\n\n\n
A Salesforce CLI Deploy takes metadata files from your project and sends them to a target org. The org checks the files, compiles any code and saves the changes. If one item fails, the whole deploy rolls back by default, so the org never ends up half-changed.<\/p>\n\n\n\n
Retrieve does the opposite. It reads metadata from an org and writes it into your project as files.<\/p>\n\n\n\n
Think of your project folder as a shared notebook and the org as a whiteboard in a meeting room. Deploy copies your notes onto the whiteboard. Retrieve copies the whiteboard into your notebook, so you do not lose what someone else wrote.<\/p>\n\n\n\n
Why Salesforce CLI Deploy Matters<\/h2>\n\n\n\n
Change sets work only between connected orgs, and you build them by clicking. The CLI is faster and far more flexible.<\/p>\n\n\n\n
- \n
- Any org.<\/strong> Deploy to scratch orgs, sandboxes, Developer Edition orgs or production.<\/li>\n\n
- Repeatable.<\/strong> The same command gives the same result every time.<\/li>\n\n
- Scriptable.<\/strong> Pipelines can run the exact commands you type.<\/li>\n\n
- Testable.<\/strong> You choose which Apex tests run during the deploy.<\/li>\n\n
- Fast feedback.<\/strong> Errors show up right in your terminal with file names and line numbers.<\/li>\n<\/ul>\n\n\n\n
How Salesforce CLI Deploy and Retrieve Work<\/h2>\n\n\n\n
Every command needs two answers: what to move, and which org to use. You choose “what” with one of three flags. You choose “which org” with
--target-org<\/code>, or the CLI uses your default org.<\/p>\n\n\n\n![\"Salesforce](\"https:\/\/swapnilzambare.com\/blog\/wp-content\/uploads\/2026\/10\/salesforce-cli-deploy-retrieve-metadata-diagram-1-1024x640.png\")
<\/a>Deploy sends files to an org, and retrieve pulls them back.<\/figcaption><\/figure>\n\n\n\n The table below shows the three ways to choose what to move.<\/p>\n\n\n\n
Flag<\/th> What it selects<\/th> Good for<\/th><\/tr><\/thead> –source-dir<\/td> A file or folder in your project<\/td> Quick deploys while building<\/td><\/tr> –metadata<\/td> Named items, like ApexClass:CourseService<\/td> One or two exact items<\/td><\/tr> –manifest<\/td> Everything listed in package.xml<\/td> Planned releases<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Deploy by Folder or File<\/h3>\n\n\n\n
This is the most common option during daily work. You point at a file or a folder, and the CLI deploys everything inside.<\/p>\n\n\n\n
sf project deploy start --source-dir force-app\/main\/default\/classes\/CourseService.cls\nsf project deploy start --source-dir force-app<\/code><\/pre>\n\n\n\nThe first command deploys one Apex class and its meta file. The second command deploys the whole project. Both use your default org.<\/p>\n\n\n\n
Deploy by Metadata Name<\/h3>\n\n\n\n
You can also name the items directly with the type and API name. Separate several items with spaces.<\/p>\n\n\n\n
sf project deploy start --metadata ApexClass:CourseService ApexTrigger:CourseTrigger<\/code><\/pre>\n\n\n\nThis deploys one class and one trigger, as long as their files exist in your project.<\/p>\n\n\n\n
Deploy with a Manifest<\/h3>\n\n\n\n
A manifest is a file named
package.xml<\/code>. It lists every item for a release. Here is one for the Bright Path Tutors course feature.<\/p>\n\n\n\n<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<Package xmlns=\"http:\/\/soap.sforce.com\/2006\/04\/metadata\">\n <types>\n <members>CourseService<\/members>\n <members>CourseWelcome<\/members>\n <name>ApexClass<\/name>\n <\/types>\n <types>\n <members>CourseTrigger<\/members>\n <name>ApexTrigger<\/name>\n <\/types>\n <types>\n <members>Course__c<\/members>\n <name>CustomObject<\/name>\n <\/types>\n <version>65.0<\/version>\n<\/Package><\/code><\/pre>\n\n\n\nEach
types<\/code> block holds one metadata type. Themembers<\/code> tags list the API names, andname<\/code> gives the type. You can let the CLI build this file for you withsf project generate manifest --source-dir force-app<\/code>.<\/p>\n\n\n\nThen deploy it with this command.<\/p>\n\n\n\n
sf project deploy start --manifest manifest\/package.xml --target-org brightpath-uat<\/code><\/pre>\n\n\n\nSalesforce CLI Deploy with Apex Tests<\/h2>\n\n\n\n
Production needs tested code, so every Salesforce CLI Deploy to production runs Apex tests. Salesforce requires at least 75% code coverage across your Apex before a production deploy can pass. You control which tests run with
--test-level<\/code>.<\/p>\n\n\n\nTest level<\/th> What runs<\/th> Typical use<\/th><\/tr><\/thead> NoTestRun<\/td> No tests<\/td> Sandboxes and scratch orgs only<\/td><\/tr> RunSpecifiedTests<\/td> Only the tests you list<\/td> Fast, focused production deploys<\/td><\/tr> RunLocalTests<\/td> All tests except managed package tests<\/td> Most production deploys<\/td><\/tr> RunAllTestsInOrg<\/td> Every test, including packages<\/td> Rare, full checks<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n For example, this deploy runs only the CourseService tests.<\/p>\n\n\n\n
sf project deploy start --source-dir force-app --test-level RunSpecifiedTests --tests CourseServiceTest<\/code><\/pre>\n\n\n\nWith RunSpecifiedTests, each class and trigger you deploy needs at least 75% coverage from the tests you list. So choose your test classes carefully.<\/p>\n\n\n\n
Validate First, Then Quick Deploy<\/h2>\n\n\n\n
Big teams rarely deploy straight to production. Instead, they validate first. A validation runs the full deploy and the tests but saves nothing. If it passes, you can release it later with a quick deploy.<\/p>\n\n\n\n
sf project deploy validate --manifest manifest\/package.xml --test-level RunLocalTests --target-org production\nsf project deploy quick --job-id 0Af5g00000AbCdEFGH --target-org production<\/code><\/pre>\n\n\n\nThe first command checks everything and prints a job ID. The second command uses that ID to release the same changes in seconds, without running the tests again. A successful validation stays ready for a quick deploy for up to 10 days.<\/p>\n\n\n\n
This is perfect for release nights. You validate in the afternoon, and you quick deploy in a short evening window. Users see almost no downtime, and the team avoids last-minute surprises. If the validation fails, you still have hours to fix the problem before the window opens.<\/p>\n\n\n\n
Retrieving Metadata<\/h2>\n\n\n\n
Retrieve uses the same three flags as deploy. Here are the most common examples.<\/p>\n\n\n\n
sf project retrieve start --metadata ApexClass:CourseService\nsf project retrieve start --metadata CustomObject:Course__c\nsf project retrieve start --manifest manifest\/package.xml<\/code><\/pre>\n\n\n\nThe first line pulls one class. Next, line two pulls the Course object with its fields, list views and rules. Finally, line three pulls everything in the manifest. In each case, the CLI writes the files into
force-app<\/code> in source format.<\/p>\n\n\n\nDeleting Metadata with Salesforce CLI Deploy<\/h2>\n\n\n\n
Sometimes a release must remove things, such as an old class nobody uses. Change sets cannot do this. The CLI, however, can delete metadata safely.<\/p>\n\n\n\n
For one or two items, use the delete command. It removes the item from the org and from your local files.<\/p>\n\n\n\n
sf project delete source --metadata ApexClass:OldCourseHelper --target-org brightpath-uat<\/code><\/pre>\n\n\n\nFor planned releases, use a destructive manifest instead. You create a file named
destructiveChanges.xml<\/code> with the same layout as package.xml. Then you add it to a Salesforce CLI Deploy with the--post-destructive-changes<\/code> flag. As a result, the deploy adds the new items first and removes the old ones after.<\/p>\n\n\n\nBe careful with deletes in production. Always validate first, and keep a backup of the files in Git.<\/p>\n\n\n\n
Source Tracking in Scratch Orgs<\/h2>\n\n\n\n
Scratch orgs and Developer sandboxes can track changes for you. Salesforce calls this feature source tracking. The CLI remembers what you deployed and spots what changed in the org since then.<\/p>\n\n\n\n
So in a tracked org, you can run a Salesforce CLI Deploy with no flags at all. The CLI sends only the files you changed. In the same way, a plain
sf project retrieve start<\/code> pulls only what changed in Setup.<\/p>\n\n\n\nBefore you move anything, you can see the list of changes with a preview.<\/p>\n\n\n\n
sf project deploy preview\nsf project retrieve preview<\/code><\/pre>\n\n\n\nEach command prints a table of items that would move, with no changes made. This is a safe habit before every deploy or retrieve in a tracked org.<\/p>\n\n\n\n
Salesforce CLI Deploy vs Change Sets<\/h2>\n\n\n\n
Admins often ask how the CLI compares to change sets. The table below shows the main differences.<\/p>\n\n\n\n
Feature<\/th> Change sets<\/th> Salesforce CLI Deploy<\/th><\/tr><\/thead> Works between<\/td> Connected orgs only<\/td> Any org you can log in to<\/td><\/tr> How you build it<\/td> Clicks in Setup<\/td> Files and commands<\/td><\/tr> Version history<\/td> None<\/td> Full history with Git<\/td><\/tr> Delete metadata<\/td> No<\/td> Yes, with destructive changes<\/td><\/tr> Automation<\/td> No<\/td> Yes, in CI\/CD pipelines<\/td><\/tr> Learning effort<\/td> Low<\/td> Medium<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n - Repeatable.<\/strong> The same command gives the same result every time.<\/li>\n\n
![\"Salesforce](\"https:\/\/swapnilzambare.com\/blog\/wp-content\/uploads\/2026\/10\/salesforce-cli-deploy-retrieve-metadata-diagram-2-1024x640.png\")
<\/a>