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

[luckow]

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

Out of sight, out of mind.

[humpty]

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

[timconsidine]

Am I hallucinating or did I read somewhere that Surfer would get multi-domain functionality ?
If hallucinating, ignore me.

[girish]

@timconsidine thanks for the reminder I posted a follow up at https://forum.cloudron.io/topic/16009/surfer-v7-new-cli-deploys-app-passwords/5

[luckow]

Great. 75% done. What’s still missing? Redirecting to the correct domain.

Current setup:
Location = default location
Aliases = match the site configuration in Surfer
Redirects = redirect to the location

For a “real” multi-domain app, I need configuration options for this typical use case:
www.example.org
www.example.com

example.org redirects to www.example.org, and example.com redirects to www.example.com. As I understand it, that’s currently not possible.

[girish]

right, redirects are platform feature, so the app doesn't even know about them . A workaround for now is to move the redirects as aliases instead and set up redirects manually inside surfer.

I think if we want to make this truly truly multidomain, we have to simply merge surfer into the platform itself (instead of trying to make surfer more multidomain).

edit: then again, maybe we just need a simple redirects configuration in site configuration .

[timconsidine]

Aliases are working fine for me currently.
Moved 10 of my individual Surfer deployments into a single Surfer with the Site facility.
I haven't found a "smart" may to move content : I just download the individual deployment public folder, then uninstall the deployment, then create the alias and the site in the multi-domain deployment and re-upload the files from individual public dir into the new location. Manual but it gives me the chance to review/curate as I go.