Feature request: Ability to have Cloudron _not_ remove DNS records upon uninstalling an app.

[d19dotca]

Hello,

I know this is a bit of a fringe case, but I ran into an unfortunate timing incident where DNS propagation from DigitalOcean was taking 30-60 minutes to go around the globe instead of the usual minute or two (DO is normally super quick).

My use-case was to uninstall an old website and replace it with what was the staging site. The new app was going to use the exact same domains and subdomains. I uninstalled the old app (well actually I moved it to www-old instead of www but it'd be the same thing DNS-wise as it removed the whole app as it'd remove the www record). I then added in the new locations for what was the staging site so that it would assume the new role, and as it would happen DNS propagation was having issues in between the time I uninstalled the old app and started to setup the new one. So unfortunately, the removal of www was quickly propagated, but it took 30+ minutes for the www record to propagate again, causing some downtime for the site.

While it's definitely a fringe-case due to the general reliability of DO DNS servers and other worldwide DNS servers, if my intention is to essentially have one app take all the same locations as the old app, I think it may be beneficial to have Cloudron leave those locations alone so that no DNS changes are made, and it's all kept local on the Cloudron server for what app receives the requests.

The way I invision it, is when uninstalling an app or changing a location, perhaps a pop-up to verify if the DNS records should be removed or left alone. Or a setting that automatically leaves all location changes alone at the DNS level that's maybe system-wide?

Hoping it'd be something simple to add and could prevent certain fringe scenarios from occurring without negatively impacting the normal workflow.

[girish]

I think a related issue is that it will be nice to simple "swap" a staging site with prod. Currently, we have to move the prod app some other place and then move staging to prod. Quite cumbersome. Internally, all that needs to happen is update some db entries and maybe configure the reverse proxy (so it's local to the server) but it avoids external services altogether.

[d19dotca]

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