Remie’s answer is correct but it does not explain why we don’t support “just running P2 add-ons in Atlassian Cloud”. The simple answer is that P2 add-ons are too powerful for a Cloud environment. P2 add-ons can:
- Use as much memory as they like.
- Use as much CPU as they like.
- Make database manipulations for JIRA / Confluence.
- Put themselves anywhere in the Product UI that they like (or even just completely swap out the product UI for something totally different).
You can think of it this way: being able to install a P2 add-on on a Cloud instance gives you (an approximation of) root access for that tenant.
This is too much power in a Cloud environment; especially when you consider that, in a Cloud environment, you might be sharing some resources between multiple customers (like CPU and Memory for example). That would allow a misbehaving add-on for one customer to affect not only a single customers experience but multiple customers experience.
In short, Atlassian Connect is a much better sandboxed plugin system that defines much better API’s between the product and the add-on; allowing both to be much safer, more reliable and easier to develop. This comes at the expense of “power”; a Cloud add-on is more restricted, by design, and thus can’t do as much as a server add-on.
I hope that this gives you an understanding of why Atlassian Connect was built and how it continues to be designed. The idea is to give you as much power as possible without compromising on reliability or security for our shared customers.