Heroku starts getting really expensive once you leave that free tier. It's not just the bare Heroku service that is costly, the addons as well are very pricey.
When your deploy fails you see a legitimate error log. Many of the other PaaS give you nondescript messages and debugging is a pain. Debugging Heroku wins by comparison.
Getting started with Heroku is very easy. It's a very straightforward procedure and a beginner can set up their first app in two minutes. Often it's just a matter of a couple of git commands and it's all set up and running. The official Heroku docmentation also helps a lot.
Heroku offers a free tier which contains a single dyno instance and is available for up to 18 hours per day. It offers 512MB of memory and 100MB swap space.
Heroku instances can easily be scaled up or down by increasing or decreasing the number of available dynos for that instance. This can be done through the CLI or through Heroku's web UI.
Heroku has a vast list of plugins and services that can be added to an instance. These plugins cover things from databases to email systems. This remove the task of having to install services and setting them up manually. Heroku does it all for you.
Heroku is one of the oldest PaaS providers. The fact that it's been around for such a long time means that it had a lot of time to mature over the years. There's also a massive number of articles, guides and tutorials on Heroku out there for beginners and advanced users.
While starting with Heroku is fast and easy, and the first few deployments are actually very fast, larger applications tend to have slower deployments. It takes some time for the dynos to restart and while they are restarting the application is completely offline. Which means that you can lose precious seconds of application time.
If you want to fully customize your production environment, then Heroku can be seriously constraining. Installing libraries or services can not be done unless there is already a Heroku plugin for it.
Limits are based on total memory allocation, you can allocate as much RAM as you want for each instance. Even the pricing is based on the total amount of RAM allocated, $0.04/GB.
While it's true that AppFog may be relatively new and the online support is not very extensive, they offer 24/7 professional live chat support for any questions or problems you may have.
The deployment process with AppFog is generally nice and easy because of its CLI. Unofrtunately the only downside of that process is the fact that it takes too long. A deployment to AppFog genereally takes up to 40 seconds, which should be fine if you are deploying once a week, but when you deploy every hour it starts bothering you too much.
Most other PaaS providers only allow for multiple, low-memory instances for horizontal scaling, but dotCloud also allows for vertical scaling and resource-heavy applications by adjusting per-instance memory availability.
dotCloud is usually very fast when it comes to deploying your project. The CLI tool is very good at that and deploys your build almost as soon as you push it.
When your databases have a very high write volume dotCloud starts having some serious problems keeping up with it. Performance drops completely and in the worst case scenario the database crashes and starts going down daily.
There are a number of ways available to contact their support team (email, twitter, IRC and even through phone). They usually respond very fast even to emails and the responses are very friendly and helpful.
Modulus has a tool called demeteorizer which takes a standard Meteor application and turns it into a regular Node application so that it can run on Modulus.
The deployment process in Modulus can be slow depending on the size of the project. On every deploy the whole application is bundled (except node_modules and deployed to Modulus. Since it doesn't use something like git it has to upload every file on each deploy instead of "diffing" them.
There's a free plan which provides you with up to 10 free apps hosted on each datacenter, albeit with some restrictions on hard disk size, CPU and RAM.
It's very easy to scale up or down your app in Azure. You can either scale the CPU or RAM according to your needs. There's even an option for autoscaling which lets Azure itself choose when to scale up or down depending on traffic.
Other than plain-text JavaScript files (which are the majority), modules can also be platform-specific binary images which are compiled at install time, usually by Python or node-gyp.
Since Azure services run on a Windows-based system, for native modules to work they need to have been installed and compiled on a Windows development system. This prevents you from using some modules which have very specific requirements. But the most popular ones (like MongoDB) are able to run just fine.
Firebase hosting is only for uploading and hosting static assets (JS, HTML and CSS files). If you want to build a full-stack app with a backend framework running your custom commands, you can't host it on Firebase.
The content is deployed immediately through the Firebase CLI. Once it's uploaded, the content is served immediately. If you have made a mistake, you don't need to re-upload a new version, through the Admin dashboard you can easily rollback to a previous version.