@nebulon there was no error reported by cloudron. The issue was that if I tried to curl, there was nothing returned back (I don't remember the exact reply -- sorry for that). Basically it was like nginx was not routing properly, as if nothing was running at the subdomain.

@infogulch said in Changing from wildcard to provider-based dns configuration left apps and my.example.com unassigned after wildcard was deleted:

That makes a lot of sense. Curious, does Cloudron log when it encounters an existing DNS record that it should not overwrite?

It will show the error in the UI. If you try to install an app into a subdomain that has a DNS entry, it will error and give you an option to "overwrite" the DNS record.

@girish Im tracking with what you saying but the API didn't create any A records. In fact i couldn't get to the dashboard at all until i created that * wild card. I still have no idea why its not redirecting to HTTPS if i put int http://www.mydomain.com. The only files the API created in dns were 2 txt records and a testcloudrondns at 127.0.0.1

Did not know this was existing till now... thanks man

@nebulon there should be branching logic after Cloudron 'senses' that it doesn't own that DNS anymore.

Prompt for delete of an unmanaged resource in that state?

@robi yeah, with ecommerce being our primary business, we're invested in this. We have 12 very experienced devs on the team but just a few of them have had time to start looking at Cloudron this week. In this for the long-term though so I'm sure you'll start to see our work filtering through very soon.

@jdaviescoates said in "subdomain 'selfhost.cloud' is in use":

use the File Manager

Which is exactly what I did 🙂

Actually the first time I used to nice new File Manager 🙂

@girish domain expiry is more of a calendaring function IMO

but a whois query at domain setup could get you that date which Cloudron could remember and prompt during that month via notification.

I'm with @nebulon, I see this as difficult to support, harder to code for - and more user friction. I usually never support more user friction unless it's dire. I think configuring after installation is more than acceptable. It's not like we can't write scripts using their API to macro your suggestion too, but I digress. 😂

can you modify the title a bit for clarity since this isn't a migration but more of a swaping or switching?

ty

UPDATE: it's been modified within 2m, thanks to @girish

@d19dotca Fixed for the next release, thanks for reporting.

Never had an issue with cloudron in FF, neither in the Terminal nor here. I can confirm that I can just paste screenshots

@jordanurbs said in A Question About Domains, Subdomains, Email, and DNS:

. Some apparently don't allow the * symbol for a wildcard domain

You can also use the manual dns provider. With that, you just have to add the DNS entry manually before you install an app. The UI will remind you to add a DNS entry.

@d19dotca I'm inclined to agree that it might be something better documented - but more-so because caching problems can cause support burdens where they are a common source of issue for the uninitiated.

I like your suggestion that documentations have comments like "we tested this and it worked for us" sort of thing.

@atrilahiji I use Namecheap too, decent service but equally the Cloudflare free DNS services is pretty solid and not had any trouble with that & Cloudon. Just mentioning in case you got stuck or hadn't compared that option.

Thanks @marcusquinn ! There is a bug in the Cloudron code where we were using the wrong API call to list zones when validating the config. https://git.cloudron.io/cloudron/box/-/commit/45c49c975712ee4b3bbf306ca7492c60a41c4c57 was the fix.

@alejandrolengua This documentation page is mostly geared towards setting up with different DNS providers, but this is a good place to start too as you'll need this to add new domains to your Cloudron server: https://cloudron.io/documentation/domains/

@girish

This is intentional because the root domain record can be in use on another server/app/website.

Right, that makes sense.

I added a redirect from the root domain and it solved all my problems. Thanks for the quick help.

@girish yes, that’s a much better idea. Essentially the ability to “swap” app instances, or in other words the ability to easily promote from staging app instance to production app instance on the same server. That’d be ideal. 🙂