With time passes and development moving forward our managed package becomes bigger and bigger. It takes up to 2 hours to deploy it and upload the package with all test executions, analyzes etc.

So I'm wondering, could it potentially grow infinitely or would we hit some governor limits eventually? Are there any restrictions re included number of components, size of the package itself, max time for tests execution or upload to happen, CPU limits for processing etc.

I do understand that in general it's a bad practice to have one huge solid package, better follow 'divide and conquer' strategy with bunch of dependent packages - but just wanna know if our current approach physically fails in nearest future and block us from further development forcing our client to finally agree on splitting)

4 Answers 4


Limits are different now, 30k from API 47. See below:

You can deploy or retrieve up to 10,000 files at once. AppExchange packages use different limits. In API version 43.0 and 44.0, AppExchange packages can contain up to 12,500 files. In API version 45.0, AppExchange packages can contain up to 17,500 files. In API version 46.0, AppExchange packages can contain up to 22,000 files. In API version 47.0 and later, AppExchange packages can contain up to 30,000 files. The maximum size of the deployed or retrieved .zip file is 39 MB. If the files are uncompressed in an unzipped folder, the size limit is 400 MB.

Source: https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_deploy.htm

  • Great addition! Can you add the source, please? Apr 24, 2020 at 9:45
  • @ChristianSzandorKnapp, I've edited the answer.
    – Simon
    Apr 25, 2020 at 6:41

The only hard limit we have hit is the "characters of Apex Code" one where some orgs have a 3 million character limit set. Salesforce support have upped that limit for us when we have asked. SFDX scratch orgs default to a 10 million character limit.

I'm also interested to know if there are hard limits: we haven't hit any others, though our managed packages are probably "medium sized" compared with those of other ISVs.

Suggest you keep an eye on what second-generation packaging has to offer before changing too much right now.

  • Yep, we already doubled "characters of Apex Code" also. But couple times our upload failed with Unexpected Errors and support confirmed that it was just timeout issue, advising us just to re-upload the package later on - so I guess there should be some limit, at least http request timeout.
    – wesaw
    Feb 16, 2018 at 13:42
  • Packaging 2.0 looks great - but as for now scratch orgs do not support Territory Management - it's crucial functionality for us(
    – wesaw
    Feb 16, 2018 at 13:43
  • @wesaw A timeout sounds nasty and probably hard to quantify what particular components/numbers cause it...
    – Keith C
    Feb 16, 2018 at 13:47

We have finally hit the limit - so now I know how huge managed package could be as for now, i.e. checked in practice and confirmed by SF support.

10,000 files - limit for non-certified managed packages, i.e. without passing security review.

12,500 files - for certified managed packages, i.e. for those which have passed security review.

Pay attention, these are hard limits - no way to extend by request. And also - every file contributes to this limit, i.e. tests, translations etc., even those tiny xml files with api version which go in pair with Apex classes and lightning components.

Also got confirmation that 39 MB limits applies to SOAP deployment. But in Winter 19 there is a promising option for sfdx command called 'Rest Deployment' - according to documentation it allows to bypass 39 MB limits.

So now we are hitting the wall with our heads what to do with our huge monolitic managed package, which moves closer and closer to the limit with each commit)


I'm pretty sure that ultimately, you'd be bound by the Metadata Limits, which states there's a limit of 10,000 components and a maximum compressed size of 39 MB. The documentation does not call this out explicitly, but it seems reasonable to presume that they use the same API internally as they do externally. Other than that, there's a few other limits that don't apply to packages directly, but might indirectly. For example, the ten namespace limit conceptually limits how many nested/extension packages one can have before the platform will no longer install new packages (e.g. ten packages which each have an Account trigger would limit further packages from installing with Account triggers). Mind you, this is only speculative, since ISVForce guide doesn't state too much in the way of limits, and I don't think I've ever heard of a package being too large to upload, although larger installs may take increasingly longer to complete.

  • We've finally got 'Limit exceeded' error message when installing beta package on one of our test sandboxes (yep, error is thrown on install, but not when you are uploading the package). According to support response, this is 'work as designed', and there is a limit of 10,000 files for non-certified packages, and 12,500 files for packages which have passed security review. And this is a hard limit - crap) Regarding 39MB - in Winter19 there is an option like 'Rest Deployment' for sfdx deployment command - docs claim that this option allow to bypass 39MB restriciton imposed mainly by SOAP nature.
    – wesaw
    Sep 10, 2018 at 14:12

You must log in to answer this question.

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