The set of SFDX source commands has grown to include (presently beta):

sfdx force:source:deploy

and that seems similar to the mdapi commands:

sfdx force:mdapi:deploy

What is different?

(In particular, it would be great to be able to directly deploy code in SFDX format to a namespace org used for managed package uploading without having to convert to MDAPI format first, but I assume that is still not possible)

2 Answers 2


The two commands are virtually identical, except that you can upload metadata in sfdx format instead of mdapi format. And yes, this includes deploying metadata and code to a namespace org used for managed package uploading (I use sfdx with my primary dev org, which has had a namespace for nearly a decade).

  • OK, so "sfdx force:source:deploy" (when GA) will allow managed package developers to stick to SFDX format (and avoid the MDAPI convert), correct?
    – Keith C
    Nov 7, 2018 at 14:32
  • @KeithC You can use force:source:deploy today, even on your packaging org. Usually, when Salesforce says "beta," they mean "it's a high quality feature with known limitations." I think the only limitation is deploying against production (you should use 2GP to deploy changes to production).
    – sfdcfox
    Nov 7, 2018 at 14:41
  • @sfdcfox correct me if I'm wrong, but I think that force:mdapi:deploy has the advantage of allowing you to do a "verify" deployment (which means that you run unit tests but you don't actually push the code to the org). AFAIK that can't be done with force:source:deploy
    – mkorman
    Feb 19, 2019 at 16:33
  • @mkorman Correct. force:source:deploy is meant to be a tool for development of applications, not pushing stuff to production.
    – sfdcfox
    Feb 19, 2019 at 18:02
  • @sfdcfox understood. However, for me running tests is part of developing apps. To push stuff to production I use a managed package. It's a question of semantics I guess. Thanks!
    – mkorman
    Feb 20, 2019 at 9:23

I’ve been playing with sfdx force:source:deploy today and I can see several things:

  • it’s possible to specify the package.xml manifest file as a parameter, which is a little bit better than when you go through sfdx mdapi (because you need to go through sfdx force:source:convert to convert sfdx source into mdapi format and this outputs whole sfdx project - without possibility to limit scope to certain items).
  • it has certain flaws - e.g. if you specify only one custom field in your manifest file - nevertheless it converts and deploys whole object
  • there is also sfdx force:source:delete which seem to be nice alternative for destructive change set (whatever is not tracked in git source gets deleted from an org)

Testing that further, finally I’m trying to set git-based deployments for sandbox based orgs, seem to be an interesting addition to previously available tools.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .