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.
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: https://github.com/kadirahq/meteor-up
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 modulus.io 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 Prerender.io - 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?
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 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.
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.
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
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.
@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?
