What does it take to use Surfer as a “real” multidomain surfer?

[james]

So an order and folder function for app elements in the dashboard would be the feature request I guess.
Having the ability to stuff "background" apps like Synapse, Valheim or TeamSpeak into a folder and forget about it.
Same with the 10x Surfer problem. All into a folder. Out of sight, out of mind.

[luckow]

@james said in What does it take to use Surfer as a “real” multidomain surfer?:

Out of sight, out of mind.

[humptydumpty]

@james Maybe this could be useful resource wise too. IDK if it works this way, perhaps a dev can explain but if each surfer app idles at +50MB. Would stacking all the sites on a single surfer app bring down the overall RAM usage? For example, 50 MB RAM x 10 surfer apps = 500 MB vs. having them stacked in a single surfer app that would have 50MB RAM usage only. Food for thought. If it's the latter, then any cheap hosting plan could work for basic sites/businesses.

[timconsidine]

@james said in What does it take to use Surfer as a “real” multidomain surfer?:

folder function for app elements in the dashboard

Hey, now you're on to something.
Folders would be great and serving multiple needs
For me personally the dashboard filter doesn't really hit the mark.
Yes, it does work, so no complaints.

But having a folder which I could put all apps for a domain, now that would really help overcome "can't see wood for trees" syndrome. I have 130 apps deployed.

In some cases I might want to group apps by ephemeral criteria not available in dashboard filters, such as "fringe".
Tags go some way to this, but a folder would be neat.

[rosano]

I just worked on a hack for this https://github.com/rosano/remit

It's a small separate app that maps multiple domains to folders under any public URL: so if it gets a request for your-site-domain.com/path, it will fetch https://your-surfer-cloudron-domain.com/maybe_a_folder_with_some_websites/your-site-domain.com/path and send it as a response. So you name folders with the domain and it figures out the rest.

[nebulon]

I think what you really want here is a location rewriting reverse proxy. Maybe apache mod_rewrite using the lamp app would work here. Given the generic nature of (sub)domains mapping to paths, I guess in the end everything ends up as a hack unless there is a proper regular expression syntax supported.

(a propery reverse proxy is required as unlike that remit hack, you also need to handle all HTTP verbs like POST, PUT,.... as well as dealing at least with header and status code forwarding)

[rosano]

@nebulon Agreed. I just use the tools I understand, so it tends to end up with this shape. For me static sites only require GET anyway. I copied headers in the previous version, maybe will add that later. Pull requests welcome if someone wants to improve it.

[robi]

One could also do it in the reverse, but having your Surfer app with several sites in subfolders, then install an App Proxy for each subfolder.

The issue is you now have a lot of App Proxies in your dash which is just like all the Surfer apps..

Since we don't have better control over the Cloudron reverse proxy, having more features in the App Proxy would make sense.

@nebulon what do you think about bringing it into the Services section of Cloudron which would allow us to add an arbitrary number of proxy records all in one place?

Or it could filter down into the Location section of App Config with Aliases and Redirects, which could then support ports and paths.

[timconsidine]

I think it is possible to write a simple nodejs app which handles the proxy.
One surfer instance, one nodejs app in it started on launch, multiple folders/sites.

[robi]

Not sure you even need that, as I recall writing some JS for a list of redirects based on the incoming request which could send you anywhere else as part of the index.html on a Surfer App.

The main issue I think was URL cloaking so the address bar doesn't change, while the content of the page does.