<![CDATA[Set domain redirects and memory allocation before initially creating the app]]>This would be quite useful as just a QOL change as right now the process takes more clicks than I think it reasonably should (just being nit picky really). So you make the app with a domain, you go into settings and add a redirect which triggers a restart, and finally you change the allocated memory which again triggers a restart.

]]>https://forum.cloudron.io/topic/3347/set-domain-redirects-and-memory-allocation-before-initially-creating-the-appRSS for NodeFri, 17 Apr 2026 02:39:46 GMTThu, 08 Oct 2020 05:14:21 GMT60<![CDATA[Reply to Set domain redirects and memory allocation before initially creating the app on Sat, 10 Oct 2020 20:08:15 GMT]]>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. 😂

]]>https://forum.cloudron.io/post/15420https://forum.cloudron.io/post/15420Sat, 10 Oct 2020 20:08:15 GMT<![CDATA[Reply to Set domain redirects and memory allocation before initially creating the app on Sat, 10 Oct 2020 03:15:11 GMT]]>this is where a task queue could come in handy, for which the user/admin doesn't have to wait for.

]]>https://forum.cloudron.io/post/15379https://forum.cloudron.io/post/15379Sat, 10 Oct 2020 03:15:11 GMT<![CDATA[Reply to Set domain redirects and memory allocation before initially creating the app on Fri, 09 Oct 2020 17:29:52 GMT]]>@nebulon Fair enough. Better leave them separate then. I don't want to pray to the async gods every time I start an app 🙂

]]>https://forum.cloudron.io/post/15345https://forum.cloudron.io/post/15345Fri, 09 Oct 2020 17:29:52 GMT<![CDATA[Reply to Set domain redirects and memory allocation before initially creating the app on Fri, 09 Oct 2020 09:58:53 GMT]]>Various things have to happen in the backend to facilitate that. Some, especially around the domain are heavily async and might take time and can fail. So to handle all that also during installation all in one go is much harder and results in various states which are harder to recover when doing all at once. So the decision was made to lean towards broken up tasks to avoid situations where a user is left with states hard to recover without deeper knowledge.

]]>https://forum.cloudron.io/post/15320https://forum.cloudron.io/post/15320Fri, 09 Oct 2020 09:58:53 GMT<![CDATA[Reply to Set domain redirects and memory allocation before initially creating the app on Thu, 08 Oct 2020 16:05:54 GMT]]>Ah so it is more due to strange error states you encountered bundling memory allocation and domain changes?

]]>https://forum.cloudron.io/post/15204https://forum.cloudron.io/post/15204Thu, 08 Oct 2020 16:05:54 GMT<![CDATA[Reply to Set domain redirects and memory allocation before initially creating the app on Thu, 08 Oct 2020 09:42:42 GMT]]>We used to have all those things in one task internally and broke that up then. The reason was to have better ability to retry/repair functionality if something goes wrong. The trade-off is basically more potential clicks and restarts vs less hard to fix app states.

So far our idea for the installation dialog is, to be less complex so a users can quickly install and then go about configuring it in more detail until it is then actually used for production. Also this helps to avoid much code and error checking duplication in the UI and backend, which again lowers the chance to hit bugs.

]]>https://forum.cloudron.io/post/15154https://forum.cloudron.io/post/15154Thu, 08 Oct 2020 09:42:42 GMT