When I tell people about my side-project to create a server that makes it safe and easy to run your own web apps, some say I should check out Sandstorm. I was a (small) backer of Sandstorm’s IndieGogo but I’ve been disappointed by how it worked out.

I think the idea of safely and easily hosting your own server-side applications and services is important for the internet to remain free. I thought this then and I still think it now.

Sandstorm is ambitious, and has a lot of good things going for it. However, development and adoption has been slow and the company behind it has shut down.

Some design choices in Sandstorm have made it harder for the platform to thrive. Here is how I see it:

Coerce Old Apps Into A New System

Sandstorm’s “Grains” make it technically possible to run just about any existing application inside Sandstorm, since they are using Linux container technology. But unlike Docker, which also uses Linux containers, apps on sandstorm usually need to be modified.

For example, a web-app on Sandstorm should not provide a login and user management service since the platform provides it. Since most web-apps include this as an essential part of the system, it means ripping it out or somehow bypassing it to work with Sandstorm.

It’s hard work going into an existing codebase to rip out one of its primary elements. Many open source web-apps are old, and old code is even harder to muck about with. Login is just one thing, Sandstorm also has its own data sharing paradigm and apps have to be altered for that too.

Another issue is that developers of typical standalone web-apps assume the app is started when the host starts, and runs continuously until the server needs to be rebooted. There is no reason to optimize startup time, and some apps take seconds to start. However on Sandstorm the grains are only started when the user actively summons them. The result: the user waits.

Not Easy to Create a New App

While it’s work to modify an app to run on Sandstorm, that same container tech makes it intimidating to create an app for Sandstorm in the first place. Have a look at this page that explains how do get started with a simple PHP app. Yikes! It’s Ok if you’re regular container slinger, but otherwise it seems kind of steep.

Sandstorm’s approach puts it in an odd spot: while it has the advantage of being able to run almost any app thanks to its container tech, it’s a lot more work for devs to make their web-based application code run on Sandstorm than on Docker (or any other container runtime), so few have done so. But it’s also hard to create an app from scratch.

So, steep hill to climb if you’re forking an app to run on Sandstorm and steep hill to climb if you’re creating one from scratch. As a result, Sandstorm’s app market had a very modest number of apps, most of which were a few (or many) releases behind their source, some of which were slow to start, and in my experience had a few bugs. Populating an app store for a new platform is always a hard problem, but Sandstorm’s design made it even harder.

Not Really Good At Services

This one is the kicker. Sandstorm works well with applications that you tend to sit in front of. It’s not great for situation where you regularly serve dynamic requests. See this page (the section at the bottom titled “Why only static content”).

Sandstorm also has an issue with URLs that are not clean looking, and hooking up a service to a nice sub-domain is still eluding the platform, apparently. It’s hard to feel like your service is “of the web” if it can’t simply be connected to a clean domain.

To me the very essence of an online service is to serve dynamic requests. Quite possibly a lot of them, coming from many different clients at any random time with potentially different authorizations. Services should be reachable at a nice clean URL, respond quickly even if not used often, not bring the host to its knees if under some load, and take up almost no resources when not in use.

The Future of Self-Hosting Web Apps

There are other pain points for Sandstorm: the user interface, the unfamiliar and complex concepts for users, etc… Some of this is typical of a very ambitious project: niceties like the UI and making it simple are left for later. This discussion illustrates a few of these problems, along with a large number of comments from people who were justifiably saddened that Sandstorm was not taking off.

Sandstorm is still evolving as a community project and may yet gain enough speed to take off. I certainly am not writing it off. But I think there is room for other approaches, with different trade-offs and different priorities.

This was post 19 of the #100DaysToOffload challenge.