Once upon a time, there was this magical thing called
meteor deploy. It was real simple and allowed you to share your Meteor app with the world. Those of you who remember when MDG took away the free hosting solution can probably relate and say that things have not been the same in the Meteor community since. Many demo apps went offline never to be seen again. The free hosting solution that came with Meteor was one of the best things that attracted me to Meteor. It allowed me to quickly build, show my demo to a client, get feedback, and repeat the loop until the product was ready to graduate to the next level. It was also very friendly towards beginners and abstracted away many deployment complexities.
In my introductory post, I introduced
meteor-now, the idea behind it, and a little about how it works. One crucial thing that was missing, that we were working hard on, is a true
meteor deploy replacement where you don’t even have to provision your own MongoDB. That was our goal after the initial release of
meteor-now and I think we were successful in implementing that in our latest release.
After some crazy ideas that now seem completely unfeasible, we decided to try and bundle MongoDB in the same Docker image that the Meteor app is running on. Justin was able to put together a Dockerfile that successfully bundles Meteor as well as MongoDB together. When the Docker container is ready, MongoDB as well as the Meteor app are started together using supervisord. From Meteor’s perspective, it is connecting to a local MongoDB instance just like when you run
meteor on your development machine. This works out perfectly since every free deployment will be self contained and there is no crazy MongoDB scaling to worry about. This is mainly why MDG pulled the plug on
meteor deploy. It was costing them a lot of money to maintain it.
meteor-now offers a very similar experience for free thanks to ZEIT’s Open Source Software plan. To deploy Meteor with an included MongoDB instance, just run
meteor-now in your project folder.
The only caveat to this is that if your Meteor app starts to gain traction, the
now service will automatically scale your deployment by creating new containers. Well if MongoDB is part of the container, things are going to get weird since now you’re going to have multiple databases. Which container are you connected to?
I have done some a small tests using Load Impact and did not observe any weird data anomalies but you should keep that in mind. Either way, I think this is a small trade off. If you see your app getting popular, it’s worth looking into getting a dedicated MongoDB instance from mLab or Compose and you won’t run into these issues.
I hope this article gave you a good idea of how
meteor-now is able to bring back the
meteor deploy goodness. Please feel free to reach out to me or Justin, or just post an issue at the