Where is the Best Place to Host my Web App

Code in the Google Apps Script editor

Web Apps are apparently the future. And why not? Browsers have become full fledged virtual machines capable of running powerful Javascript applications, and HTML and CSS have both evolved to include a lot more than just text and pretty colours.

One of the main reasons I’m looking into this is because I’ve made several unsuccessful attempts to build a couple simple web apps using Google Apps Script on Google Drive. Based on the documentation and the marketing it should have been simple enough. But I always ran into the same roadblock: Caja! Google uses Caja to sanitize (or cajole) your scripts and prevent any malicious activity on Google’s network. But running within a Caja sandbox is a whole new world where libraries don’t behave the way they should, standard features are blocked, and you need to use tricks for things that should just work.

There are four categories of web app hosts:

  1. Un-intentional hosts are services that aren’t really built for hosting web apps or pages but can work that way;
  2. Dedicated app hosts are services that are designed specifically for hosting web apps and provide some or all of the back-end infrastructure to support them;
  3. Generic web hosts include shared hosting, VPS, Paas, and Iaas;
  4. Browser hosting, since these days every modern browser (so not Internet Explorer) can host some kind of web app.

The focus is Dedicated app hosts since there’s not much to say about the Un-intentional hosts (actually it turns out there is) and far too much to say about the others.

Un-intentional hosts

The best known of this group are Google Docs and Dropbox. Both have officially documented methods for hosting publicly accessible HTML, CSS, and JS files. But the solutions are kind of kludgy, and if your single-page app (SPA) goes beyond a single page they go from kludgy to bizarre. Tools like Neutron Drive help, but this not the place for a serious web app.

Note that both Google and Dropbox offer data storage services that are entirely separate from the methods of hosting your web app. And only Dropbox offers a Javascript library for data in a generic web app; to access Google’s data storage from a web app you’d have to roll your own requests and response handlers.

In fact, the Dropbox Datastore service could almost make it into this review except that it doesn’t explicitly provide hosting for your web app – although you could do that with the Public folder in your Dropbox account, but it’s not an integrated solution, unfortunately. But the Datastore service is interesting since it also provides an Own Your Data solution for your users.

Google Docs does let you write web apps using Google Apps Script but since they run in a Caja container they’re handicapped in some pretty annoying ways (as I’ve said before, and will say again).

Generic hosting

Either a shared host, your own VPS or IaaS, or a PaaS will allow you build the back-end and host your front-end files. But a lot of work will be up to you and can require a lot more effort to get your actual web app going. If you’re using Google’s App Engine (as a PaaS) then the Tailbone project might interest you.


Not exactly web apps, but an interesting possibility. Browser apps are built with the same technology and they can leverage both local and remote back-ends (sometimes simultaneously). But they need to be installed locally before you can use them so they aren’t instantly available everywhere.


These services are designed specifically for serving up web apps and their back-ends. They aren’t equal though, and some might be better suited for your needs than others. The list includes services like BackendlessBackliftBuilt.ioFirebaseMeteorParse, and 5apps. Unfortunately the list excludes Stack Mob since they’re closing the service.

The biggest issue for web apps is having to access data from the same domain as you load your original containing page. There are ways around that, most recently CORS, but it’s probably the biggest hurdle developers face when building web apps. So a key element to differentiate a web app service from a mobile or other BaaS (Backend-as-a-Service) is whether they allow you to host your application as well as the data! This distinction is crucial in understanding the limited list of services below.

All these services provide at least these three features:

  • Asset hosting and serving, so that’s your HTML, Javascript, CSS, images, etc. but limited to a reasonable amount;
  • Templating, so that the assets you serve can be made dynamic; and
  • Data storage for your structured data (typically JSON objects) but sometimes file storage too.

A lot (maybe even all) these services use Node.js as their backend, which makes sense considering everything is now Javascript. But it does explain why some things are so similar; and make you wonder why somethings aren’t available sometimes.


The most interesting thing about this service is it implements the remoteStorage protocol so that means your users Own Their Data. It also focuses on helping you deploy your app in a variety of environments, including mobile and browsers. Their hosting and deployment service is completely separate from their data storage service, but together they are a very interesting app hosting service. A little light on documentation, but they are still evolving.

  • Hosting & serving: your code is pushed to 5apps via git, and you can use your own domain.
  • Templates: There are no templates or server-side scripting so the assets served are all static.
  • Data storage: 5apps data storage is a separate service based on the remoteStorage protocol.
  • Pricing: free during development, and then starting at $5 per month for hosting; currently the only data plan is the free one.

An interesting side effect of using the remoteStorage protocol is that once users start using the app they have to find their own storage. That could be by creating their own account at 5apps or another provider (including hosting their own remoteStorage back-end).


This is one of the big names, and targets primarily mobile environments but provides hosting for web apps too.

  • Hosting & serving: all your content is uploaded via the parse command-line tool, and you can use your own domain.
  • Templates: templates are based on the Express framework.
  • Data storage: the Parse SDK is built on Backbone.js and allows you store and retrieve Javascript objects.
  • Pricing: free during development, and then starting at $199 per month.

I have nothing against Parse itself but I don’t trust Facebook with my data so I’m immediately suspicious of Parse. Sorry.


Offered as both a service, and an open-source Node.js module that your can host yourself. At the moment it is still in beta, or preview as they call it. And Their level of documentation and helpful examples is very impressive, and their community is quite large.

  • Hosting & serving: you push your app’s assets to Meteor using the meteor command-line tool, using a sub-domain of meteor.com or your own custom domain (or your own installation of Meteor).
  • Templates: templates are generated using the Handlebars inspired Spacebars language.
  • Data storage: storage is based on MongoDB and synchronization between the client and the server.
  • Pricing: I couldn’t find any information about Meteor’s pricing at this time.

A big focus for Meteor is publishing your data to all clients as it changes. So it’s very well suited for apps where more then one client will access the same data, in particular collaboration or social sharing


Although the Firebase service for real-time data storage and synchronization is in full production, their service for hosting is still in beta.

  • Hosting & serving: currently still in beta but it works with a Node.js based firebase command-line tool to manage your app and serve it from a firebaseapp.com sub-domain.
  • Templates: no template language is currently available, all the assets are static.
  • Data storage: Firebase stores and propagates in real-time Javascript objects.
  • Pricing: free during development, and then starting at $49 per month.

The most exciting thing about Firebase is that they’ve developed some comprehensive guides for working with popular client-side frameworks, including Angular and Ember. So if you’re using one of those frameworks you’ll have an easier time integrating with Firebase as a back end.


Is marketed towards the mobile app developer crowd, with support for web apps.

  • Hosting & serving: you can upload your static assets and server side extensions in a ZIP file, and host them from a built.io sub-domain or your own custom domain.
  • Templates: there’s no template language in built.io.
  • Data storage: is stored as Javascript objects and be integrated with Backbone.js if desired.
  • Pricing: free during development, and then starting at $99 per month.

Their focus seems to bigger enterprises, they’re the second most expensive service here,


Backlift has two pretty cool features: it uses Dropbox for deployment and the data API is designed to work with Backbone.

  • Hosting & serving: your web app assets are taken directly from Dropbox so to deploy simply copy (or directly edit) the files in your local Dropbox and let the magic happen.
  • Templates: Backlift offers a very powerful template language for developing dynamic web pages.
  • Data storage: data is stored as Javascript objects, but Backlift offers a lot of control over how it’s organized and accessed.
  • Pricing: there doesn’t seem to be any pricing information.

The Backlift service seems pretty cool, and they’ve done some really cool things with all the different integration they’ve implemented.


Backendless is another mobile-focused service that provides web app hosting as a secondary service.

  • Hosting & serving: web app assets are uploaded  to the /web folder via the web interface, API, or optional git integration.
  • Templates: there are no templates or dynamic content possible.
  • Data storage: it’s a bit of an odd API since objects have to have explicitly created constructors before they can be saved and accessed.
  • Pricing: a basic free plan is available, but then all aspects can be fine tuned so the price is extremely variable.

Backendless provides a complete range of back-ends for building applications, but they seem a bit light on web apps.


When you initially decide to write a web app you take on the task of designing, developing, testing and documenting (hopefully) your work. But once it’s up and running you need to handle the volume and data being stored. Dropbox and remoteStorage neatly solve the data issue since they make it the users problem. In terms of hosts the biggest difference is the price and the API. So it’s really a question of what you can afford and what your style is.

If you’re building the next big thing then you probably want to use one of the established dedicated hosts like Parse or Firebase. They’re both production ready, well documented, and have a good community. Personally, I think Backlift and 5apps are the most interesting.

If you’re a hobbyist building something for yourself and a few other people then you’re best bet is probably cobbling it together on Dropbox or Google Drive. There aren’t any other questions about volume, storage, or pricing because they just don’t exist. And both these platforms are big enough you’ll only see them get better rather than drastic changes or disappear completely. And you, and your audience, probably already have accounts there so it’s one less thing to worry about.

Cross-posted on Schultzter’s Blog