two digitial ocean questions:
one thing i’m loving about modulus is the simplicity of “modulus deploy”. I’m just not a huge fan of the pricing, especially if there is something better and more extensible (with the cluster package).
The apps I’ve done so far have been small enough that the app & db are on the same server, so I can’t really help there.
The best way for me to deply to DO (or any remote server you have SSH & root access too) so far is: https://github.com/arunoda/meteor-up#installation
Depending on requirements, it could be as easy as just creating the instance, changing your password (or creating a non root user), then using MUP on your local machine. Once the config file is setup the command “mup deploy” from your app directory will bundle your local meteor app, pre-install all necessary software on the remote server (node, mongo, etc), SSH it to the remote server and then start it up. It also handles the SSL certs, starting up and reboot and keeping alive if you app dies for anyreason. I don’t have a ton of Meteor experience (< 5 months), but it hasn’t got much easier than that for me.
@manuel I’m really really surprised, my last startup we got $60K in free hosting on Azure. Ruby / Angular on Azure VM and had noting but issues
I have been using Modulus and Compose for the past three months. Compose has been great but, as others have noted, Modulus has been having issues lately. No only did I run into the deployment challenges this week but I have not had success with getting their sticky sessions / load balancing / auto scaling capabilities to work properly.
I love Modulus’ ease of use but the consistency and service level have not been ideal and I am going to start looking at other options. If I recall, WorkPOP is using the Modulus and Compose combination and they said that Modulus has been great for scaling.
My next step is to look at Cluster from Meteorhacks and DO or AWS.
After a lot of trying my best way to go is:
DigitalOcean + Nginx + Meteor Up + MeteorCluster + Compose (at the same data center)
Why: Nginx for SSL termination and static content delivery, Meteor Up for easy deploying, MeteorCluster for multi-core support, Compose for robust mongodb
So, if I need more power I can do vertical scaling and go to more CPU (DO with 4 or more cores) and MeteorCluster. If I want to do horizontal scaling I can create more DO-Droplets but have to do some nginx, ssl and dns configuration.
If you need horizontal scaling, you can easily do it with Meteor Cluster too.
You don’t need to go for DNS based setup. Simply add more instances.
I’ve show them here: https://meteorhacks.com/cluster-a-different-kind-of-load-balancer-for-meteor.html
May be I need to come up with some better documentation.
How do you ensure you D.O. droplet and Compose db are in the same data center? That’s something I’d obviously like, but I know nothing about which data center the physical machines are in or how to do anything about it.
When you creating the compose DB, you can select the datacenter.
I can select a zone like us-west-coast when setting up a Compose db, but the west coast of the US is a big place – how can I be sure it ends up in the same data center as my D.O. droplet in the us-west-coast zone?
Seems like you’ve selected Compose’s AWS datacenters. They support D.O data centers too.
Thanks, Arunoda. I should have thought before I typed! 
Guys, sees like most of your interested about Cluster. What it lacks is a better documentation.
So, I started to work on some docs.
Here’s the outline: https://hackpad.com/Cluster-Documentation-JgozZ2xnk4R
I’d like to hear suggestions and more topics to add.
Thanks for your replay. I understand what you mean, but if I want to have all the advantages of more droplets (higher availability, all are load balancer, etc) than I need to do some DNS and SSL stuff. Or am I wrong?
No you don’t need. Simply add more instances and point traffic into one server. It will work.
Add SSL to the server you are sending traffic. I need to more docs. Will do it soon.
I have used Heroku successfully for Meteor production. However you can only run one instance of an app because it does not support sticky sessions.
You can definitely run multiple instances of your app (“dyno’s”) on Heroku. There may have been a reason long ago but Heroku supports websockets now which are “sticky”. The few clients that fall back to long polling may increase load slightly but I doubt it’s noticeable. Haven’t tested this too thoroughly, someone please correct me if I’m missing something.
But anyway I’m looking forward to Galaxy, I’d switch to that in immediately. 
Long polling does not corectly work with meteor on heroku.
Heroku has round robin routing. So, multiple long polling connections goes to diff. servers. Which breaks the SockJS connection.
Then those clients will refresh the page every few seconds.
Oh, I hadn’t thought this through well enough. I had thought that when the long polling times out it would re-establish the DDP connection. I’m sure it wouldn’t be a problem to re-establish the DDP connection and hit a new server, but now that I think about it SockJS’s long polling websocket emulation is transparent to Meteor, so Meteor isn’t actually re-establishing the DDP connection and probably would get messed up.
But websockets is the norm so most people wouldn’t notice the problem. Unless you have IE 9 or old Android or a bad proxy you would end up with a websocket connection.