We haven't worked out the details around subscription for multihost, however you still can just go ahead as you mentioned. Anyways you can migrate apps from one Cloudron to another, mostly this works well as long as the usernames are consistent (we try to setup most apps to use the username as the unique identifier)
Yes I think the main reason so far with those commerce platforms is, that they are more like frameworks rather than apps. So they are quite hard to package and more importantly ensure updates work reliably.
Would be nice if someone actively using prestashop could share some experience in that area with us.
A bit of thread necro, but I had the same problem. It appears that NodeBB is correctly configured, BUT in the Cloudron portal, by default, the "custom mailbox name" flag in the advanced app configuration settings is set to off. Thus, the email credentials correctly entered into NodeBB led to an account that, by default, was deactivated in Cloudron's mail server.
For others who stumble here:
From your Cloudron control panel, click the Configure tool (the pencil overlay over the app icon).
In the Advanced tab of the pop-up, ensure that Custom Mailbox Name is checked, and that the name matches the name as configured in NodeBB's email control panel. By default, it's nodebb.app@.
Problem solved, although whether it immediately resolved or whether it fixed when I rebooted Cloudron to install security updates about three seconds later, well .... 🙂
the application's data path can be found at /home/yellowtent/appsdata/<appId>/data/ and that is the only writeable path for apps (besides /tmp and /run of course). This is done for security as well as predictability for updates. Usually if you push data there through external means like SSH, you might have to reconfigure the app through the dashboard, in case the file permissions are not correct. Generally it is preferred that data changes are done via the app itself, which I guess is not quite applicable for your use-case though.
For duplicator, from what I understand this migration script is mostly just creating a tarball/zipfile of the whole previous installation and then extracts it into a folder, which is served up by some LAMP environment. This is incompatible with the Cloudron WordPress package, for reasons mentioned above (mostly the read-only fashion) For this you probably have to fallback to the LAMP app itself. There it should work.