Skip to main content
Galaxy Logo

How to Deploy a Meteor App to Production (2026)

Deploy a Meteor App to Production, a Galaxy guide

Deploying a Meteor app is simpler than most Node setups. The deploy is built into the framework. You still need a MongoDB to point at, a settings file for your config, and a host that runs Meteor correctly, including the oplog tailing and hot code push that keep Meteor apps reactive. Get those right and the deploy is one command.

This guide covers what a Meteor production deploy requires, the hosting options and their honest tradeoffs, and a full deploy on Galaxy, the platform built by the team that makes Meteor.

Follow along with the example app

We built a small open-source app so you can deploy the real thing: meteor-example.

It’s a stock Meteor 3 app — the default counter example, ready to deploy. The rest of this guide takes it to production. If you don’t have the Meteor CLI installed yet, follow the official install instructions first.

bash
git clone https://github.com/CloudByGalaxy/meteor-example.git
cd meteor-example
meteor npm install

What a Meteor deploy requires

Meteor bundles your app into a plain Node.js application at build time. Production runs that bundle. A few things you handle wherever you host:

  • A MongoDB database. Meteor needs a MONGO_URL. Reactivity depends on the database supporting replica sets and oplog tailing.
  • A settings file. Meteor reads config from a settings.json (env vars, mail, API keys), kept out of your repo.
  • The right Node version. Meteor 3 runs on Node 20+. On a host built for Meteor, the runtime is handled for you.
  • HTTPS and a domain. Production Meteor apps should run over SSL.
  • Hot code push and oplog. A correct Meteor host pushes new client bundles to connected users and tails the oplog so publications update in real time.

That last point is where generic hosts fall short. Running Meteor “like any Node app” technically works. The reactive parts need a host that understands them.

Your hosting options, compared

Meteor Up (mup)Docker / self-hostGeneric PaaSGalaxy
Setup~1 hourHoursMinutesOne command
Server maintenanceYouYouProviderProvider
Built for MeteorCommunity toolNoNoBuilt by the Meteor team
meteor deploy commandNoNoNoYes
MongoDB and oplogYou provisionYou provisionSeparate add-onOne click, same network
Built-in APMNoNoNoMonti APM
SSLLet’s Encrypt setupManualAutomatedAutomatic

Meteor Up (mup). A community tool that automates meteor build and ships the bundle to a server over SSH. Good if you want your own VPS. The server, MongoDB, SSL, and patches are yours to maintain.

Docker or custom build. meteor build produces a plain Node bundle you can containerize. Full control, full responsibility. You wire up Mongo, oplog, and SSL yourself.

A generic PaaS. Render, Railway, and the like run the bundle as a generic Node app. They don’t know about hot code push or oplog. The database is a separate bill.

Galaxy. The platform built specifically to run Meteor, by the team that makes Meteor. Meteor’s own deployment docs recommend it. meteor deploy ships your app in one command. Managed MongoDB runs on the same network with oplog optimized, SSL is automatic, and Monti APM is built in.

Deploy your Meteor app on Galaxy

Two ways to deploy. Push from GitHub, or one command from your terminal.

Push to deploy

1. Push the app to your GitHub. From the meteor-example folder you cloned earlier, create a new repository on GitHub and push. The easiest way is with the GitHub CLI:

bash
cd meteor-example
git remote remove origin
gh repo create your-username/your-app --public --source=. --remote=origin --push

Or create a new repository on github.com, then push manually:

bash
git remote add origin https://github.com/your-username/your-app.git
git push -u origin main

2. Create the app on Galaxy. In the dashboard, click Create New, then Deploy New App. The deploy wizard walks you through five steps:

App Type. Select Meteor.js. Galaxy pre-configures the build and runtime for Meteor, so don’t pick Node.js.

Git Provider. Continue with GitHub (or Bitbucket).

Repository. Import the repo you pushed in step 1.

Account & Plan. Choose your account and a plan. The Free plan runs in us-east-1 with an auto-generated subdomain. Essentials and Professional let you choose a region and container size.

Configure and Deploy. This last step has everything on one page. Set the branch (usually main) and a custom subdomain. Free apps deploy to myapp.sandbox.galaxycloud.app. Paid plans pick a region and run at myapp.us.galaxycloud.app.

3. Set your settings and database. Still on the Configure and Deploy page:

Just testing? Toggle Add Free MongoDB and you’re done. Galaxy provisions a shared cluster on the first deploy and automatically creates your settings.json with the correct MONGO_URL. No manual configuration needed.

Already have a database or extra settings? Paste your Meteor settings into the Meteor Settings JSON field:

json
{
  "galaxy.meteor.com": {
    "env": { "MONGO_URL": "mongodb+srv://user:password@host/db" }
  },
  "public": { "appName": "My App" }
}

Going to production? Create a managed MongoDB on Galaxy first. Open Databases in the sidebar, click Create Database, pick MongoDB, and choose a version, a size, and the same region as your app. It runs on the same network, so transfer is free and oplog queries stay local. Use a replica set for high availability. Daily backups are included. Copy its connection string into MONGO_URL.

4. Deploy. Hit the Deploy button. Galaxy builds the app, runs it over HTTPS, and redeploys on every push. PORT and ROOT_URL are set for you.

Deploy from the CLI

The deploy is built into the Meteor tool. From your project root:

bash
# Free plan with a free shared MongoDB
meteor deploy myapp.meteorapp.com --free --mongo --settings settings.json

For a paid app, drop the flags and point at your own database in settings.json:

bash
meteor deploy your-app.com --settings settings.json

That’s the whole deploy. No Dockerfile. No server to configure.

The help center walkthrough has the screen-by-screen version.

Galaxy is built and run by the team that creates and maintains Meteor. We run Meteor ourselves. The core parts of Galaxy, the Meteor site, Atmosphere, and several of our own products are all built with Meteor and deployed on Galaxy. We deploy Meteor the way we’re asking you to.

The gotchas that bite on the first deploy

Never deploy with the --production flag. It only simulates production minification while still watching files and talking to the package server. That wastes resources and creates security issues. Use the normal deploy flow.

The free MongoDB is for testing. No backups. It also needs tlsAllowInvalidCertificates in your settings. For production, create a managed MongoDB on Galaxy: replica sets for high availability, daily backups, and the same network as your app with no transfer fees.

Keep settings out of your repo. Paste your settings.json into Galaxy instead of committing secrets. Use the Settings File Path only for non-sensitive config.

Migrations need a paid plan. Run them with a Pre-Deploy Command, available on Essentials and Professional. It runs after the build, before traffic shifts.

Mind rolling deploys with data changes. Galaxy restarts containers one by one, so two versions run at once during a deploy. If a release changes data formats, make sure both versions can read the data.

Meteor deployment FAQ

Ship it

A Meteor deploy comes down to a MongoDB, a settings file, and a host that runs Meteor right. On Galaxy that’s one command, with the database, oplog, SSL, and monitoring handled by the team that builds Meteor.

Deploy your Meteor app on Galaxy. Start free, and move to a managed MongoDB when you’re ready for production.