+1 on that blog post
I agree that Meteor deployment isn’t all I’d hoped for. Deploying to Meteor.com is perfect, just the way it should/could be. But deploying for production not so much. I wish we could have the same experience deploying to our own server as we do deploying to meteor.com. Perhaps something like:
Server:
apt-get install meteor
apt get install mongodb
My laptop:
meteor deploy myserver.com
Mup does a great job, but I think there’s still a little more that could be done. My biggest complaint with Mup is that it uploads the entire project every time you deploy, even if you only changed a single line. Using Git to upload would solve that.
Have you tried modulus? MUP is more of a devops script than a meteor.com alternative.
For example:
npm install modulus -g
cd your_app
modulus deploy --project yourapp
Then you can sit back and enjoy your coffee while they take care of load balancing websockets, elastically scale your instances on demand, and take care of OS/security patches.
The main problem with Modulus is it’s very expensive compared to DO or other VPS providers. For 1gb RAM, 1gb DB and 30gb storage it comes to $92.60 a month. On DO I could get 4 servers each with 2gb RAM, 40gb SSD and 2 cores and still have $12 left over from the Modulus pricing. You could then set up load-balancing of some-kind to manage between these servers (using cluster or nginx most likely).
I know you’d have to set up stuff yourself and I guess Modulus takes out that time needed to set up your servers, but one advantage of DO especially is setting up images for your server. Doing one server will essentially do hundreds with the same config thanks to their “snapshot” service. It’s how I’ve always done my servers anyway…
These are of course just my thoughts and if you’re having good experiences with Modulus then that’s great. For me though, I’d rather have more flexibility with procuring and using my own servers!
1 Like
Yea DO is much cheaper, but you’re also leaving out the cost of having someone setup all of the load balancing, patching linux, setting up elastic scaling, etc… You’re paying for that with Heroku, Modulus, (eventually Galaxy) etc…
That being said DO is def. cheaper and more flexible! For me if i’m operating a ‘free consumer’ type app it goes to DO and I do my best to keep it up. If it’s for paying customers then Modulus handles it for me.
One of the cons of the industry is that there is so much of the ‘free app’ mentality and so many ridiculous SV startups with no revenue plans that it makes cheap servers suddenly untenable.
For most apps the cost of of the hosting is peanuts once the app starts bringing in money. It’s not uncommon for a paying user to only take up $0.05 a month and they’re paying you 100x more. However 2mil free users is expensive 
2 Likes
I am thinking that instead of bitching about Meteor deployment, you should be asking questions (here and elsewhere) on how to monetize whatever you are doing, so that you could afford to invest into tools that would help you with deployment. Have you not even noticed that being in mentioned parts of the world is a competitive advantage that is utilized by many from other parts of the world? You get to earn revenue from the “expensive” parts of the world while at the same time keeping most of your development costs there, on the “cheap” side.
1 Like
I completely agree. For me having spent some time learning server best-practice and going through countless tutorials online I feel my server architecture suits my needs now but I understand that if someone is new to meteor and wants an easy, reliable host that Heroku and Modulus would be the best bet. At least until they’ve sorted out their own solution.
As for keeping things up to date, it can easily be done with minimal hassle. The 15th and 1st of every month I update my servers and so far (fingers crossed) I’ve had no security issues or any issues around being up to date.
Not sure what approach I’d take to having 2mil free users though! Thankfully I’m a way off that stage yet 
1 Like
if you’re not monetising 2mil free users you are doing something very wrong.
2 Likes
Problem: Keeping your servers up-to-date?
Solution: Run Docker.
Problem: Scaling, setting up failover solutions, zero-downtime deployment?
Solution: Run CoreOS with Docker, etcd and fleet.
Problem: Expensive hosting with Galaxy/Modulus/Heroku?
Solution: Run your own stack. Depending on your app size, get a DO droplet. Better yet, go HostHatch and get better hardware for lower prices. I’ve used both DO and HostHatch and I can say that HostHatch is waaay better and has a lower threshold for rate limitations.
Digital Ocean:
We use server-grade Intel Hexcore processors between 1.8 GHz and 3.0 GHz.
HostHatch:
Guaranteed Intel E5 3.5GHz+ cores, SSD’s in RAID10, lots of bandwidth.
The only drawback with HostHatch is that they don’t have such a powerful API as DO, but they’re working on it and should arrive soon. They do have an API though.
If you have a medium to large sized apps, go with SoYouStart but keep in mind that you’re on your own here. You can go with the parent company OVH if you want enterprise support and servers with more firepower and customizations. You’re basically trading support for lower prices if you choose SYS over OVH, but its the same datacenters.
At our company we run on OVH servers with CoreOS and Docker. Haven’t suffered a single minute of downtime in the year we’ve been with them, so very happy.
Something I disregard anyone from going with to host Meteor apps is Amazon Web Services or Google Cloud Platform. It is a really expensive solution as all your apps will have to run 24/7 and there’s no MongoDB “solution” available like there is a Cassandra solution so there’s a huge overhead in terms of pricing.
Problem: Inexperienced, just want a quick, easy way to host Meteor apps?
Solution: Be prepared to pay up, but as you decide to go with this solution, ask yourself what’s more worth; experience & knowledge or simplicity?
4 Likes
Things has to be discussed though. If the community sees a problem with deployment, hosting solutions or w/e - it is something we all should participate to discuss in order to improve the state of Meteor overall. Share thoughts, solutions and experiences with the community and I’m sure we can get together and solve any issues.
Meteor itself should be proof that the web as we know it is maturing at a pretty rapid phase, and if you’re gonna go all buzzword this and buzzword that, we won’t get anywhere. Hosting solutions is growing at equal phase as the web does. Better keep up! 
2 Likes
Thanks a ton for those server providers. Never heard of them and they look extremely competitive. So much so that I may move my entire server setup over to them…
I agree. I get to see it downloading modules all over again for a small change. It’s a tad very inefficient.
What a FANTASTIC response this post has gotten.
I agree with those that say, “bitch’n” won’t solve anything.
But, there are some substantive posts here with real solutions for those that want to spend money and those that don’t … Outstanding response by the community.
I’m very much excited by the vibrant community and the future of Meteor and Nodejs in general looks very, very bright.
2 Likes
But when you deploy it’s not a clone.
Your production build is different from development stage. It’s not possible to diff them.
Perhaps live should be more similar to the development stage. In the world of security, a lot of resilience comes from people knowing their tools inside out. Having a development environment that is substantially different from the live environment is dangerous. That’s why we try to make the two as similar as possible. Ever heard of the guy who tested with an abstract encryption method, only to find out that in live deployed boxes the abstract method was implemented as the null encryption algorithm? The live boxes could talk to each other, no problem, likewise the test boxes, and all the test vectors checked out beautifully on the test boxes. Secure encryption that passes all the unit tests. Yay! Live might be different to the extent of minifying js but that should be about it.
It’s a little more than that, but not too much.
But if it was just that, you can’t diff minified and verbose code.
You can always use the --production flag in development:
--productionSimulate production mode. Minify and bundle CSS and JS files.
Doing that to get a diff-able codebase on both dev side and server side?
Seriously?
Best of luck with that.
Well, no, I wouldn’t . But if someone was really inclined to try, it may be doable.
1 Like
That’s true, but why not upload the diff of the source code and build on the server?