Cloudron Forum

Wildcard - In wildcard, you setup subdomains to point to the server IP. So, when you install an app or change it's location, Cloudron won't remind you to point the DNS to the server IP. Manual - When installing an app or changing it's location, Cloudron will remind you to point the DNS to the server IP. Why prefer one over the other? Wildcard is one time setup. Manual is something you have to do on each app install. People also sometimes ignore the "instructions" it shows to adjust the DNS and click Install. Depending on your DNS provider, DNS propagation can take long. So, let's say if it takes 15 mins or something, then when installing the app, Cloudron will be unable to get certs. This can lead to a bad UX.

@girish said in add deSEC as DNS Provider: deSEC integration is implemented for next release. That is the best message of the day. Thank you!

@robi It might not be advertised. Also, I think it isn't a sale, and the renewal price is the same, though I may be mistaken.

@jayonrails whoops, didn't notice!

I had a similar problem recently. Here's what I had to do in order to be able to programmatically update DNS records for a domain in Google Cloud DNS: verify domain ownership: https://cloud.google.com/endpoints/docs/openapi/verify-domain-name. I did this by inputting a special DNS TXT record into DNS for the domain. in my case, I was using a Google Cloud Service Account with Terraform (not Cloudron) to modify DNS records in Google Cloud DNS, so in additional to verifying domain ownership, I had to actually add the Service Account I created as a verified owner of the domain as well. After doing these two things, I was able to programmatically update DNS records for the domain using the Service Account. So, assuming you've created a Service Account at Google, given it the "DNS Administrator" role, and added the Service Account email as a verified owner of the domain, you should be good to go. I just tested it with my Cloudron and it all worked. I'm attaching a screenshot of the Google domain verification screen showing where I added the Service Account as a domain owner. Hope this helps.[image: CleanShot 2023-04-26 at 07.28.52.jpeg]

@j_vmess your domain works just fine for me here. Maybe it's a browser cache issue? Have you tried another browser or after clearing the browser cache? I removed your domain from the original post, since it was showing the setup screen.

@scooke yes, it won't remove your existing records and won't touch things outside scope of Cloudron (which is basically app records and email records).

@Fabix thanks. Strange stuff... I will put it in our docs that we only support Robot.

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