Here is what MS states for that:
While not strictly required in all add-in scenarios, using an HTTPS endpoint for your add-in is strongly recommended. Add-ins that are not SSL-secured (HTTPS) generate unsecure content warnings and errors during use. If you plan to run your add-in in Office on the web or publish your add-in to AppSource, it must be SSL-secured. If your add-in accesses external data and services, it should be SSL-secured to protect data in transit. Self-signed certificates can be used for development and testing, so long as the certificate is trusted on the local machine.
It is up to you. For all types of add-ins (content, Outlook, and task pane add-ins and add-in commands), you need to deploy your add-in's webpage files to a web server, or web hosting service, such as Microsoft Azure.
For content and task pane add-ins, in the supported Office client applications - Excel, PowerPoint, Project, or Word - you also need either an app catalog on SharePoint to upload the add-in's XML manifest file, or you need to deploy the add-in using Centralized Deployment.
To test and run an Outlook add-in, the user's Outlook email account must reside on Exchange 2013 or later, which is available through Microsoft 365, Exchange Online, or through an on-premises installation. The user or administrator installs manifest files for Outlook add-ins on that server.
When a user acquires an Office Add-in from the store (for Windows Desktop version of Office), a copy of the add-in manifest file is cached locally. The manifests can be found in the following place:
%userprofile%\AppData\Local\Microsoft\Office\16.0\Wef\{some-guid}\{opaque-hash}\Manifests\AppId_{version-number}
So, after installing any add-in from the store you can find a corresponding manifest file locally.