I would be interested to know if someone does this outside of Cloudron for their existing business/personal use. Seems like a lot of work (and probably just easier to switch out your NS provider if they are flaky). We use route53 for cloudron.io and AFAIK it has never gone down.

@doodlemania2 the 'Custom wildcard certificate' option .. That generates a self-signed cert, if you don't provide one.

Thanks for your investigations!

In general, as @micmc pointed out, there is no real benefit of multi-tenant setup on Cloudron.

The biggest benefit I see is a clean dashboard. I did such a setup on other hosting platforms and never had trouble with that.

While an app can have multiple databases on Cloudron, we have to investigate if it's worth the trouble of supporting such a setup.

Yes, I'm wondering this request is so rare.

@humptydumpty yeah, and I think the vast majority of sites do not and will not get "slash dotted" or get DDoS attacked and anecdotally I've seen WAY more people (including on here) mentioning issues/ problems caused by Cloudflare than people saying "thank good I was using Cloudflare" (I don't think I've ever seen anyone say anything like that)

I think it's a bit like High Availability stuff. As @marcusquinn has I think mentioned elsewhere, most people just don't need it.

And whether or not all/ most of that article I posted is now outdated, it seems obvious to me that everyone using Cloudflare (who in the end are just another investor owned private profit seeking big corporate) contributes to the over centralisation of everything on the web.

Just for info, I also found these bits of their recent SEC return interesting:

We have a history of net losses and may not be able to achieve or sustain profitability in the future.
We have incurred net losses in all periods since we began operations and we may not achieve or maintain profitability in the future. We experienced net losses of $260.3 million, $119.4 million, and $105.8 million for the years ended December 31, 2021, 2020, and 2019, respectively, and as of December 31, 2021, we had an accumulated deficit of $680.8 million. Because the markets for our products are rapidly evolving, it is difficult for us to predict our future results of operations. We expect our operating expenses to increase over the next several years as we continue to hire additional personnel, expand our operations and infrastructure both domestically and internationally, and continue to develop our products. In addition to the expected costs to grow our business, we also are incurring significant additional legal, accounting, and other expenses as a public company, as described in greater detail in the risk factors below. If we fail to increase our revenue to offset the increases in our operating expenses, we may not achieve or sustain profitability in the future.
We have experienced rapid revenue growth, which may not be indicative of our future performance.
We have experienced rapid revenue growth in recent periods, with revenue of $656.4 million, $431.1 million, and $287.0 million for the years ended December 31, 2021, 2020, and 2019, respectively. You should not consider our recent growth in revenue as indicative of our future performance. In particular, our revenue growth rates may slow or decline in the future and may not be sufficient to achieve and sustain profitability, as we also expect our costs to increase in future periods. We believe that historical comparisons of our revenue may not be meaningful and should not be relied upon as an indication of future performance. Accordingly, you should not rely on our revenue and other growth for any prior quarter or year as an indication of our future revenue or revenue growth.

@girish said in Vultr DNS default TTL:

The initial value set is really just a default and nothing else. It's not even a preferred value as such. Admins have perfectly valid reason to set up long TTLs (especially for long lived sites).

This would be a good reason to have TTLs be configurable 😉

But okay, I think I understand that it'd be a bigger backend change than the gain from it, then. I suppose I could find a way to use the Vultr API to modify all the TTLs for consistency-sake.

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.

@girish the work around worked perfectly

@LoudLemur

User Settings -> Account and security:

3e077cae-ab07-4405-9c6e-e319aa9e5dcc-image.png

Then, it's in the Security section under API key.

67c17fe7-6e19-443c-aa3f-ea2740a45b44-image.png

Only workaround without adding the feature is to simply have Sufer or LAMP redirect to your dashboard. You should also be able to use an existing LAMP or Surfer app by checking the Host header.

@LeeW Thanks for trying it and letting us know!

@colonelpanic said in Cloudflare Setup Questions:

I assume that renewing the Let's Encrypt certificate would not be an issue with the proxy turned on because Cloudron is using a DNS challenge instead of HTTP challenge. Is that a true statement?

Yes. Proxying can be left turned on, Cloudron will manage to get certs via DNS challenge.

What would be the benefit of creating a Wildcard Origin Cert on Cloudflare and uploading it instead of using Let's Encrypt?

AFAIK, there is no benefit. I think the wildcard origin cert is intended for cases where one cannot get a valid cert via DNS or HTTP automation (like some intranets that block outbound access).

Okay, this was kinda weird. Did register the domain and added it to CloudFlare. Got the error "invalid domain" while adding it on Cloudron. Got the error while using CloudFlare, but also with wildcard.
As I had some other work to do, didn't really check after my post. As I tried to add it to Cloudron for a screenshot and after that the manual solution, it suddenly worked, while having selected CloudFlare. So maybe there was a problem with resolving the domain before, but it is working now at least.

@mehdi Ohh didn't thought about that ! thanks a lot !

@msbt thanks so much. My interpretation of the fix suggested didn't work. I have posted a follow-up question there.

@msbt Thank you, that makes sense!

@girish So clever! Worked like a charm.

The only part where I had to fuss for a few minutes is that the app errored on changing to the new domain; it got stuck on de-registering the old domain. I went into the Domain manager and deleted the domain entirely from the Cloudron and then the app was able to receive the new domain without problem.

Thank you so much for writing the steps out in detail. I really appreciate it!

@nebulon I just added a new dns record on Namecheap manually. After this action, cloudron was able to add my second domain 😅

I solved the same symptoms by recreating Personal Access Token for Cloudron.
Screenshot 2022-01-13 at 6.18.06 PM.png
Read/Write access under Domains required.
Mine just expired after default set 6 months.

Adding a redirection made things work.

@jodumont For apps that require multiple domains from the get-go i.e they require multiple domains at installations time, this is part of the next release (7.1) - https://forum.cloudron.io/topic/5982/what-s-coming-in-cloudron-7-1 .

Many (most?) apps can only handle being configured with a single domain. There is usually an APP_ORIGIN or equivalent setting that can only be set to one domain and is not an array. It is used by the app to set up CORS headers, generate static links, email links etc.

@necrevistonnezr said in Godaddy.com API is down:

unfortunately none of the Cloudron supported domain providers allow moving a DE domain…

By DE domain do you mean .de?

You can definitely register those on https://gandi.net but perhaps that's different to moving them?

@samuelbevan2000 you have to port forward port 443 in the router to the vm.

@girish Magic, that seems to have worked - thanks!

Maybe worth considering adding this advice to the email notifications?

@scooke yes, you can mix between Cloudron's automation and manual DNS changes. In fact, that's the normal and only mode of operation.

The automation is only adding and removing things that you would have to do normally outside Cloudron. For example, when you install an app, you have to setup A records. When you uninstall an app, you remove the A records. This is all the automation does. If you try to install an app in a location and there is already a DNS entry in your DNS provider, Cloudron will inform you of the same and let you 'overwrite' it or cancel the app installation.

Same goes for email stuff. It sets up things like DKIM/SPF records automatically. These are updated carefully to not collide with existing entries. The MX record is only touch if you enable incoming Cloudron Email. Even in that case, there is a checkbox to not update DNS.

@girish ok i was on the initial setup and i had to click 'show advanced settings' and then set the subdomain to the zone.

a simple hint after the error with something like your message would be super helpful on that page. i'm super busy right now but could try a merge request if that would be welcome.

i appreciate the quick help, thank you.

@scooke we have traced this down to a nodejs bug apparently with the domain in question.
The upstream issue is at https://github.com/nodejs/node/issues/39397

The CLI has indeed no way to edit domains. What you did is the correct approach - make the dashboard available via the browser and then edit from the Domains view.

(As for the CLI warnings, looks like we have to replace request module with superagent. Sigh, we actually used to use superagent before...)

@girish Correct. In my case they're almost all managed by Cloudron with some exceptions like extra records needed by Mailjet for example, but yeah the vast majority of the DNS records between all the domains I manage are Cloudron-related.

@girish said in DNS CNAME and Cloudron Redirect for WWW:

roundbear.org

Thanks - that'll teach me to test things simultaneously! Fixed.

Solution:

set cname on cloudflare to www / baredomain.com set redirection on the app to add www

https://docs.cloudron.io/domains/#overview 😉

Yes, you can add new domains to Cloudron. Depending on where the authoritative servers are for the domain, you can use the dedicated API-based setups (i.e. AWS, DO, Namecheap, Linode, etc), or you can instead use the Wildcard setup for any other service that's not explicitly listed in the providers list.

Then once the domain is added to Cloudron, you can add redirections to the same app if you desire, in the App page: https://docs.cloudron.io/apps/#redirections