As promised here here are more findings and suggestions that I propose for whitelabeling cloudron
I'm also including here the suggestions also brought up by @nothing that were also appreciated by @girish and fit well with some other suggestions I'd also proposed in some other threads (see references below)
Branding is too limited and the following are a few things I have noticed:
- Page Titles still contain Cloudron e.g. User account creation
- Emails sent to user with "Cloudron" in the subject, "powered by Cloudron" in footer
- In user's dashboard, hovering over fa-user icon user is prompted to "Login with Cloudron credentials"
- "Cloudron account" in a user's profile under App Passwords
- DKIM cloudron._domainkey prefix should be changed, not only for branding but other reasons (obscurity). Why needlessly announce an organization is using Cloudron?
Branding should extend to the above. and anything I have yet to see, especially in an Enterprise setting. It should reflect the name of the organization. Ultimately, the user is creating an account with the organization, and not with Cloudron.
Also, refer to features I proposed in a previous great discussion about Hiding superadmin to deliver 'managed' cloudron to clients.
So here's what I add, that I also came out for whitelabeling implementation of cloudron.
FOR THE ADMIN user (the not superadmin or superuser)
In SUPPORT should not have to 'verify' their email address with cloudron.io, then their should be implemented a field on a 'white label form' to fill, which will add the white label registrar's contact information or a mean to reach it instead of cloudron.io
In SUPPORT one should not see "You can also write directly to support@cloudron.io." again that could be either hidden or use a contact form to which WL registrar would add on the 'white label form to fill'
In SUPPORT ticket form should be sent to owner/superadmin of the white labeled CR instance - can be set or not through superadmin
In SUPPORT "remote support" feature should not be seen by admin but superadmin only, for WL version, because WL registrar would take care of the support of its clients. So, owner/superadmin would be the only one to use that to allow cloudron.io access to the server, if needed.
In SUPPORT superadmin should also be able to customise links to KB, Tutorial, and Forum, very likely through the 'white label form' to fill and submit to customize the cloudron instance as WL. So, again WL registrar can handle its own KB, its own Tutorials, and its own users' forum.
In EVENT LOG one should be able not see the superuser activities, if not superuser oneself (I guess it appears, I'm not sure)
In NETWORK at the moment logged in as admin I cannot see the Firewall function. Alright, while I can imagine why admin user cannot block IP addresses (reasons?), for WL version I would not see a problem to leave this feature at admin level, as well as superuser of course.
In USER DIRECTORY admin should not be able to see the superadmin role, in role's dropdown choices, when adding a new user.
In APPS admin should not be able to see superadmin in Access Control users' dropdown choices
Creating a WHITELABEL instance should be as easy as using a special code when one registers a new license from within one's cloudron.io account's UI. And that instance should then be added to the WL registrar (cloudron WL provider using its WL code) pool of WL instances.
Now, for the all the documentation links all over inside the box, in oder to keep the WL offer full and constant, I believe the easiest solution that would also be fine for all users of the cloudron box, WL or not, is to put all the docs on a new domain name dedicated just for that does not refer nor link back to the developer's website. The way it is done for now is not useful and confusing for any end users already.
Several cloudron owner use their instance to serve clients of their own already, so anytime an end user stumbles on a meaning to reach cloudron.io in any way, that is where the confusion starts occuring, because cloudron.io might not be their service provider in many cases. Moreover, that is also a protection for the client finder that its end user will not eventually bypass the original provider by going straight cr.io even if it's only inadvertently. Or even to keep competitors away from the 'secret software' they use as a provider loll 
There's no need to hide or replace the name of the box, cloudron, for the domain. As long as it's not directly linking users back to the develpers' website. That should be very easy and quick to implement using search and replace technique in the source code to change all the documentation links at once. Domain name should not be very hard to find or decide on, I'm sure something like cloudrondocs.something should be very easy to find.
And, also to make it more specific and easier to distinguish I'd suggest that maybe the term 'SUPERUSER' should be replaced to use OWNERADMIN instead.
More discussion revolving around the same views for brandind and whilabeling
Create app "packages" for 'managed' cloudrons
Branding Limitation
Any comments and or suggestions are of course very welcomed.
