Deploy Meteor Apps Using Push to Deploy
Ready to get your app running in production? Galaxy makes it ridiculously simple. With Push to Deploy, you can launch your application directly from your GitHub repository in just a few minutes. No complex setup. No infrastructure headaches. Just your app, live on the internet.
Before You Start
Here's what you'll need:
- A Galaxy account (create one free if you haven't already)
- A GitHub repository with your Meteor application code
- Access to your GitHub account to authorize Galaxy
That's it. Seriously.
To deploy any application on Galaxy, you must add a valid payment method for identity verification. We'll place a small temporary hold on your card to verify it, then automatically refund it. Don't worry: you'll only be charged if you deploy a paid app.
Start a New Deployment
Head to your Galaxy dashboard and look for the Create New button in the top right corner. Click it and select Deploy New App to get started.
If you're brand new to Galaxy, the Apps page will be empty. That's normal. You're about to change that.
Choose Your App Type
Galaxy supports multiple app types, and you'll start by picking what you're deploying. Select Meteor.js since that's what you're running.
You'll notice Meteor.js shows "Versions: 1, 2, and 3" right on the card. Galaxy automatically detects your Meteor version from your project, so you don't need to configure anything special here.
Other app types available include AdonisJS, Node.js, and Python if you're working with those frameworks.
Connect Your Git Provider
Next up is authorizing GitHub. Select Continue with GitHub to connect your repository.
Currently, GitHub is the only supported Git provider for Push to Deploy. Bitbucket support is coming soon, so stay tuned if you're using that platform!
GitHub will prompt you to authorize the Galaxy application. This gives Galaxy permission to access your repositories and set up automatic deployments when you push code.
Select Your Repository
Browse through your GitHub repositories and pick the one containing your Meteor application. You can filter by repository name if you have a lot of them.
Once you find it, hit Import to proceed.
Choose Your Account, Plan, and Container
Now things get real. You're picking the resources for your app.
Which Account?
If you're working with an organization, select it here. Otherwise, your personal account is already selected.
Pick Your Plan
Galaxy has three plans to choose from: Free (great for testing), Essentials (for production apps), and Professional (for mission-critical work). Each supports different container sizes and resource allocations.
Not sure which one is right for you? Start with Essentials for production, or Free for testing. You can always upgrade or downgrade later based on what you actually need.
For a detailed breakdown of pricing, features, and what's included in each plan, check out the Billing documentation.
You can switch plans anytime after deployment. Don't overthink this choice.
Select Your Container Size
Each plan supports multiple container sizes. Container size determines how much RAM and CPU your app gets. Bigger containers handle more traffic and heavier workloads, but cost more to run.
Start with a medium-sized container and scale up if you hit performance limits. Most apps do just fine starting smaller and growing as needed.
For the complete breakdown of container sizes, CPU allocations, and pricing, see the Billing documentation.
Configure and Deploy
You're almost there. This final step is where you customize the deployment itself.
App Configuration
App Display Name: Give your application a friendly name. This is just for your reference in the Galaxy dashboard (it's not used in the URL).
Branch: Which branch should Galaxy watch and deploy from? Most teams deploy from main or master, but choose whatever branch makes sense for your workflow.
Custom Subdomain: Choose a memorable subdomain for your app. This becomes your default URL (like myapp.meteorapp.com). Don't worry too much about it, though, you can always add a custom domain later.
Region: Galaxy runs your application across multiple regions to reduce latency:
- us-east-1 (Virginia, United States): East Coast and general US traffic
- eu-west-1 (Ireland, Europe): European users
- ap-southeast-2 (Sydney, Australia): Asia Pacific traffic
Region Selection by Plan
Free plan apps are deployed to us-east-1 by default and don't include region selection. Paid plans (Essentials and Professional) can choose any region during deployment. Want to change regions later? Upgrade to a paid plan from your app's dashboard.
Build Configuration
This section is specific to Meteor apps. Here's where you configure your Meteor settings.
Settings File Path (Optional): If your settings.json file is committed to your repository, enter the path here (like private/settings.json). Leave this empty if you prefer to paste your settings directly or manage them in Galaxy.
Only use the Settings File Path for non-sensitive configuration. Never commit secrets like API keys, database passwords, or tokens to your repository. Use the Meteor Settings JSON field instead.
Meteor Settings JSON: This is where you paste your complete settings.json content. Galaxy provides a code editor with syntax highlighting and a size indicator (up to 1 MB).
Your settings should follow this structure:
{
"galaxy.meteor.com": {
"env": {
"MONGO_URL": "mongodb://user:password@host/db",
"MAIL_URL": "smtp://user:password@smtp.example.com:587"
}
},
"packages": {
"mongo": {
"options": {
"tlsAllowInvalidCertificates": true
}
}
},
"private": {
"stripeKey": "sk_live_xxx"
},
"public": {
"appName": "My App"
}
}This is the recommended approach for secrets and sensitive configuration. Your settings stay out of version control, keeping your repository safe.
Database
Want to add a MongoDB database right now? Toggle Add Free MongoDB to provision a shared cluster for testing and development. This is super convenient for getting up and running fast.
If you enable Free MongoDB, MONGO_URL will be automatically added to your settings. The free shared cluster is great for testing but not recommended for production workloads.
Already Have a MONGO_URL?
If you've already set a MONGO_URL in your environment variables or Meteor Settings, the Add Free MongoDB option will be disabled. Galaxy detects the existing connection string and skips provisioning a new database. Remove your existing MONGO_URL if you want to use the free shared cluster instead.
If you already have a database or prefer to configure it separately, skip this option.
Environment Variables
Below the Meteor settings, you'll see an Environment Variables section. For Meteor apps, most configuration goes in the Meteor Settings JSON above. However, you can still add additional environment variables here if needed.
Galaxy pre-adds PORT with a default value. These variables are available alongside your Meteor settings.
Deploy!
Review everything one more time. Does the app name look good? Region selection make sense? Settings entered correctly? Then hit the Deploy button and watch Galaxy work its magic.
You'll see the deployment in progress. Galaxy bundles your app, uploads it, and spins up your container. Within a few minutes, your app is live.
That's it. You just deployed a Meteor application to production. Pretty painless, right?
Managing Settings After Deployment
Your app is live, but configuration often needs tweaks. Galaxy makes this simple with the Variables tab in your app's dashboard.
Once deployed, open your app and navigate to the Variables tab. For Meteor apps, you'll see a specialized JSON editor (marked with a "GALAXY MODE" badge) where you can edit your complete settings.json. Make changes, click Save, and Galaxy restarts your containers with the new configuration.
For the complete guide on editing settings, understanding hot-swappable vs rebuild-required changes, and troubleshooting configuration issues, see the Variables tab documentation.
Free MongoDB Configuration
If you're using Galaxy's built-in MongoDB (with the Add Free MongoDB option), Galaxy sets MONGO_URL automatically. You'll also need to include this in your settings to handle SSL certificates:
{
"packages": {
"mongo": {
"options": {
"tlsAllowInvalidCertificates": true
}
}
}
}This setting is necessary because the free database provider doesn't have certificates installed on every machine. If you're using your own external MongoDB database with a custom connection string, you won't need this setting.
The free MongoDB shared cluster is not recommended for production. It doesn't include backups or restoration resources. For production apps, use a dedicated MongoDB instance.