Show HN: Portal – Personal Cloud Servers | Hacker News Reader

Show HN: Portal – Personal Cloud Servers

portalplatform.net

This just looks like expensive managed hosting. It's still just cloud hosting on someone else's hardware.

For truly personal 'cloud' apps, I recommend projects like Freedombox or Sandstorm. They make it this easy to deploy cloud apps on hardware you actually physically own and control.

We're trying to make it as close to self-managed as a sysadmin running their own machine in a colo. We're not there yet but that's where we're headed. Sandstorm is working on a hosting service as well.

The only way you can truly control a server, as an individual, is by running it out of your home. The problem with servers at home is that most residential internet is terrible for running servers on.

You can have locked cage space leased from a datacenter if you want to be in control of all the things you have any business being in control of.

That, however, is prohibitively expensive for small scale users though. Even moreso than running a box from home.

I did a quick comparison with DigitalOcean, and it looks like equal (obviously, with more features). What's cheaper cloud hosting than DO (that's not crap)?

Vultr:

https://www.vultr.com/pricing/

The big difference is that with Portal you can run 8 x 128 MB (or 4 x 256 MB) VMs within a single 1 GB memory plan. Running each of your apps in a separate VM on a standard VPS would cost a lot more.

This sounds like a case for containers, does it not?

Yes, we initially used containers. We think VMs are a more secure form of isolation, which is arguable. We also want users to have the ability to run apps based on a variety of operating systems and kernels.

Portal apps themselves can use containers of course. For example, a game server app might run each game process in a separate container within its own VM.

IMO people who aren't political dissidents are generally better served by renting reliable resources in a datacenter with good bandwidth than running flaky hardware in their home off their broadband. Fortunately the sticker shock of a $200 box vs. $10/month will mostly take care of this issue.

I think this is much easier for the average consumer. Reminds me of the old "virtual hosting" platforms that made it easy enough for your grandma to set up & maintain a website. I like it.

People are quick to condemn GeoCities, but it was a pretty fantastic thing for the world, when you get right down to it. I'm excited to see lots of providers looking at doing similar things for the modern web.

Advice: Link your actual app store/list somewhere. On an app-based platform, most people's first question is "what apps can I run on it?"

I think I saw your thing before at an earlier stage because I'm heavily interested in/messing with Sandstorm.io. There's a lot of stuff you can currently run on this that would not work (yet) on Sandstorm, which is cool. Particularly a game server like Minecraft.

My question is what kind of security is employed to ensure apps are frequently updated, apps cannot interfere with other apps, etc.?

You may want to fix how your Terms of Service is presented. On Firefox, it does not word wrap, and scrolls horizontally... pretty much indefinitely inside that box.

Thanks for the detailed feedback. We used to list apps that we have got working ourselves but we decided it's not a great idea to try to support a bunch of third-party open source apps ourselves. We hope we can encourage the actual developers to let users load their app on Portal, it's pretty simple usually. We definitely need some examples though.

Each app is a separate KVM virtual machine. By default, apps only have access to data they've created, not the data of other apps. Apps can communicate over a private (virtual) "LAN" using private IPs. An app's LAN and Internet access can also be disabled.

Our idea for keeping apps up to date is to replace the entire operating system and app software every time the app VM starts up. For example, restarting an app based on "ubuntu14lts" loads the latest daily release of Ubuntu 14.04 LTS with all its security patches.

The only thing that survives an app restart is the /data drive, with the idea that not even a rootkit will be cleared by a simple restart.

I guess the biggest challenge is, if say, I signed up for this today, would I be able to use it as a non-technical user, if there's no pre-prepared apps to install? And even if other developers are supporting your manifest standard, if you have no central app list, how does someone signing up for your service know what apps are available for it, and where they can get them?

We're hoping we can encourage app developers themselves to support Portal as a platform, and if we can, we will include those apps as "Officially Supported" apps.

You're correct that right now it's really only possible for developers to use. That will change quickly as we get officially supported apps. We're working to make at least a few apps that work for non-developers within weeks. Thanks again!

We're already working with some developers to make personal cloud server apps and really want to encourage more developers to start. There are thousands of apps that need to be written and it's a lot more fun than working in propriety mobile environments!

And it's not just about writing "Portal apps", we want every app that runs on Portal to also run on competing personal cloud server platforms. That's what true decentralization requires.

So, have you looked into how Sandstorm packages files, and whether one of your JSON manifests could be easily added next to a Sandstorm package in order to run it? Or, oppositely, could your platform install an app based on a provided SPK file (and it's own built-in manifest)?

The biggest difference is that it looks like you have people include a script to install the app, and Sandstorm packages the app and all it's dependencies 'pre-installed', and is mostly independent of Linux flavor.

Since Sandstorm packages have all the dependencies and app data in read-only, and all of the user's app data in /var, I would think it'd be relatively possible to figure out how to get the two formats to play nice.

I haven't looked at Sandstorm packages in detail yet. I think it definitely should be possible to make a Sandstorm-runner app for Portal. I've experimented with doing this for Docker. It should also be possible to run a full copy of Sandstorm (or more than one) as a Portal app VM. We'll support any and all standards that emerge.

For now, we're just trying to keep it really simple and the JSON config seems as simple as we can make it. Apps could do a lot more, like include their own OS images or rootfs tarballs if it makes sense.

My thoughts on running Sandstorm in an app on a server that runs apps is similar to my thoughts on running ownCloud on Sandstorm. There's definitely uses, to be able to use features the parent app platform doesn't support (Sandstorm doesn't do everything ownCloud does yet), but running an app platform inside an app platform is sometimes silly. (Though it's probably relatively trivial to run Sandstorm inside Portal Platform.)

Though running individual Sandstorm apps as individual Portal Platform apps is probably also doable, since SPKs contain everything a Linux server needs to run an app. Sandstorm and Portal Platform manifests are pretty similar, and the way the apps are run are similar.

My thought here is just that if your 'install' script can unpack and set up from an SPK file, you might be able to take advantage of some of the apps already being published (currently) exclusively for Sandstorm.

I've been poking around Windows' SDKs to turn iOS and Android apps and stuff into Windows apps, so the concept of this sort of thing happens to be fresh in my head currently. :D

Please post this again when it doesn't come with "Current users of the service should be expect frequent downtime and even data loss during the Developer Release period. "

I think we may have gone overboard with the wording there!

Updated to more accurately reflect the situation:

Current users of the service should expect some downtime and must careful to backup their data during the Developer Release period.

We haven't had any unexpected downtime or data loss with current users, we just wanted to make sure to warn people that they're using something so new. Thanks!

So you want us to pay you so you can test things?

No thanks.

That's fair, but it's not just a test, you can really use it. In fact, our own domain runs on Portal. Our web server and email server are two simple custom Portal apps I created in a few minutes for our own use.

The point of the disclaimer is just to make it clear that we expect there to be some initial hiccups, as with any new service.

No IPv6? Guessing not, as your website doesn't even use it.

Congrats on launching!

We are working on a similar product at Cloudron (https://www.cloudron.io). We use containers instead of kvm.

Thanks. Congratulations to you as well.

This looks like a duplicate of https://news.ycombinator.com/item?id=9040423.

It isn't. We've been working for 6 months since the last submission, it's a completely different version of the web site and service, and we're open to anyone for the first time. We're not launching to the general public yet, we're still just looking for more feedback and help from others on HN.

How is this not 100% in the spirit of Show HN?

We're stricter about duplicates on Show HN than reposts in general. Once a project has had significant attention as a Show HN, incremental upgrades aren't enough to make a new one. It needs to be a different project, or at least have some major difference. Otherwise people use Show HNs for new feature releases or just extra attention, which is not in the spirit of the thing.

Releasing the work to more people (which I assume is what "developer release" means) doesn't count as a new Show HN. It might be a huge milestone internally but doesn't imply a big state change in what people can play with and give feedback on.

However, if this is true:

> it's a completely different version of the web site and service

then it probably qualifies, so we'll take your word on that and put the post back.

You can see our old site and product on archive.org if you have any doubts, everything is different, but it does seem true that our idea of Show HN is not quite what the policy is. We'll make only regular submissions from now on. Thanks for undoing the demotion.

Sure. And I don't mean to discourage you from sharing good work. Think of Show HN as a list of "new things to play with". If the community has already tried out your base service, a repost isn't a new thing to play with (at least not at first sight).

But if it's a new service, or there's something major for people to try that they couldn't have before, that might make a fine Show HN in its own right. In that case the title and the post should present what's new, and it should be more than just an incremental upgrade. That line is admittedly fuzzy, but this is about as clear as I can make it.

The guidelines say that "new features and upgrades" shouldn't qualify for a post, but the separation between "new features" and "new products" is often pretty unclear, and sometimes the same code can be marketed either way. IMO it might be worth expanding on this in the guidelines.

No question about it, but I don't know of a clearer criterion. Any suggestions?

I had seen this before, but yeah, it's been a while and it makes sense to announce a change in status in a new post.

Thank you!

(And no, I do not know ocdtrekkie although I am also an OCD trekkie.)

A new post, sure. A new Show HN, not necessarily.

Reply on news.ycombinator.com