Meteor-Station

edit: I have just been made aware of pm2 (thanks to pchoo on IRC's meteor chan). Seems like a robust mup alternative.

Meteor-Station is a highly configurable and flexible deployment solution for Meteor. Since mup is no longer maintained, the Meteor community was forced to move to mupx. However mupx uses docker, and this technology choice should not be forced onto anyone.

Installation

npm install meteor-station -g

Configuration file

The configuration file is rather similar to mup's, but please save it in mstation.json:

{
  "servers": [
    {
      "host": "XX.XX.XX.XX",
      "username": "root",
      "pem": "~/.ssh/id_rsa"
    }
  ],

  "appName": "myApp",

  "app": "/Users/me/dev/myApp/",
  "settings": "/Users/me/dev/myApp/settings.json",
  "env": {
    "ROOT_URL": "http://myApp.com",
    "PORT": 3335,
    "BUNDLE_PATH": "/opt/myApp",
    "MONGO_URL": "mongodb://@localhost:27017/myApp"
  },

  "deployCheckWaitTime": 15
}

Speed-up

Meteor-Station provides a significant speed-up by not tarring the bundle. It also allows to not bother with the backup / rollback mechanism which once again brings down deployment times significantly.

The whole advantage of using rsync is lost with syncing a tarred archive; internally mstation uses rsync azv <source> <target> --delete which only transfers what has been updated, and removes anything from the destination which no longer exists in the source. In other words, it's fast, and better.

Example usage

n.b feature not yet checked in

$ mstation init

Creates the default configuration file for meteor-station.

$ mstation

This command looks for settings.json in the pwd, and performs all required steps to get your project deployed and running.

$ mstation --settings staging-prefs.json --config staging-server.conf

Say you have various servers, i.e for staging, testing, production etc. the --settings and --config flags enable you to run mstation with different configs.

n.b feature not yet checked in

$ mstation --backup false

This skips the step of creating a backup of your project on the target servers. This means rollback is impossible in case deployment fails, but it provides a significant speedup.

$ mstation start

Start the Meteor Application

$ mstation stop

Stop the Meteor Application

$ mstation restart

Restart the Meteor Application

$ mstation logs

Tail -f the logs for this Meteor Application

Running custom deployment steps

n.b feature not yet checked in

mstation allows you to add your own deployment configuration steps. This is because every version of meteor, on every target may have different setup requirements.

For example, when installing from OSX, bcrypt is binary incompatible and needs to be rebuilt. Fibers, and a whole host of node packages need to be installed too, and some packages need to be removed from the bundle.

Trying to cater for all these scenarios doesn't make sense. Instead, simply add your own 'custom-deploy-steps.sh' (for example) script, and point to it with:

mstation --custom custom-deploy-steps.sh

Which will allow you to make any required modifications to the installed bundle for it to work.

Understanding the deployment pipeline

The best way to master your Meteor deployments is to thoroughly understand the deployment pipeline. It's really not the complicated, and once understood, you'll better be able to diagnose and fix your own issues without having to depend on third parties.

Step 1: the build

The build step consists of nothing more but:

meteor --build /tmp/build

Step 2: generating scripts and configuration

ETC.