Deploy guide

Learn how to deploy an application to Galaxy with these detailed step by step instructions.

Galaxy makes it simple to deploy, scale, and monitor your Meteor application. This guide provides detailed step by step instructions for deploying your application to Galaxy.

This guide will cover:

  • Setting up MongoDB
  • Specifying Meteor application settings
  • Setting the hostname
  • Using the Meteor CLI tool to deploy the application
  • Configuring domains and SSL Encryption for the application

Sign up for Meteor Cloud

You will need a Meteor Cloud in order to access and deploy to Galaxy Hosting. Sign up here for a new Meteor Cloud Account. Once you have created your account, you automatically have access to Galaxy. Depending on the region you want to deploy your apps to, go to the URL and sign in with your username and password. For US East, use For EU West, use For Asia-Pacific, use The region you deploy to will affect the URL of your dashboard. If your username is devname, you’ll see your US East apps at, your EU West apps at, and your Asia-Pacific apps at You may also use the Free plan on Meteor Cloud to deploy your app (You must have Meteor 2.0 installed). There are no costs associated with this plan and it comes with a free pre-configured shared MongoDB instance. However there are some important limitations: Free plans are limited to 1 Tiny Container, must use a Meteor domain name: to US region, to Asia region, or to Europe region and have cold start enabled. For more information on deploying for free, please see our Meteor Deploy site docs. We do not recommend deploying production applications to the Free plan.

Configure your MongoDB database

If your Meteor application has a package that requires Mongo, then you’ll need a Mongo database configured for your application. Most users will want to use a hosted database provider instead of running it yourselves, such as MongoDB Atlas or ScaleGrid.

For optimum performance, we recommend that you setup a database in the same AWS region as your app deployment.

Many MongoDB providers expect you to tell them what IP addresses your app will be connecting from and forbids all connections from outside those addresses. To accomplish this on Galaxy, you’ll need to run your app in IP whitelisting mode.

Create a settings file for Galaxy

Create a Meteor settings file that will define the set of configurations needed for your application to deploy and run on Galaxy. At a minimum, the settings file needs to contain the connection URL to the MongoDB database.

In your application directory, create a file named settings.json. Put the Mongo URI in the file, using this format:

  "": {
     "env": {
       "MONGO_URL": "mongodb://<dbuser>:<dbpassword>@<dbserver>:<dbport>/<dbname>"

For a detailed example of the settings.json file, see Environment Variables.

Select a hostname

Choose a hostname that the public can use to access your application. You can use a custom domain or you can use the included * domain.

If you are using the included domain, use for apps deployed to the US East region, for apps deployed to the EU West region or for apps deployed to the Asia-Pacific region.

If you have a custom domain name, then you need to point your DNS (in your registrar’s dashboard) to More instructions on DNS configuration can be found here.

Deploy your application to Galaxy

Use the Meteor CLI tool to deploy the application to Galaxy. Make sure that you are signed into an authorized Meteor Developer Account that has permission to deploy to Galaxy. Use the CLI command meteor whoami to verify which Meteor Developer Account you are signed into.

The value of DEPLOY_HOSTNAME will depend on which region you are deploying to:

  • To deploy to US East:

  • To deploy to EU West:

  • To deploy to Asia-Pacific:

Mac and Linux

On the command line, within your application’s directory, type: meteor deploy [hostname] --settings path-to-settings.json

  • hostname is the fully qualified domain name where you’re planning to host your application (for example, ‘').
  • path-to-settings.json is the path to your settings file (for example, ‘./settings.json’).


If you are using Windows, the commands to deploy are slightly different. You need to set the environment variable first, then run the deployment command second (the syntax is the same as everything you’d write for meteor deploy). The commands will look like this:

$ meteor deploy [hostname] --settings path-to-settings.json

Cache your build

You can use the option --cache-build to reuse your build in multiple deploys.

This is useful if you want to deploy the same bundle to different environments and also if your upload is failing so you can just upload again without a new build.

The cache checks the current git commit of your repository so you need to be deploying from a folder that is a Git repository. meteor deploy [hostname] --settings path-to-settings.json --cache-build

This was introduced on Meteor 1.11

Build Only

You can use the option --build-only to stop the process after the build.

This is useful if you want to deploy the same bundle to different environments but first you want to build without deploying the bundle yet.

It’s recommend to use this option with --cache-build so your bundle is not deleted after the process. If you want to just check if your build is working then you don’t need to use --cache-build. meteor deploy --cache-build --build-only

This was introduced on Meteor 2.3

Specify an account to deploy

Galaxy utilizes the following policy to select the account to deploy your application to:

  1. If an application with the specified hostname already exists in an account, Galaxy deploys to the same account.
  2. If it is a new application, Galaxy chooses the individual user account if it exists.
  3. If it is a new application, and individual user account does not exist, Galaxy chooses the first Galaxy organization account that you are a member of.

If you are a member of two or more accounts, you can specify an owner username (available in Meteor 1.3) with --owner [username]. meteor deploy [hostname] --settings path-to-settings.json --owner [username]

Where username is the Galaxy account username the application should deploy into. You need to have deploy privileges to the account. Note: this only applies for new applications, as any subsequent deploys will already be attached to an account and re-use the same account.

Using a deployment token

Galaxy can also accept deployment tokens, which are good for 90 days. You can pass METEOR_SESSION_FILE=token.json before meteor login to generate a login session token so you don’t have to share your login credentials with third-party service providers. This solution is recommended for continuous integration service providers.

You can use a deployment token as an alternative to typing in your username and password. You’ll need to specify it both when running meteor login on your machine to generate the file, and when actually running meteor deploy in CI. Please note that your organization choice does not affect your deployment token.

Configure your application

The first thing you should do is verify that the deployment was successful. Check to see if the application is accessible by navigating to its URL. Then check the application logs in Galaxy at<app_name>/logs to see if there are any errors that are affecting the deployment.

Once your application is successfully deployed, head on over to your Galaxy dashboard to configure your application by adding a custom domain name and enabling SSL encryption.

Add a domain in your application’s settings and point your DNS to:

  • for applications in the US East region.

  • for applications in the EU West region.

  • for applications in the Asia-Pacific region.

If you are deploying to a root domain (for example, then follow the advanced instructions here.

Enable encryption to secure sensitive data by generating a free Let’s Encrypt certificate or uploading your own custom certificate.

Learn more

Edit on GitHub
// search box