@girish In the meantime there were already several official, stable releases of statping-ng. The last one was 6 days ago (v0.90.80)
cfr this link.
So I suppose there is no reason anymore to stay with the original statping (for which the latest version was released in december 2020) ?
Ok, so I was correct when I said I seemed to remember there are some limitations with CF proxy and subdomains in the free plan.
When trying to open a ticket with CF regarding this issue I was pointed to the following link on their community:
https://community.cloudflare.com/t/subdomain-too-deep/81872
The certificates available with the free account (universal certificates) cover only one level of subdomains so my.domain.tld is covered, but my.sub.domain.tld isn't.
NetCup can't be held responsible for the reputation of the ip address, it's simply a result of what their users have done with that ip address.
And that's something you have to keep in mind when buying servers from any provider, not only NetCup.
But that doesn't mean you can't do anything about it. In fact there is a good chance you can revert it back to a clean state just by taking the correct actions.
As marcusquinn says, Hetzner is very good indeed, but their ip's aren't always clean either. They might be on some blacklists or even blocked alltogether by some parties.
I had a similar situation myself where the ip of our mailserver was blocked by Microsoft and as a result none of our emails could be delivered to microsoft addresses (hotmail, outlook, office365, ...)
BUT: I contacted MS and explained the situation. After providing the necessary info / proof of ownership of the ip, they delisted the ip address and everything is fine since then.
@girish I see, but I wouldn't expect any solutions from the old, abandoned ticket 
Maybe you can open a new ticket at statping-ng?
According to this thread DoT support was added in v1.2.0 of the AdGuard package (with Cloudron 6.2).
The Cloudron package documentation however still mentions that DoT is "not yet supported"
Therefore I decided to just try it out and after some fiddling with OpenWRT and stubby in particular I was able to get DoT working.
So I guess Cloudron's AdGuard documentation can use some extra love regarding DNS configuration 
@girish hmmm, I see, but imagine the following scenario:
Our clients come to us for developing a new Wordpress website and obviously they also want an integrated email system so they can send and receive mails for that website and probably they also want to see some analytics.
So we set up a separate cloudron for such client and install Wordpress for the website, SOGo (or one of the other webmail apps) for the email and Ackee for the analytics.
This means the cloudron is dedicated to the client and therefore the trusting factor is there since the client is the only party that makes use of the cloudron and its apps.
However, our clients aren't interested in administering the cloudron themselves so we will manage it for them. But they do want to be able to add extra email addresses when needed.
So the client will get the mail manager role while we are the admin of the system. In this scenario it doesn't make sense - and isn't even desirable - that the client can see our admin user.
So while I definitely understand your explanation, I hope you can see my point as well
After Nextcloud was automatically upgraded from v23.0.2 to v23.0.3 we started getting issues with up- and downloading of files and even opening of files in the browser.
We're using server-side encryption and a Hetzner storage box over sshfs for the data dir.
Further investigation learned that there was an issue with the encryption/decryption on the server.
The exact error we got was:
Encryption not ready: multikeydecrypt with share key failed:error:0407109F:rsa routines:RSA_padding_check_PKCS1_type_2:pkcs decoding error
Apparently some of the keys were changed in our data dir (the mounted external storage). Luckily we found older, correct keys in the original data dir of the cloudron app (i.e. inside yellowtent).
After replacing the keys on the mounted storage with the older keys from the original data dir everything started working again.
Since there are a lot of encryption related tickets in the Nextcloud repository I mentioned my issue and resolution as a response on one of the still open, relevant issues: https://github.com/nextcloud/server/issues/8349.
But I'm also reporting it here in case it's related to the cloudron packaging and/or someone else here is experiencing similar issues.
Is it possible to use a single domain, let's say example.com, with 2 (or more) cloudrons?
The use case would be to host multiple applications for the same company each on their own server, e.g. websites on one server and forum and mail on another server.
Note: I'm new to Cloudron and I really like it so far, but I'm having some specific use cases and it's not clear to me whether Cloudron is a good fit for them.
@girish That definitely sounds like an interesting solution, except that in my use case it's not (entirely) related to automation / programmatic access. So I guess it will also need some UI changes.
@girish actually both.
Visually, because it doesn't make sense to show admin users to mail managers when they can't do anything with them.
But also security wise because in my opinion users with a lower access role (in this case mail managers) shouldn't know any (sensitive) details about users with a higher role (in this case admins), e.g. username, email address, ...
We all know passwords shouldn't be reused for different accounts/logins but I'm sure usernames are and therefore I think it's better to not show such data to others when that data isn't relevant for them.
@girish Thanks, it's working again! 
@humptydumpty There are several alternatives indeed, such as cryptomator, but they don't solve the current issue with the Nextcloud encryption.
The only way to get access again to our Nextcloud files is by modifying the openssl config, but that's something only @girish or @nebulon can do I guess.
Same issue here, but I'm still on Ubuntu 20.04.
This is a major issue because we can't access any of our files anymore and we can't even apply the temporary workaround since the openssl config for the Nextcloud app is on a readonly filesystem.
Unfortunately this isn't the first time I'm experiencing issues with the server side encryption in Nextcloud 
Therefore I want to turn off the encryption alltogether, but that's only possible after this issue gets fixed 
NetCup can't be held responsible for the reputation of the ip address, it's simply a result of what their users have done with that ip address.
And that's something you have to keep in mind when buying servers from any provider, not only NetCup.
But that doesn't mean you can't do anything about it. In fact there is a good chance you can revert it back to a clean state just by taking the correct actions.
As marcusquinn says, Hetzner is very good indeed, but their ip's aren't always clean either. They might be on some blacklists or even blocked alltogether by some parties.
I had a similar situation myself where the ip of our mailserver was blocked by Microsoft and as a result none of our emails could be delivered to microsoft addresses (hotmail, outlook, office365, ...)
BUT: I contacted MS and explained the situation. After providing the necessary info / proof of ownership of the ip, they delisted the ip address and everything is fine since then.
@humptydumpty Thanks! Hadn't seen that post yet.
@girish When can we expect an update that fixes this issue?
It just happened again on one of my Cloudrons
@robi Yes, I tried it but it's too locked down. There were several plugins that didn't work, e.g. some security plugins.
Ok, I thought the whole point of the developer package was to have a "regular" version of Wordpress where you have more permissions and control over the code (such as plugins, themes, ...) similar to packages of other apps (NextCloud, Matomo, whatever) and that the managed version of Wordpress was to have a locked down version for security reasons.
But actually it seems none of the 2 Wordpress packages work in a similar way as the packages for other apps, since the managed version is a locked down version and the developer version is a "do it yourself" version.
Is that correct?
If so, then why is there no regular version of the Wordpress package where the core (i.e. Wordpress itself) is updated, similar to other Cloudron apps, while the plugins and other stuff are up to the user (again, similar to other Cloudron apps)?
Take for example Nextcloud:
When there's a newer version of Nextcloud a new Cloudron package is prepared and after updating to that new package Nextcloud is at the newer version. Nextcloud plugins/addons are not updated and should be managed by the user.
Why isn't this behaviour applicable to (one of) the Wordpress package(s)?