Meteor's new Galaxy and the perfectly Composed companion


Important: The features referred to in this article are no longer available in this form as the Compose platform has evolved to better fit its users. The article has been retained as part of the Compose archive. Please refer to recent Compose articles and the documentation for up to date and relevant information. MongoDB on Compose now has an oplog add-on in a different configuration to the one documented here.

The people behind Meteor, the JavaScript-based platform for real-time responsive applications, have just announced Galaxy, a new way to deploy Meteor applications – sending them up to be hosted in a Meteor-managed, container-based cloud built for Meteor applications.

From the command line, you can deploy your Meteor application to the Galaxy system and then, from the Galaxy web application, you can add and remove containers running your application. The Galaxy platform can spread the user load across them and you can watch the performance from the web applications graphs.

Meteor also knows that hosting databases is a different kind of challenge and have made Galaxy a BYODB (Bring-Your-Own-Database) offering. That's where Compose comes in. We've been hosting Meteor application databases for some time and pioneered offering MongoDB oplog support which energises Meteor's ability to scale up. Our MongoDB databases can automatically scale to address demand for capacity which makes them great for web-based services especially when matched with a service like Galaxy and a platform like Meteor.

We jumped at the chance to try out the Galaxy service to see how we could make the process of moving your Compose-database backed Meteor applications up onto Meteor's Galaxy as easy as possible. At this point you can watch the screencast below or read on.

Connecting Compose and Meteor

At heart, Meteor applications need just two environment variables set to allow it to talk to a database. They are MONGO_URL and MONGO_OPLOG_URL. For current Compose MongoDB deployments, you will find the information you need in the dashboard. Create a MongoDB deployment on Compose, then create a database (say "todos") for that deployment, click into that database and select the Admin view:

The Replica Set URI is what we need. It needs a user name and password to connect to the database. Click on Users and begin to create a user but make sure you select the "W/Oplog Access" option to enable, well, oplog access. Now, if your MongoDB URI is say:


... and you have a user name and password of "galaxyuser" and "galaxypass", you drop those into the URI and that makes your MONGO_URL environment variable:

export MONGO_URL="mongodb://,"  

Important: Put quotes around the value because there's a ? in there, among other things, which a shell will try and translate if unquoted. Now, the next variable MONGO_OPLOG_URL changes at the end of that value you set MONGO_URL to. Take the section after the last /... todos?replicaSet=set-561232e524b9178f98000a2b.

First you need to prefix it with local?authSource=. This is a little database magic that switches where you get authentication from so you can use the user you set up for the particular database. The other change is you remove the replicaSet=... as thats not needed for this URL. That should leave you with local?authSource=todos. Put that back on the rest of the URL and you can now export it:

export MONGO_OPLOG_URL="mongodb://,"  

With those environment variables in place you can now create your Meteor application. With a quick meteor create --example todos you can generate the Meteor todo example; cd into the directory and run meteor and it'll be connected to the Compose database. With this all set up, it's time to send that application to the cloud.

Connecting Compose and Galaxy

Galaxy lets you deploy an application against a domain name. To enable it to do that, you need to set the DNS entry for that domain name to CNAME This is the service that handles incoming Galaxy connections. Once thats done, all we need is a way to pass environment variables up to our application when it's running on Galaxy. This is where the settings.json file comes in – actually it can be any name so you can have production and test settings files. It's not even Galaxy specific; Meteor apps can user settings.json for storing variables and values. In this case, we have none, so we can create one. Here's the template:

   "": {
        "env": {
                "MONGO_URL": ... ,
                "MONGO_OPLOG_URL": ...

Anything within the "" map is used by Galaxy to deploy the application and anything within the "env" map is used as environment variables. All we have to do is drop in the variables we set earlier into this file to give us:

   "": {
        "env": {
                "MONGO_URL": mongodb://,",
                "MONGO_OPLOG_URL": "mongodb://,"

With the file in hand, there's one last step: deploying. Meteor's had deployment to a remote test server since it launched with the meteor deploy command. Galaxy is designed to be as simple to deploy to as that and so it uses the same deploy process with one change. You set an environment variable, DEPLOY_HOSTNAME, to tell it to deploy to Galaxy and give the deploy command the name of your domain and settings. This looks like this for our example: meteor deploy --settings settings.json  

Run that (or at least with your own domain name) and your application will be up in the Galaxy cloud. If you go to the Galaxy dashboard at, you'll be able to add and remove containers to manage the load. With Compose's MongoDB servers handling your data and Meteor's Galaxy handling your users, you'll be ready to scale for all your challenges and all your successes.

Dj Walker-Morgan
Dj Walker-Morgan was Compose's resident Content Curator, and has been both a developer and writer since Apples came in II flavors and Commodores had Pets. Love this article? Head over to Dj Walker-Morgan’s author page to keep reading.

Conquer the Data Layer

Spend your time developing apps, not managing databases.