deploy Commands

Description for deploy

This command must be run from within a project.

The command first analyzes your project, your active or logged-into environments, and local defaults to determine what to deploy and where to deploy it. The command then prompts you for information about this particular deployment and provides intelligent choices based on its analysis.

For example, if your local project contains a source directory with metadata files in source format, the command asks if you want to deploy that Salesforce app to an org. The command lists your connected orgs and asks which one you want to deploy to. The list of orgs starts with scratch orgs, ordered by expiration date with the most recently created one first, and then Dev Hub and production orgs ordered by name. If the command finds Apex tests, it asks if you want to run them and at which level.

The command stores your responses in the "deploy-options.json" file in your local project directory and uses them as defaults when you rerun the command. Specify --interactive to force the command to reprompt.

Use this command for quick and simple deploys. For more complicated deployments, use the environment-specific commands, such as "sf deploy metadata", that provide additional flags.

Examples for deploy

Deploy a project and use stored values from a previous command run:

Reprompt for all deployment inputs:

Usage

sf deploy

[--json]

[--interactive]

Flags

--json

Optional

Format output as json.

Type: boolean

--interactive

Optional

Force the CLI to prompt for all deployment inputs.

Type: boolean

Description for deploy functions

You must run this command from within a git repository. Only committed changes to Functions are deployed. The active branch is deployed unless specified otherwise with `--branch`.

Examples for deploy functions

Deploy a Salesforce Function:

Deploy to 'deploy-branch':

Overwrite the remote repository:

Usage

sf deploy functions

[--json]

-o CONNECTED-ORG

[-b BRANCH]

[--force]

[-q]

Flags

--json

Optional

Format output as json.

Type: boolean

-o | --connected-org CONNECTED-ORG

Required

Username or alias for the org that the compute environment should be connected to.

Type: option

-b | --branch BRANCH

Optional

Deploy the latest commit from a branch different from the currently active branch.

Type: option

--force

Optional

Ignore warnings and overwrite remote repository (not allowed in production).

Type: boolean

-q | --quiet

Optional

Limit the amount of output displayed from the deploy process.

Type: boolean

Description for deploy metadata

You must run this command from within a project.

If your org allows source tracking, then this command tracks the changes in your source. Some orgs, such as production org, never allow source tracking. You can also use the "--no-track-source" flag when you create a scratch or sandbox org to disable source tracking.

To deploy multiple metadata components, either set multiple --metadata <name> flags or a single --metadata flag with multiple names separated by spaces. Enclose names that contain spaces in one set of double quotes. The same syntax applies to --manifest and --source-dir.

Examples for deploy metadata

Deploy local changes not in the org:

Deploy the source files in a directory:

Deploy a specific Apex class and the objects whose source is in a directory (both examples are equivalent):

Deploy all Apex classes:

Deploy a specific Apex class:

Deploy all custom objects and Apex classes (both examples are equivalent):

Deploy all Apex classes and a profile that has a space in its name:

Deploy all components listed in a manifest:

Run the tests that aren’t in any managed packages as part of a deployment:

Usage

sf deploy metadata

[--json]

[-a API-VERSION]

[--async]

[--concise]

[--dry-run]

[-c]

[-r]

[-g]

[-x MANIFEST]

[-m METADATA]

[--metadata-dir METADATA-DIR]

[--single-package]

[-d SOURCE-DIR]

[-o TARGET-ORG]

[-t TESTS]

[-l TEST-LEVEL]

[--verbose]

[-w WAIT]

Flags

--json

Optional

Format output as json.

Type: boolean

-a | --api-version API-VERSION

Optional

Target API version for the deploy.

Use this flag to override the default API version, which is the latest version supported the CLI, with the API version of your package.xml file.

Type: option

--async

Optional

Run the command asynchronously.

The command immediately returns the job ID and control of the terminal to you. This way, you can continue to use the CLI. To resume the deployment, run "sf deploy metadata resume". To check the status of the deployment, run "sf deploy metadata report".

Type: boolean

--concise

Optional

Show concise output of the deploy result.

Type: boolean

--dry-run

Optional

Validate deploy and run Apex tests but don’t save to the org.

Type: boolean

-c | --ignore-conflicts

Optional

Ignore conflicts and deploy local files, even if they overwrite changes in the org.

This flag applies only to orgs that allow source tracking. It has no effect on orgs that don't allow it, such as production orgs.

Type: boolean

-r | --ignore-errors

Optional

Ignore any errors and don’t roll back deployment.

When deploying to a production org, keep this flag set to false (default value). When set to true, components without errors are deployed and components with errors are skipped, and could result in an inconsistent production org.

Type: boolean

-g | --ignore-warnings

Optional

Ignore warnings and allow a deployment to complete successfully.

If a warning occurs and this flag is set to true, the success status of the deployment is set to true. When this flag is set to false, success is set to false, and the warning is treated like an error.

Type: boolean

-x | --manifest MANIFEST

Optional

Full file path for manifest (package.xml) of components to deploy.

All child components are included. If you specify this flag, don’t specify --metadata or --source-dir.

Type: option

-m | --metadata METADATA

Optional

Metadata component names to deploy.

Type: option

--metadata-dir METADATA-DIR

Optional

Root of directory or zip file of metadata formatted files to deploy.

Type: option

--single-package

Optional

Indicates that the metadata zip file points to a directory structure for a single package.

Type: boolean

-d | --source-dir SOURCE-DIR

Optional

Path to the local source files to deploy.

The supplied path can be to a single file (in which case the operation is applied to only one file) or to a folder (in which case the operation is applied to all metadata types in the directory and its subdirectories).

If you specify this flag, don’t specify --metadata or --manifest.

Type: option

-o | --target-org TARGET-ORG

Optional

Login username or alias for the target org.

Overrides your default org.

Type: option

-t | --tests TESTS

Optional

Apex tests to run when --test-level is RunSpecifiedTests.

Separate multiple test names with commas, and enclose the entire flag value in double quotes if a test contains a space.

Type: option

-l | --test-level TEST-LEVEL

Optional

Deployment Apex testing level.

Valid values are:

- NoTestRun — No tests are run. This test level applies only to deployments to development environments, such as sandbox, Developer Edition, or trial orgs. This test level is the default for development environments.

- RunSpecifiedTests — Runs only the tests that you specify with the --run-tests flag. Code coverage requirements differ from the default coverage requirements when using this test level. Executed tests must comprise a minimum of 75% code coverage for each class and trigger in the deployment package. This coverage is computed for each class and trigger individually and is different than the overall coverage percentage.

- RunLocalTests — All tests in your org are run, except the ones that originate from installed managed and unlocked packages. This test level is the default for production deployments that include Apex classes or triggers.

- RunAllTestsInOrg — All tests in your org are run, including tests of managed packages.

If you don’t specify a test level, the default behavior depends on the contents of your deployment package. For more information, see [Running Tests in a Deployment](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_deploy_running_tests.htm) in the "Metadata API Developer Guide".

Type: option

Permissible values are: NoTestRun, RunSpecifiedTests, RunLocalTests, RunAllTestsInOrg

Default value: NoTestRun

--verbose

Optional

Show verbose output of the deploy result.

Type: boolean

-w | --wait WAIT

Optional

Number of minutes to wait for command to complete and display results.

If the command continues to run after the wait period, the CLI returns control of the terminal window to you and returns the job ID. To resume the deployment, run "sf deploy metadata resume". To check the status of the deployment, run "sf deploy metadata report".

Type: option

Default value: 33 minutes

Description for deploy metadata cancel

Use this command to cancel a deploy operation that hasn't yet completed in the org. Deploy operations include standard deploys, quick deploys, deploy validations, and deploy cancellations.

Run this command by either passing it a job ID or specifying the --use-most-recent flag to use the job ID of the most recent deploy operation.

Examples for deploy metadata cancel

Cancel a deploy operation using a job ID:

Cancel the most recent deploy operation:

Usage

sf deploy metadata cancel

[--json]

[--async]

[-i JOB-ID]

[-r]

[-w WAIT]

Flags

--json

Optional

Format output as json.

Type: boolean

--async

Optional

Run the command asynchronously.

The command immediately returns the control of the terminal to you. This way, you can continue to use the CLI. To resume watching the cancellation, run "sf deploy metadata resume". To check the status of the cancellation, run "sf deploy metadata report".

Type: boolean

-i | --job-id JOB-ID

Optional

Job ID of the deploy operation you want to cancel.

These commands return a job ID if they time out or you specified the --async flag:

- sf deploy metadata

- sf deploy metadata validate

- sf deploy metadata quick

- sf deploy metadata cancel

The job ID is valid for 10 days from when you started the deploy operation.

Type: option

-r | --use-most-recent

Optional

Use the job ID of the most recent deploy operation.

For performance reasons, this flag uses job IDs for deploy operations that started only in the past 3 days or less. If your most recent deploy operations was more than 3 days ago, this flag won't find a job ID.

Type: boolean

-w | --wait WAIT

Optional

Number of minutes to wait for the command to complete and display results.

If the command continues to run after the wait period, the CLI returns control of the terminal window to you. To resume watching the cancellation, run "sf deploy metadata resume". To check the status of the cancellation, run "sf deploy metadata report".

Type: option

Description for deploy metadata quick

Before you run this command, first create a validated deployment with the "sf deploy metadata validate" command, which returns a job ID. Validated deployments haven't been deployed to the org yet; you deploy them with this command. Either pass the job ID to this command or use the --use-most-recent flag to use the job ID of the most recently validated deployment. For the quick deploy to succeed, the associated validated deployment must also have succeeded.

Executing this quick deploy command takes less time than a standard deploy because it skips running Apex tests. These tests were previously run as part of the validation. Validating first and then running a quick deploy is useful if the deployment to your production org take several hours and you don’t want to risk a failed deploy.

This command doesn't support source-tracking. The source you deploy overwrites the corresponding metadata in your org. This command doesn’t attempt to merge your source with the versions in your org.

Examples for deploy metadata quick

Run a quick deploy to your default org using a job ID:

Asynchronously run a quick deploy of the most recently validated deployment to an org with alias "my-prod-org":

Usage

sf deploy metadata quick

[--json]

[--async]

[--concise]

[-i JOB-ID]

[-o TARGET-ORG]

[-r]

[--verbose]

[-w WAIT]

Flags

--json

Optional

Format output as json.

Type: boolean

--async

Optional

Run the command asynchronously.

The command immediately returns the control of the terminal to you. This way, you can continue to use the CLI. To resume watching the deploy, run "sf deploy metadata resume". To check the status of the deploy, run "sf deploy metadata report".

Type: boolean

--concise

Optional

Show concise output of the deploy result.

Type: boolean

-i | --job-id JOB-ID

Optional

Job ID of the deployment you want to quick deploy.

The job ID is valid for 10 days from when you started the validation.

Type: option

-o | --target-org TARGET-ORG

Optional

Login username or alias for the target org.

Overrides your default org.

Type: option

-r | --use-most-recent

Optional

Use the job ID of the most recently validated deployment.

For performance reasons, this flag uses only job IDs that were validated in the past 3 days or less. If your most recent deployment validation was more than 3 days ago, this flag won't find a job ID.

Type: boolean

--verbose

Optional

Show verbose output of the deploy result.

Type: boolean

-w | --wait WAIT

Optional

Number of minutes to wait for the command to complete and display results.

If the command continues to run after the wait period, the CLI returns control of the terminal window to you. To resume watching the deploy, run "sf deploy metadata resume". To check the status of the deploy, run "sf deploy metadata report".

Type: option

Default value: 33 minutes

Description for deploy metadata report

Deploy operations include standard deploys, quick deploys, deploy validations, and deploy cancellations.

Run this command by either passing it a job ID or specifying the --use-most-recent flag to use the job ID of the most recent deploy operation.

Examples for deploy metadata report

Check the status using a job ID:

Check the status of the most recent deploy operation:

Usage

sf deploy metadata report

[--json]

[-i JOB-ID]

[-r]

Flags

--json

Optional

Format output as json.

Type: boolean

-i | --job-id JOB-ID

Optional

Job ID of the deploy operation you want to check the status of.

These commands return a job ID if they time out or you specified the --async flag:

- sf deploy metadata

- sf deploy metadata validate

- sf deploy metadata quick

- sf deploy metadata cancel

The job ID is valid for 10 days from when you started the deploy operation.

Type: option

-r | --use-most-recent

Optional

Use the job ID of the most recent deploy operation.

For performance reasons, this flag uses job IDs for deploy operations that started only in the past 3 days or less. If your most recent operation was more than 3 days ago, this flag won't find a job ID.

Type: boolean

Description for deploy metadata resume

Use this command to resume watching a deploy operation if the original command times out or you specified the --async flag. Deploy operations include standard deploys, quick deploys, deploy validations, and deploy cancellations. This command doesn't resume the original operation itself, because the operation always continues after you've started it, regardless of whether you're watching it or not.

Run this command by either passing it a job ID or specifying the --use-most-recent flag to use the job ID of the most recent deploy operation.

Examples for deploy metadata resume

Resume watching a deploy operation using a job ID:

Resume watching the most recent deploy operation:

Usage

sf deploy metadata resume

[--json]

[--concise]

[-i JOB-ID]

[-r]

[--verbose]

[-w WAIT]

Flags

--json

Optional

Format output as json.

Type: boolean

--concise

Optional

Show concise output of the deploy operation result.

Type: boolean

-i | --job-id JOB-ID

Optional

Job ID of the deploy operation you want to resume.

These commands return a job ID if they time out or you specified the --async flag:

- sf deploy metadata

- sf deploy metadata validate

- sf deploy metadata quick

- sf deploy metadata cancel

The job ID is valid for 10 days from when you started the deploy operation.

Type: option

-r | --use-most-recent

Optional

Use the job ID of the most recent deploy operation.

For performance reasons, this flag uses job IDs for deploy operations that started only in the past 3 days or less. If your most recent operation was more than 3 days ago, this flag won't find a job ID.

Type: boolean

--verbose

Optional

Show verbose output of the deploy operation result.

Type: boolean

-w | --wait WAIT

Optional

Number of minutes to wait for the command to complete and display results.

If the command continues to run after the wait period, the CLI returns control of the terminal window to you. To resume watching the deploy operation, run this command again. To check the status of the deploy operation, run "sf deploy metadata report".

Type: option

Description for deploy metadata validate

Use this command to verify whether a deployment will succeed without actually deploying the metadata to your org. This command is similar to "sf deploy metadata", except you're required to run Apex tests, and the command returns a job ID rather than executing the deployment. If the validation succeeds, then you pass this job ID to the "sf deploy metadata quick" command to actually deploy the metadata. This quick deploy takes less time because it skips running Apex tests. The job ID is valid for 10 days from when you started the validation. Validating first is useful if the deployment to your production org take several hours and you don’t want to risk a failed deploy.

You must run this command from within a project.

This command doesn't support source-tracking. When you quick deploy with the resulting job ID, the source you deploy overwrites the corresponding metadata in your org.

To validate the deployment of multiple metadata components, either set multiple --metadata <name> flags or a single --metadata flag with multiple names separated by spaces. Enclose names that contain spaces in one set of double quotes. The same syntax applies to --manifest and --source-dir.

Examples for deploy metadata validate

NOTE: These examples focus on validating large deployments. See the help for "sf deploy metadata" for examples of deploying smaller sets of metadata which you can also use to validate.

Validate the deployment of all source files in a directory to the default org:

Asynchronously validate the deployment and run all tests in the org with alias "my-prod-org"; command immediately returns the job ID:

Validate the deployment of all components listed in a manifest:

Usage

sf deploy metadata validate

[--json]

[-a API-VERSION]

[--async]

[--concise]

[-x MANIFEST]

[-m METADATA]

[-d SOURCE-DIR]

[--metadata-dir METADATA-DIR]

[--single-package]

[-o TARGET-ORG]

[-t TESTS]

[-l TEST-LEVEL]

[--verbose]

[-w WAIT]

Flags

--json

Optional

Format output as json.

Type: boolean

-a | --api-version API-VERSION

Optional

Target API version for the validation.

Use this flag to override the default API version, which is the latest version supported the CLI, with the API version in your package.xml file.

Type: option

--async

Optional

Run the command asynchronously.

The command immediately returns the job ID and control of the terminal to you. This way, you can continue to use the CLI. To resume watching the validation, run "sf deploy metadata resume". To check the status of the validation, run "sf deploy metadata report".

Type: boolean

--concise

Optional

Show concise output of the validation result.

Type: boolean

-x | --manifest MANIFEST

Optional

Full file path for manifest (package.xml) of components to validate for deployment.

All child components are included. If you specify this flag, don’t specify --metadata or --source-dir.

Type: option

-m | --metadata METADATA

Optional

Metadata component names to validate for deployment.

Type: option

-d | --source-dir SOURCE-DIR

Optional

Path to the local source files to validate for deployment.

The supplied path can be to a single file (in which case the operation is applied to only one file) or to a folder (in which case the operation is applied to all metadata types in the directory and its subdirectories).

If you specify this flag, don’t specify --metadata or --manifest.

Type: option

--metadata-dir METADATA-DIR

Optional

Root of directory or zip file of metadata formatted files to deploy.

Type: option

--single-package

Optional

Indicates that the metadata zip file points to a directory structure for a single package.

Type: boolean

-o | --target-org TARGET-ORG

Optional

Login username or alias for the target org.

Overrides your default org.

Type: option

-t | --tests TESTS

Optional

Apex tests to run when --test-level is RunSpecifiedTests.

Type: option

-l | --test-level TEST-LEVEL

Optional

Deployment Apex testing level.

Valid values are:

- RunSpecifiedTests — Runs only the tests that you specify with the --run-tests flag. Code coverage requirements differ from the default coverage requirements when using this test level. Executed tests must comprise a minimum of 75% code coverage for each class and trigger in the deployment package. This coverage is computed for each class and trigger individually and is different than the overall coverage percentage.

- RunLocalTests — All tests in your org are run, except the ones that originate from installed managed and unlocked packages. This test level is the default for production deployments that include Apex classes or triggers.

- RunAllTestsInOrg — All tests in your org are run, including tests of managed packages.

If you don’t specify a test level, the default behavior depends on the contents of your deployment package. For more information, see [Running Tests in a Deployment](https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_deploy_running_tests.htm) in the "Metadata API Developer Guide".

Type: option

Permissible values are: RunAllTestsInOrg, RunLocalTests, RunSpecifiedTests

Default value: RunLocalTests

--verbose

Optional

Show verbose output of the validation result.

Type: boolean

-w | --wait WAIT

Optional

Number of minutes to wait for the command to complete and display results.

If the command continues to run after the wait period, the CLI returns control of the terminal window to you and returns the job ID. To resume watching the validation, run "sf deploy metadata resume". To check the status of the validation, run "sf deploy metadata report".

Type: option

Default value: 33 minutes