I can't quite see how anything between those versions could have affected this and especially since reverting the app will put the old app back anyways, the only issue may come from the cli then or the token actually be invalid. To rule out one bit also, is the SSL certificate valid for the app? Also do you see any error in the server side app logs and can you use the cli outside your CI/CD?

Ah! This is what I needed: Surfer itself has an admin page to upload and manage files. Thanks

This is fixed with latest release.

@nebulon Thanks thats clear.

@insuusvenerati if you use one of the automated DNS providers, you can keep your server completely private just like you have now as well. No change in setup needed, don't even have to open port 80/443 ...

That is indeed odd that the app responds with 413 and there is no potential cloudflare proxying or so in between, which could get in the way?

Thank you!

Perfect, now it is working as expected. You're fast!

@nebulon Yes - I was getting confused about the WebDAV API keys, what user name as needed, etc. The thing that helped the most was clicking on the SFTP dialog for the app, which makes it very clear what the login information is. Clicking on SFTP for the Surfer app shows: [image: 1723582196179-f04ce061-ff35-4938-8219-ff57e38b8783-image.png] Thanks for your help! One more app configured and migrated

Since it is a static site generator, I guess you could also generate the assets locally and then push to a surfer instance. Otherwise, it may be similar to github pages, which build the static assets on git push and then just serve those. For this you would probably build a custom Cloudron app, which knows how to build the assets.

@bmann said in Github Actions documentation/example for Surfer: /website/* This is a bit weird. In the output above it complains that it cannot find /website/, while in your yaml you are passing website/. The first one would be no surprise if it does not work, the second one however should work as ci tools usually open a shell where you will be directly in your git checkout. I would try to debug this with inserting a few ls and pwd into your yaml to see where you actually are and if this might be a permission issue of some kind.

@nebulon said in Docs wrong?: For the cli help, did you mean the /app/data/* -> /* ? If so that is also fixed but pending a cli release. Yes, I was referring to the 4th example: surfer put dir/* / # puts dir/* as /app/data/*

@nebulon Thanks for replying. I guess I could just migrate to the LAMP stack and just leave PHP and MySQL idling; thanks for that idea!

Yes, going the html route is what I’m considering as an alternative even though true 301s would be preferred.

@nebulon I switched the folder into LAMP and it works fine now. Thank you.

@girish said in multiple static sites on one app: A "hack" if you really really really want a single app would be to use the LAMP app. You can add any number of alias domains. After that , yu have to then configure apache there to serve up different folders based on the request domain. Indeed, though you need to have a bit of Apache server knowledge and you can configure all your virtual hosts inside the Apache configuration file, which is named app.conf on Cloudron. As a matter of fact DO offers a pretty decent Apache configuration tutorial. It's relatively easy, you don't need to know everything, just how to host multiple static pages on once instance. Have fun.

Hm I don't have a Windows system here to test this, but opening it in the browser will not work. So maybe you can check the logs and see which requests Windows is issuing, especially which http verbs (get/propfind/...) it is using.

Hi. I only figured out my original problem with surfer (and suddenly with other apps too) about one or two months ago and it was because I was missing some points that are detailed here: https://forum.cloudron.io/post/78855 Thanks to @Jan-Macenka for sharing his thoughts and tipps. I put this here in case of others with "old installations" searching for similar topics.

Most likely this is a network routing issue (probably missing hairpin support with your router). With OpenID login, the app has to be able to reach the OpenID provider (on the dashboard domain), to test this, open a webterminal into the app and check if this works (replace domain.com with yours): curl -v https://my.domain.com/.well-known/openid-configuration