Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


    Cloudron Forum

    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular

    Set domain redirects and memory allocation before initially creating the app

    Feature Requests
    domains userinterface memory
    4
    7
    211
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • ?
      A Former User last edited by girish

      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.

      1 Reply Last reply Reply Quote 3
      • nebulon
        nebulon Staff last edited by

        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.

        1 Reply Last reply Reply Quote 4
        • ?
          A Former User last edited by

          Ah so it is more due to strange error states you encountered bundling memory allocation and domain changes?

          1 Reply Last reply Reply Quote 0
          • nebulon
            nebulon Staff last edited by

            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.

            ? 1 Reply Last reply Reply Quote 1
            • ?
              A Former User @nebulon last edited by

              @nebulon Fair enough. Better leave them separate then. I don't want to pray to the async gods every time I start an app 🙂

              1 Reply Last reply Reply Quote 1
              • robi
                robi last edited by

                this is where a task queue could come in handy, for which the user/admin doesn't have to wait for.

                Life of Advanced Technology

                1 Reply Last reply Reply Quote 0
                • Lonkle
                  Lonkle last edited by

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

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post
                  Powered by NodeBB