@Benoit said in Create app "packages" for 'managed' cloudrons:

It could be a manageable app store by the super admin of the cloudron. He could hide the default app store for non technical clients and choose what apps need to be accessible with a customization on the description of these apps. it could be an interface with toggle buttons to activate or deactivate some apps. And you can choose the text you want to show for each app activated. the process to install would be the same. Be careful for me in the back, it is the same app store but it is the front what is different and more compatible with newbies and non tech users.

Certainly, this is another way of seeing and doing things to accomplish this, and it's great ideas as well. That's the reason for such forum and how genius software are created. We have here a crowd of people with amazing backgrounds of all sorts and it's the main reason we've a rich community.

it is a big improvement but it does not seem impossible to do for super @girish ;). Perhaps i don't see all the difficulties it could engage.
Anyway it could be a more comprehensible interface to help the onboarding of new users.

Ah, you're conscious all is possible with @girish right? 😛

@robi I decided to move both, appsdata and boxdata.

Where is this slated release wise?

@girish said in Hiding superadmin to deliver 'managed' cloudron to clients.:

@micmc said in Hiding superadmin to deliver 'managed' cloudron to clients.:

And I guess, that is what would or should happen if we choose to hide the owner. I haven't thought really about this one but yeah, well thought and that should the be case also indeed, the superuser would not be seen in apps as well.

We had this idea of creating a "service account" - https://git.cloudron.io/cloudron/box/-/issues/771 (which is scheduled for 7.3). I think this will get you this feature.

This is how we see how great minds encounter! 😛

Also, there's the discussion about the "email admin" role to which your issue above refers too as well, which several of us have followed as well, which have popped several ideas and views as well and has brought to the creation of such feature.

@briankb-0 NodeBB FTforumW. 👍

@girish Yes there is. .ipfs is not a "normal" TLD. It's for websites which are on IPFS, which is an alternate decentralized protocol. Kinda like .onion domains for serving websites on tor.

However, i don't really know how cloudron could support it, as I believe it does not use standard http/s at all, so regular apps would not work.

@nebulon woohoo! Thank you

I still really want to be able to filter apps by LDAP support 🙂

@fbartels I hear ya, not the main use case, but the subsetting feature with starting a new DB from previous prod data is the killer feature here.

Hi Nebulon! 🙂

@nebulon said in Using Cloudron to setup DNS records in new DNS Provider before switching Nameservers on domain. Vanity Nameservers could also be supported if changes made.:

will not allow for adding essentially multiple DNS provider for the same domain

Just to be clear, I'm not looking to store multiple DNS credentials, if I switch it in Cloudron to Vultr from DigitalOcean, I'd assume or expect Cloudron to clear out the old credentials/API keys, so it definitely doesn't need to retain two or more at any given time for a single domain. Hopefully that clarifies that part. Definitely no need to go down the rabbit hole of refactoring, haha.

@nebulon said in Using Cloudron to setup DNS records in new DNS Provider before switching Nameservers on domain. Vanity Nameservers could also be supported if changes made.:

if there would be an option to not resolve DNS records from the Cloudron side, one could change the DNS backend, then hit re-sync DNS in the Cloudron dashboard, then wait for the new nameservers to have all records in-sync and then switch the nameservers for the domain itself.

That's basically what's being asked here... to remove the requirement to double-check the nameservers in the first place before being able to save the API keys on the domain. I understand why Cloudron does it, it's to help avoid DNS propagation issues, however at the end of the day, Cloudron works as a script to populate the DNS records in any provider we give it access to, so it should not be restricted to only doing so if the nameservers are configured correctly. That limitation that exists currently prevents admins from having Cloudron setup the DNS records in the new location first which of course is best practice before switching the nameservers at the domain level, you don't want to be doing it afterwards. 😉 I think a good compromise if Cloudron team feels it's necessary to still check for nameserver pointers, is to warn but allow a user to move past it to freely have Cloudron setup the DNS records where we provide access regardless of nameservers.

Does the above make sense? I can clarify if needed. Basically just hoping that limitation can be removed in the product as it's impeding what I'd think are some important tasks to be able to do before changing nameservers on a domain.

@3246 yes, kind of like a torrent file where you can select priority per file/dir and which ones to skip.

not sure a pause is needed, but more like a pre-start selection.

I'm sure @staff can enumerate mail and other core services as required items but with flexible priority/order.

Not only that, but while we're pondering that manual selection process with manual clicks, the essential bits can already be restored and ready for the next prioritized components.

How much of this will change with Multi-Cloudron?

@d19dotca I'm excited by the potential for https://ntfy.sh.
Maybe a cloudron official instance which sets up channels for all customers, so cloudron-generated notifications can be delivered to a customer.
Or maybe there's a better way. I just think ntfy.sh is so easy to implement into scripts.

@tamayers yes this should be nice to set scan just only for where is write and read file. Not docker configure.

This will be part of 7.2.1

This is now implemented and will be part of the next release.

@d19dotca
that is also because Nginx uses FPM and not FastCGI(Apache in some cases can use FPM) for PHP, which give already a good boost.

NextCloud and WP could take good advantage of it, and Nginx could help solve the issue of the main image being too "fatty" 😉

It's easy to use Nginx in a multi-layer image.

It seems they don't offer SMTP relay as per https://www.mailerlite.com/help/does-mailerlite-offer-smtp-simple-mail-transfer-protocol . Their partner company mailersend has it - https://www.mailersend.com/help/smtp-relay . If you can, please try using mailersend with Cloudron's External SMTP Server option - https://docs.cloudron.io/email/#relay-outbound-mails . If that works well, I can add it to the dropdown (the dropdown is really just a UI template to prefill things).