By Kenton Varda - 14 Jan 2015
When using Sandstorm’s upcoming managed hosting service, your resource usage will be limited in two important ways:
So, what exactly are compute units? Technically speaking, a CU can also be described as a “gigabyte-RAM-hour”: using a gigabyte of RAM for one hour consumes one CU. Or, alternatively, using 100 MB of RAM for 10 hours, or using 10GB of RAM for six minutes, is also one CU.
Practically speaking, think of your CU quota like the battery on your phone. Some apps, when they are running, use more CU than others. Sandstorm aggressively shuts down apps when they are not in-use, so apps will only consume CU when you are actively using them (e.g. when you have them open in your browser). As a rule of thumb, we find that many apps use about 1 CU for every 5-10 hours of active use. Some apps – especially ones with servers written in ahead-of-time compiled languages like C++, Rust, or Go – may use far less, while particularly inefficient apps may use a bit more. You will be able to check your CU level and see which apps are using it by clicking the CU indicator in the top bar.
Note that when you use an app to publish a web site to a separate domain – such as Ghost or WordPress – Sandstorm caches the page content and serves it statically. Therefore, the app does not start up and does not consume CU when a guest merely visits your site; CU is only used if the visitor does something that changes the site (like leaving a comment) or when you open the app’s administrative interface.
For our managed hosting service, you will receive a monthly CU allowance. Those who sign up for the “standard” plan (currently slated for $6 / month) will receive 200CU per month. That equates to 1000-2000 hours of using a typical app, which is more time than a month actually has! We expect that most users will never come anywhere near hitting their CU quota.
But what happens if you do hit your quota? We said your CU is like a battery, but it’s like a battery that is always charging. When you first create your account, your CU battery starts out full. When it is not full, it recharges at a rate such that over the course of a month it will recharge equal to your monthly limit. So if you run out of CU, go take a walk, and when you get back you’ll have some more. And if you run out often, consider upgrading to a larger plan. :)
By Asheesh Laroia - 12 Jan 2015
I’ll be in the Boston area next week, and I’ll be organizing a web app self-hosting meet-up on Tuesday, Jan 20, from 7:30pm to 9:30pm at Clover Harvard Square. If you’re in town, I hope you can escape the cold and come by! First beverage (beer/hibiscus lemonade/iced coffee/etc.) is on us. Please RSVP for free here!
If you’ve read this far, you might appreciate the following personal note:
I used to live in the Boston area, so it’ll be nice to see old friends and meet new people as well. If you haven’t heard of Sandstorm, but you care about personal servers or self-hosting, then I’d love to meet you.
In 2009, I once knew that the authors of a web application I used a lot, and had complicated feelings about, were coming to town. I read an announcement just like this one, and I thought, “Whatever, those people are too fancy to want to talk to me.”
I should have gone. And you should come to this one. RSVP here.
By Asheesh Laroia - 07 Jan 2015
I’m Asheesh Laroia, and I’m excited to say I’m joining Sandstorm as a member of the technical staff.
For most of my career, I’ve worked in open source: I’ve been a software engineer at Creative Commons, and I co-founded OpenHatch, a non-profit that helps people get involved in open source. I got my start in open source by reporting a bug against a Linux filesystem check tool, made my first visible contribution in 2003 when I created the Xbox-Linux wiki, and I mentor others as a Developer in Debian. I did a one-year stint in web startup-land to hone my security knowledge, and now I find myself in the coolest possible position: working at Sandstorm on tools and community to build the easiest, most secure system ever to run a personal server.
Personal servers mean a lot to me. I’ve been running one since 2001; in 2006, I found a way to move it out of my parents’ basement into friend’s apartment in Tokyo (that’s another story). I’ve been through it all – RAID failures, difficult package upgrades, and getting compromised – for the pride of knowing I’m running my own real Internet site, so it’s amazing to be working on Sandstorm’s mission of creating the easiest way to run a personal server.
I first heard about Sandstorm when Kenton visited San Francisco to discuss it with me and get my feedback. We talked about about what Sandstorm can learn from efforts like Freedombox, and I was impressed to discover that the Sandstorm vision seemed to be ahead of my own thinking. So last summer, I came to the Sandstorm Hackathon (app port-a-thon), and rather than port an app, I added a Vagrantfile to make it easier to port apps to Sandstorm from a Mac. You might have seen me talk about it in the video for the Indiegogo campaign.
Sandstorm’s mission has two pillars: the codebase, and the community, and I’m lucky to be working on both. As my first act, I’ve given us an IRC channel. Come find me in #sandstorm on freenode as “paulproteus” – ping me about parts that need improvement, or about how to get involved. If you already have a client, great – join in! And if you don’t, visit us via this web chat link and say hello! I’m looking forward to meeting all of you.
By Kenton Varda - 15 Dec 2014
Cap’n Proto is an open source serialization and RPC protocol being developed as part of the Sandstorm project. Today, we’ve released version 0.5 of Cap’n Proto with lots of goodies, including new features like generics and support for additional compilers and languages like Visual C++, Java, and C#. Much of the work comes from a large number of awesome open source contributors.
So, what does this have to do with Sandstorm?
Many developers are excited by Cap’n Proto for being “like Google’s Protocol Buffers, except infinity times faster”. When it comes to Sandstorm, though, the design of Cap’n Proto’s RPC system is far more important than the speed of its encoding. Sandstorm is a capability system: applications can send each other object references and address messages to those objects. Messages can themselves contain new object references, and the recipient implicitly gains permission to use any object reference they receive. Essentially, Sandstorm allows the interfaces between two apps, or between and app and the platform, to be designed using the same vocabulary as interfaces between objects or libraries in an object-oriented programming language (but without the mistakes of CORBA or DCOM). Cap’n Proto RPC is at the core of this.
This has powerful implications: Consider the case of service discovery. On Sandstorm, all applications start out isolated from each other in secure containers. However, applications can (or, will be able to) publish Cap’n Proto object references to the system representing APIs they support. Then, another app can make a request to the system, saying “I need an object that implements interface Foo”. At this point, the system can display a picker UI to the user, presenting all objects the user owns that satisfy the requirement. However, the requesting app only ever receives a reference to the object the user chooses; all others remain hidden. Thus, security becomes “automatic”. The user does not have to edit an ACL on the providing app, nor copy around credentials, nor even answer any security question at all; it all derives automatically and naturally from the user’s choices. We call this interface “The Powerbox”.
Moreover, because Sandstorm is fully aware of the object references held by every app, it will be able to display a visualization of these connections, allowing a user to quickly see which of their apps have access to each other and even revoke connections that are no longer desired with a mouse click.
Cap’n Proto 0.5 introduces primitives to support “persistent” capabilities – that is, the ability to “save” an object reference to disk and then restore it later, on a different connection. Obviously, the features described above totally depend on this feature.
The next release of Cap’n Proto is likely to include another feature essential for Sandstorm: the ability to pass capabilities from machine to machine and have Cap’n Proto automatically form direct connections when you do. This allows servers running on different machines to interact with each other in a completely object-oriented way. Instead of passing around URLs (which necessitate a global namespace, lifetime management, firewall traversal, and all sorts of other obstacles), you can pass around capabilities and not worry about it. This will be central to Sandstorm’s strategies for federation and cluster management.
By Kenton Varda - 05 Nov 2014
Today we have a few announcements regarding Sandstorm and mobile.
First, we’ve updated Sandstorm’s web interface to be mobile-friendly. Whereas before the UI was mostly unusable on mobile, now you should be able to get around reasonably well. Not all of our apps are optimized for mobile, but at least now that the Sandstorm shell works well, apps can follow.
Second, we’ve implement the ability for applications to export HTTP-based APIs, which among other things can be used to allow a mobile client application to access a Sandstorm-based server. To learn how to make your own application export an API, check out the documentation.
As an example of the new functionality, we’ve updated our port of TinyTinyRSS to support an Android client. Install the latest version of the TinyTinyRSS app and check out the preferences to learn more!
We’ve ported Telescope – a Reddit / Hacker News clone – to Sandstorm; find it in the Sandstorm app list now. Being a Meteor app, Telescope was, of course, easy to port using meteor-spk.
We are using Telescope to power the Sandstorm app committee voting app, where those people who purchased seats on the app committee during our Indiegogo campaign have been voting on the next apps for us to port. So far, they have chosen Gitlab and Diaspora.
Want to follow the action? Visit the app committee group.
We’ve updated the Groovebasin app to allow batch uploads of multiple songs. (This was previously disabled due to a limitation in Sandstorm, which we’ve now fixed.) Re-install Groovebasin from the Sandstorm app list to get the update. Now you can upload your whole music library more easily!