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.
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.
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.
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.
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.
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!
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.
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.
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.
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
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!
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.
We are working on a similar product at Cloudron (https://www.cloudron.io). We use containers instead of kvm.
How is this not 100% in the spirit of Show HN?
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.
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.
(And no, I do not know ocdtrekkie although I am also an OCD trekkie.)