How do you run Meteor in production?

Meteor has been fantastic so far with my development project to try to save my company some time and money with repetitive sales processes. But I’ve run into a problem that admittedly is a showstopper so far…we can’t get Meteor to run in production anywhere. An app 2 people have been working on for 6 months works perfectly in dev, and worked perfectly on Heroku until the introduction of PhantomJS. Once that happened, KABOOM. Heroku app down. Reversing the last steps and going back to the last deploy should have fixed it…no go. It’s dead. So the two of us, both extremely experienced with enterprise Microsoft, Java, and PHP deployments somehow can’t manage to get Meteor to run anywhere in production with PhantomJS.

We just had a meeting with our boss. Essentially we’ve been told that everyone thinks we’ve spent the last six months playing with “a development toy called Meteor” and have nothing to show for it. IT has told us that in the end they don’t care how we do it, but it needs to run on AWS with preferences going to a Docker container. Unfortunately it seems that Meteor 1.3 is not compatible with Docker and errors out.

How do you run Meteor in production on Amazon Web Services? I’ve tried every tutorial I can get my hands on and somehow 15 years of enterprise IT is failing me.


When you say you’ve tried all the tutorials, which ones?
I’ve never deployed to AWS, but I have to DigitalOcean.

I had a quick read of this tutorial which was the first result on google:

It mostly makes sense to me and follows a similar process which I believe should work.

Where are you running into issues with AWS? Is the issue with PhandomJS as with on Heroku? or something else?

1 Like

Please see thread Meteor 1.3 deploy Error with MUP

You can definitely run Meteor 1.3 in production. Check out mupx (a version of mup meant to work with containers).

We have deployed many apps in Digital Ocean, It’s a bit difficult to deploy as compare to PHP (I am from PHP Background), but it works.

1 Like

Running in production is not a problem, using mupx you can use it with docker images.

If you want to use custom docker images you can use the kadirahq version of mup:
My suggestion is starting a custom docker image from the base meteord image.

If you have any specific questions just shoot, I’ve been running production apps on AWS for almost a year now.


Just to echo, we’ve found meteor quite easy to deploy with meteor-up. We have been using mup for deployments for 2 moderately large applications and have not really encountered any issues. It runs well, deploying new versions is easy, scaling up AWS infrastructure is fairly simple (although it did require quite a few customs scripts to get a load-balancer working properly.

We have also used to deploy another application. Modulus handles all the heavy lifting with deployments and deployments work great, with scaling as easy as a click in the control panel or an API call. Real simple. We did, however, come up against a couple of issues initially deploying the application. But that turned out to be a faulty build image on modulus’ servers. Which they fixed quickly.

Are you using phantomJS for any particular reason? If it’s for SEO… I wouldn’t bother. Our applications have been indexed perfectly without using phantomJS and spiderable. Although our deployments did work when we initially had phantomjs installed. Sounds like a deeper issue with your application. Does it run without phatomjs installed on the server.


We’ve built Galaxy, a Platform as a Service for Meteor apps, using Docker containers for the application runtime on AWS.

Galaxy also integrates with - so you can get SEO for your Meteor app through a service, without having to run PhantomJS in your docker containers. We found that PhantomJS and spiderable consumed considerable CPU resources in each application container.

Have you looked at Galaxy as a Platform as a Service to run your production app?

Thank you for your replies, everyone. I really appreciate how willing the Meteor community is to help someone else out.

I had to walk away from the problem for a couple of days so that I could approach it with a fresh mind, no lingering frustration.

I tried:
MeteorD -
With this I got random errors that I didn’t record.

Tupperware - This got farther than all of the others but errored at the issue mentioned.

Tried MUP and MUPX and oddly enough got zero errors, but also zero success. It installed everything to Linux, seemed to configure it correctly, and then nothing. It seems that its just not setting up a web server and configuring it, or even trying to. I also can’t find enough docs on verifying a mup/mupx to make it a viable avenue for a production deployment.

Heroku - Was beautiful once I found the Horse buildpack. Until I installed PhantomJS. Heroku never recovered despite rolling back and uninstalling and redeploying.

PhantomJS is an absolute requirement, sadly. I’m not using it for SEO as this is a strictly internal application. I’m using it to create a PDF contract and save it to SalesForce. PDFKit would require a massive amount of investment compared to PhantomJS, and may not create the same thing.

I’ve finally had success installing Meteor onto AWS EC2 using Passenger:

I highly recommend this for anyone struggling with Meteor deployment on any server. If I can get SSL working I think I’ve finally got a solid setup to keep this project alive.

I’ve personally had success using Docker with MeteorD, MupX, and manually uploading and running to AWS (later turned into an Ansible script on git push).

Typically if it’s just Meteor on the server its pretty simple, it gets complex when you start adding Apache into the mix.

How did you build the bundle? How did you get it into the Docker container? I’m normally pretty technically savvy but I struggled with this part.

With Docker, I just let MeteorD do the work, simply ran

docker build -t name/project .

Just use the meteord:base docker image for that. It works like a charm.

I might have spoken too soon. Apparently the introduction of SSL is extraordinarily complicated with Passenger, with zero documentation or examples to back it. Hang tight folks, either I’m going to have a heroic blog post on “How to deploy Meteor when literally everything else fails”, or I’m going to be fired. We shall see.

1 Like

I just recently deployed a Meteor (v1.3.x) application on Digital Ocean using Ansible, mupx and TincVPN. I have a load balancer (Nginx reverse proxy) connected to two application servers via DO Private Networking and VPN-secured connections, which connect to a MongoDB replica set on three different DO Droplets (also connected via TincVPN). I used MupX for deploying to the app servers. Took me one afternoon to set the whole thing up and it seems to work like a charm. The only issues I had was setting up the firewalls properly (I was blocking my own connections with TincVPN at first). Maybe you should review firewall settings (iptables eg.) ? Anyway, I’d love to help you not get fired so let me know if it doesn’t work out for you :slight_smile:

1 Like

Thank you. I’m not sure that mupx is going to work. I’ll give mup another shot later. This is what mupx does:

Did you get SSL working with Passenger? I have an app running in Passenger using Letsencrypt SSL if you’re interested.

Can you post the contents of your settings.json file?

Are you investigating the issues you’re running into in detail? Based on this thread it feels like you’re jumping from platform to platform at the first issue.

Hi there. I struggled with Phantom.js for printing PDFs in a node.js project some time ago. I would suggest that you create another service just for the task at hand and communicate using message queues and isolate the PDF generation. Mostly because you will not want to consume a lot of CPU in your web server. In AWS you can still save the file in S3 bucket and save the access to your mongo DB for access from the front end / web server.

It is just my honest opinion after struggling a lot with Phantom.js and its version upgrades. I guess you could totally workout this service in a afternoon and leave your meteor app free to process more important stuff.

Just my 2 cents

1 Like

@whitesidest I’m very curious where all of this leads because I see myself having the same problem in a few months. I’m hesitant to even dip my toes in the Meteor ecosystem if there is not a clear path to deployment. Why is Galaxy not an option for you?