@DAMO11-coder see https://docs.cloudron.io/troubleshooting/#expired-domain

I just jumped the gun. It was just DNS taking a while to propagate. All good now.

@Shaun-Snapp said in Add an A record manually for the domain:

"Add an A record manually for www.abc.com to this Cloudron's public IP"
I purchased the domain around 1/2 hour before trying to change an app to that domain. This is the error I received when the app failed to propagate.

That message is saying that you have to add the A record manually in your domain provider (not in Cloudron). Cloudron cannot add/remove DNS entries for the domain because it's "manual" mode and thus has no programmatic access to your DNS.

The place where you purchased your domain most likely has a Domain/DNS control panel where you can add/remove DNS entries.

Yes, see the instructions at https://docs.cloudron.io/troubleshooting/#expired-domain . If that's too technical, please feel free to mail us at support@cloudron.io and we can help switch it.

Ignore me. This was an issue with PowerShell apparently. If run from linux it works fine.

Thanks again

@girish Thanks. All working perfectly.

Thank you that worked!

@girish ok, understood

@girish
Perfect, thank you!!

@girish I was a little impatient, it's back. Thanks

@subven Thanks for the details I will also trying this later today..
I appreciate the help. It is different to wrap your head around the Cloudron way of thinking....

@nebulon I haven't investigate but certainly some extension that blocked the ability to write there.

I was just wondering why the forum was down, yet the many subdomains were working fine. 😆

Yay for more resilient features.

@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!