Deploying Meteor Apps to Cloud Foundry

Recently, I was playing around with Meteor to test out how our Cloud Foundry deployments would handle web socket connections from client browsers. For those that haven’t seen Meteor before, Meteor is a platform for building web and mobile applications that get updated automatically when changes are made through other clients. For instance, if our application has cards that move between columns on a Kanban board and someone else moves a card in their browser session then the card would also move in my browser if I had it open at the same time the event occurred. Meteor uses MongoDB as its data persistence layer and so our Cloud Foundry environment had have MongoDB available as a service in the marketplace.

The Cloud Foundry Meteor Buildpack

When I started there wasn’t a de facto Meteor buildpack that worked with Cloud Foundry, at least that I could find. I did find a Heroku Meteor buildpack which provided many of the pieces needed to update for Cloud Foundry Meteor application deployments. I originally forked the repo but then created a new repo with a name that declared the buildpack as being Cloud Foundry oriented. You can check out the Cloud Foundry Meteor buildpack repo at The major changes that were need for use with Cloud Foundry had to do with where the MongoDB and root URL environment variables, necessary to be set for Meteor to start application successfully, were being pulled from. In Cloud Foundry these are pulled by convention from the VCAP_SERVICES environment variable rather than setting configurations from the command line in Heroku.

Creating a Meteor Application

You can install the Meteor binaries using the following command:

curl | sh

Once installed, creating your first example Meteor application is as simple as running the following in the directory of your choice:

meteor create --example todos

You can change the name of your application from “todos” to something else if you’d like.

Deploying a Meteor Application to Cloud Foundry

Now that we have an example Meteor application, lets push it to a Cloud Foundry environment. In order to push our application we will need to be logged into a Cloud Foundry environment. We will use the Cloud Foundry CLI to login and push our application. Here is how I do this in our Cloud Foundry environment:

cf login -a -o myorg -u csterwa

And after I put in my password I’m logged in. We can now use the Cloud Foundry CLI to push our application. First, lets create a MongoDB instance for our persistence layer that our Meteor application will bind to and use.

cf create-service mongodb default todos-mongo

We named our MongoDB instance “todos-mongo”. We can now create a file called manifest.yml in our Meteor applications top level directory with the following contents:

- name: todos
memory: 512M
- todos-mongo

This manifest is setting the name of the application to todos and reserving 512 MB of memory for the application to use. It also tells Cloud Foundry to use the Cloud Foundry Meteor buildpack to bundle up the application for running on Cloud Foundry. And finally, bind to a service named todos-mongo, the name of the MongoDB instance that we just created. With this manifest.yml file created in our top level Meteor application directory, it is now time to push our application to Cloud Foundry.

cf push

Since we have the manifest.yml we don’t need to send any arguments to the Cloud Foundry CLI push command. It should now be uploading our application files, building a deployment package, binding the application to our MongoDB instance and then starting the application. When it is finished it will say “App Started” and provide a URL to access the running application. In this case it would have been assuming my default domain was “” in this Cloud Foundry environment. You should now be able to open up multiple browser windows to the URL provided and see changes in one show up on the other.

I’m looking forward to hearing from others on their experiences deploying Meteor applications using the Cloud Foundry Meteor buildpack. If you have any feedback or issues please add to the issue tracker on the Github repo at

Published by

Chris Sterling

Chris Sterling is Global Director of DevOps and Cloud Practices at Luxoft (, a 10,000+ person, $2B global technology solution provider with approximately 200 employees in the Pacific Northwest. Chris has an extensive technology, product management, process, and consulting background. Chris published the book Managing Software Debt: Building for Inevitable Change with Addison-Wesley in 2010 to provide a framework for teams and organizations to assess and manage debt in their software systems. Chris was a Certified Scrum Trainer with the Scrum Alliance for 8 years and taught thousands of people about how to apply Scrum effectively. Chris has successfully supported organizational transformation across multiple verticals with organizations of 10 up to 800 people. Chris co-founded a company in 2009 called Agile Advantage focused on solving portfolio management problems to leverage the value that Agile teams can deliver, which lead to a successful acquisition by Rally Software. He has spoken at many conferences and user groups on topics such as continuous delivery, software architecture, technology management, Lean and Agile processes, and Lean Startup. Chris has taught the “Advanced Topics in Agile Software Development” class at the University of Washington in the Agile Developer Certificate extension program. Chris brings his diverse experience and deep passion for technology when discussing topics such as Continuous Delivery, Cloud Native architecture, DevOps, Lean and Agile. Follow me @csterwa or get LinkedIn with me at