Meteor deploy with Mup

Background

First, this post is essentially a replacement for an internal email at OpenForm — a practice I plan to continue where possible (more on that later).

Second, for the uninitiated, Meteor is a popular node.js based web development stack: a set of packages and a command line tool for quickly integrating and using those packages in a simple, ideally usable manner. From the documentation on their web site (http://docs.meteor.com/#whatismeteor):

“The key idea in the Meteor package system is that everything should work identically in the browser and on the server (wherever it makes sense, of course: browsers can’t send email and servers can’t capture mouse events). Our whole ecosystem has been built from the ground up to support this.”

Sounds great right? In the future, we hope to possibly use Meteor, as well as many other technologies we continue to explore, in any project for which it is most appropriate.

Rationale

It’s important to keep in mind that one of the main benefits of Meteor from a developer perspective is the ease of deployment. Ideally, if you’re going to incorporate it into your stack, you’d like it to work the same way it does when you read the first tutorial. Everything should boil down to something like typing the following command:

$ meteor deploy myapp.meteor.com

Except in this case of course, we would like it to be something more like:

$ meteor deploy yourapp.openformstudio.com

Done! Unfortunately, I couldn’t find an easy way to do this in the meteor documentation. The workflow they recommend for a self-hosted app essentially looks more like this:

$ meteor bundle myapp.tgz
$ scp myapp.tgz user@yourapp.openformstudio.com:
$ ssh yourapp.openformstudio.com && cd /path/to/app && tar -zxvf ~/myapp.tgz
$ cd bundle/programs/server && npm install
$ PORT=3000 MONGO_URL=mongodb://localhost:27017/myapp node main.js

Yuck! This wasn’t going to work for our team. Enter the meteor-up project (https://github.com/arunoda/meteor-up). By following the docs, we have the following initial setup on the server (where we already have a manually installed meteor app behind nginx — a topic for another post):

$ cd /path/to/app
$ npm i -g mup       # install mup on the server

The next step is for Austin to “mupify” the app he’s already built by typing the following on his machine:

$ cd /path/to/local/git/rep

$ mkdir mupify && cd mupify

$ mup init

At this point, assuming I’ve got write access to the git repo in question, Austin simply has to commit this directory with the rest of the app, I can fill it in, and finally pass an SSH private key to him for future pushes. Once this is done, his future workflow looks more like the following:

$ mup deploy

Much closer to the original meteor model, isn’t it?