Cloudron: A platform for self-hosting web apps | Hacker News Reader

Cloudron: A platform for self-hosting web apps

cloudron.io

8 pointsnebulon18 comments

This seems like a much more minimal version of what Sandstorm does.

Sandstorm is more interesting in many ways, but it's oddly high friction to get going with it. I installed it, got its config page, and was excited to get it running, but then I discovered that you can't just have normal password auth. You must authenticate using a third party service like Google or via one of their 'enterprise' options like LDAP, etc. This seems really really strange for a 'decentralization' oriented project, and I just didn't move forward with it because... huh? I just wanted to log into the thing and use it.

Hi co-founder here. We do follow a similar goal than sandstorm does, however I think our approaches are quite a bit different.

From your example, we do not have any 3rd party services integrated and it does not even fit into our idea, but instead have single sign-on for all apps bound to your own Cloudron user management. In fact your own Cloudron is for example an LDAP and OAuth provider on its own for the installed apps.

Regarding your high friction to get going, we only now started to support self-hosting outside of our managed version, so there are still rough edges as well, but that is what we are focusing on next. This is also one of the reasons, we only currently support AWS (even though other providers are in the works), the setup to get to your Cloudron should be easy, afterall that is one of the main goals to make self-hosting easy. If you have more feedback in that area, that would be great.

The biggest thing you might want to support (I can't find any mention of it in your docs, but instant kudos if you already do) is some form of two-factor authentication. TOTP is wonderful because there's apps available for every platform to do it, and it's really common.)

Yes, we are on it :) https://git.cloudron.io/cloudron/box/issues/2

Sandstorm founder here. Thanks for the feedback. This is a bit off-topic for this thread (apologies to Cloudron), but I wanted to clarify that one of Sandstorm's authentication options is "e-mail", i.e. authenticate using any e-mail address. While technically e-mail is a "third-party service", it is decentralized and ubiquitous.

There are two reasons we don't like plain username/passwords:

- They are notoriously insecure. If you're running a server with passwords you usually want dedicated staff to deal with account hijackings, which self-hosted servers obviously won't have.

- They are not global identities, i.e. someone else's Sandstorm server cannot authenticate the same identity. So if you transfer an app to a different Sandstorm server (something we aim to make easy), all the identities would have to be replaced with new ones local to the new server, which will probably confuse the app.

With that said, we have been thinking about other ways to solve these problems and we might introduce a plain old username/password option in the future.

Thanks for the response!

I gave up pretty fast on the e-mail option since I had to set up a mail server and it was painful... we use Google for e-mail and it could not use that, and setting up anything else is a many-step time sink.

I did not want sandcats.io but to use this on a private (ZeroTier) intranet. Even for your enterprise offering, which we might be willing to pay for, you still don't have a clear and simple way to auth. For enterprise I have to set up LDAP or other complicated nasty things.

My personal rule for UX:

Each step that must be performed to set something up cuts the adoption rate in half. So if you have an audience of 1000 and 4 steps, 63 people will end up trying your product.

That's not hard science, just a rule of thumb I use to impress upon myself and my team how important UX and zero-config is. It does have some basis in logic. Think of each step as a bit in an integer for 'cognitive load.' Each additional bit increases cognitive load exponentially, not linearly, since the total setup involves the specification by the user of N bits of information.

I'd highlight that there's multiple options here that require less steps, like using Sandcats, or passwordless email login, but that you've specifically decided none of those options are acceptable. So you're specifically looking for the most complicated use case you can come up with, and then complaining there's nothing simpler. ;)

I do like your rule, regarding people "trying your product", but I don't know if it really applies to setting up a server, because setting up a server of your own is probably the worst way to try something you aren't sure you want to use.

I'd suggest that anyone looking to "try" Sandstorm should be looking at Sandstorm Oasis, which is managed hosting you can try for free. (Along with being an easy place to see "live demos" of any of the apps on it.) If you try it on Oasis, and decide it fits your needs, you're much more likely to implement the additional steps required to configure it how you want it on your own hosting.

I don't think I'd ever personally put in the effort to set up something self-hosted until I already had "tried it".

To me the whole value prop of Sandstorm is the idea that we can run our own absolutely independent cloud server. External dependencies for auth or hosting (e.g. relaying everything through sandcats.io) bring us to "well why not just use Google?"

And as much as Sandstorm helps, running a reasonably secure absolutely independent server is going to take some manner of work. ;)

While there are definitely platforms that work with just a username and password, they are arguably drastically less safe in that scenario.

The whole idea of Sandstorm is to drastically reduce that work.

And it certainly does. I daresay you will not find a self-hosting platform that requires less work to implement but is equally as secure.

Could you clarify a bit on that? I might not fully understand what additional security sandstorm gives here. Would those login security issues be mitigated once Cloudron has 2fa implemented?

You should give Cloudron a try. It is an absolutely independent cloud server (including sending email).

In all honestly, Sandstorm without outgoing SMTP configured is not a great experience regardless of how you authenticate. So probably we need to focus on making SMTP setup more automated.

Note that Sandstorm also offers "passwordless email" login, which is kinda like doing a password reset for each login. The primary reason for this is that the Sandstorm team doesn't feel a normal username and password setup is adequate security with the level of protection identity providers like Google and GitHub currently offer, and because they also want to make sure the same account can be used across any Sandstorm server for eventual federation purposes. I kind of wish you could use a more insecure login method if you wanted to, as well, but that's the reasoning for it at least.

If you don't use Sandcats, which provides free dynamic DNS and wildcard SSL, Sandstorm is a bit more work to set up, but that is because it is almost certainly more secure. Sandstorm is designed to protect you from malicious or buggy apps, which require a lot of mitigation strategies that Cloudron doesn't look to offer. Some of these are why Sandstorm currently can't work with Let's Encrypt, for instance.

But Cloudron definitely has friendlier URLs, which seems to be a particularly strong desire for some people. A little DNS management could handle that for Sandstorm where desired, but they don't have that figured out yet.

Probably the biggest difference between the two is that Sandstorm doesn't put "apps" at the top level of organization, but puts "grains" (basically, files or instances) as the top organizational structure. This means individual documents run entirely separate instances of applications, which makes them more secure. It's difficult to provide say, etherpad.mysandstorm.com because each Etherpad document you have open is a completely separate Etherpad server!

nebulon, I feel you buried the lead here. I came in here and was like "Cloudron already offered self-hosting on AWS, what's this announcement/blog for?"

You guys went open source! THAT'S AWESOME. But you didn't mention that until the bottom of the blog. :( You should highlight that news better!

Congrats and welcome to the open source world! :D

Thanks for the hint about messaging. I guess we haven't seen it as a huge PR thing for us, as it is more like the natural thing, coming from an all open source environment anyways. We just had no time/focus to do it till now and until recently the code itself it was pretty useless as such for others. With the AWS self-hosting only the first step is done to help people use it in their own way.

I think it's a big deal because most decentralization folks and self-hosters wouldn't take a closer look at a platform that wasn't open source. So you get a chance to get that second look when you push that news.

And things going open source usually does well on HN as a headline.

Reply on news.ycombinator.com