@p998 You have to change the DNS entry of maindomain.com to your external server's IP.

@fbartels ok, this makes sense, thanks!

@girish I did something slightly different (but maybe not SO uncommon). I created the server and put the clients domain into my own (developer) cloudflare account. After everything worked I created the domain in the client's cloudflare account and changed the NS entries (basically this: https://developers.cloudflare.com/fundamentals/get-started/basic-tasks/manage-domains/move-domain/).

the situation was now, that the API key was still valid but changed the wrong domain entries at cloudflare. so, I imagine cloudron creates the NS entry, checks if this works (which it doesn't) -> brain freeze. Something like this?

@girish thank you! And thank you again for your prompt help!

@nebulon thank you! Guess I missed 7.2.0 & 7.2.1 🙂

@girish gotcha, thanks!

Just to note, it seems it was a timing issue, where the DNS in this case took longer than expected for full propagation.

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 Err, I forgot that I already removed those last week as well - https://git.cloudron.io/cloudron/dashboard/-/commit/72ba61ad91d326c3f287a2f538809cc78afcfdc8 . So, this should be fixed in next release.

Thanks Girish! 🙂

@girish said in Vultr DNS default TTL:

The changelog is not comprehensive, it doesn't have 1-1 relation with all changes since it also goes into the UI. Only way to know is the git log for small changes.

Totally fair. I was surprised to see that one missing since there's a ton of smaller changes still in the changelog in previous versions. I always thought the changelog was quite comprehensive before, but maybe it's geared more high-level now.

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?