The MEAN stack blog

Installing on Heroku

Installing on Heroku is incredibly fun, easy, fast and troubles free.

In this short tutorial I’ll walk you through checking out, connecting it to Heroku, and using an 3rd party MongoDB provider (MongoHQ in this case).

First thing first, you’ll need to create accounts on both Heroku and MongoHQ. Creating an account on both services is a matter of minutes all together.

1. Heroku

In order to work with Heroku, you also need to download Heroku’s toolbelt which will give you the needed command line tools to communicate with Heroku’s backend. Right after registering in Heroku and installing it’s toolbelt, run the following command and add your SSH key, to identify yourself with Heroku:

$ heroku login
Enter your Heroku credentials.
Password (typing will be hidden): 
Found the following SSH public keys:
Which would you like to use with your Heroku account? 2
Uploading SSH public key /Users/zohar/.ssh/ done
Authentication successful.

2. MongoHQ

Once you are done with creating your account, proceed to adding a new DB. MongoHQ chose their biggest and most expensive package as default, but for the sake of this example, I chose a free AWS Sandbox. A few seconds later you’ll be redirected to the DB’s dashboard, where you should add a user and password with which to access the DB. Note that these credentials are different than the ones you registered with and need to be manually created.

MongoHQ > Add a new DB user

Go to the Admin tab on the left, then to Users, and add a user: MongoHQ - add users

MongoHQ > Get the connection string

Go back to the Admin > overview tab, and copy the connection string (username and password are masked): MongoHQ - user and password You’ll need this connection string later in the process.


Your next move is to prepare your MEAN application: If you don’t have an app yet, get a fresh copy of from Github (git clone or download the .tar.gz or .zip files). If you already have a ready made app, or after you have downloaded, your next move is to change the MongoDB connection string in the app.

Before you go ahead, just make sure your app sits on a git repository. If it isn’t, run this from the directory:

git init
git add .
git commit -a -m "Initializing my new app repository"

The connection string to be changed is found in the configuration files under config/env. By default, is delivered with three environments: development, test(ing) and production. The different configurations allow for easy development and deployment, without the hassle of changing config files each time. For our example, we’ll consider Heroku as production. Therefor, we need to edit the file config/env/production.js, and insert the MongoHQ connection string from earlier:

/var/www/mean-on-heroku$ cat config/env/production.js

'use strict';

module.exports = {
    // Replace <user>:<password> with your real user:pass
    db: "mongodb://<user>:<password>",
    app: {
        name: "MEAN - A Modern Stack - Production"

Then git commit your changes.

4. All together now

Once the connection string is changed, you’re ready to push changes to Heroku:

/var/www/mean-on-heroku$ heroku create mean-on-heroku

This command creates an app on Heroku, and adds a remote git origin called heroku, to which you need to commit your changes hereafter. This is the response of the command:

Creating mean-on-heroku... done, stack is cedar |
Git remote heroku added

To get Heroku to respect our grunt magic – we need to reference the a slightly altered node buildpack which supports grunt

heroku config:add BUILDPACK_URL=

Note the remote heroku origin, and the URL the app. You’ll need it later to see your app in action. Next step is to push your changes to heroku:

git push heroku master

When you push the app to Heroku it automagically identifies is as a node.js app, and will run the necessary npm install on the server. The very last thing to do is to let Heroku know that it needs to look for it’s configuration not in the default environment, but in the production one. This as well is done via the local toolbelt from the command line:

heroku config:set NODE_ENV=production

…And that’s about it! Your app is live and running on the above URL (in my case:!/ although don’t expect this URL to be functional as it’s only a test one…).

To wrap it all up:

Within minutes you can have a functional MEAN stack ready for development or production. The whole process takes only a few minutes. Really – reading this post should have taken you longer…



I have been doing open source since 1999 but this is the first time that I’ve seen this kind of adoption, passion and care for anything I’ve been involved with.

Amos is doing an awesome job leading the work on – tranforming our best practices, inisghts and experience to installable, stable and elegent code you can clone and use to adopt our way of creating MEANinfgull software.

We’re getting a growing number of pull requests to the project and Amos has been merging alot in. This is great news because you guys (and gals) like the platform and are contributing back. The bad news is that some really cool things do not make it in. We want to ensure that the core is as small, elegent and fast as possible and that the code is of the lowest common denominator which fullstack js developers need.

Another issue we’ve noted was the community’s need to understand where we are going and why…

We want the develpers to keep contributing and help us grow and extend build the stack so given the above…


If we build a modular architecture with a clear and solid api for module invocation and inclusiong -we’ll let the developers contribute and share functionalities, practices, directives, services and more. So assuming we build these mean modules we’ll understand that…


I’ve played a bit with a cli and one of the first commands will be mean install $MODULENAME which will let us install these modules.

Once these modules are installable we’ll inevitebly reach another challange – how would you get the modules??


A repository that can store them and that will provide a meta dependency both for server and clientside dependencies.

These are the main things we’ll be working on – I hope this will provide a way to contribute modules, share practices and provide a way to extend and grow