First, I’d say that the main value of Galaxy is its easy integration with Kadira. Application performance monitoring (APM, what Kadira is) is incredibly valuable, and Kadira in particular is very well written. If APM isn’t important to you, then go ahead and host these things yourself.
If your goal is to do everything as cheaply as possible, the fastest, cheapest and easiest solution is to use a single, high performance AWS instance that runs an single-node, replicated mongod instance with a database directory on an EBS guaranteed-IOPs drive; and
meteor run --production --port 80 (note, it looks like the MDG folks suggest against doing that, so maybe just package with their build commands and run it directly with node) with a
MONGO_URL environment parameter set to the appropriate path.
You should use the documentation from
To specifically answer your questions,
- I wouldn’t worry too much about MUP
- if you want to create a mongodb instance separate from your web host, which is a “gold standard,” just start a new AWS instance
compose.io is great, but all database providers are a rip off (and the fact that there are so many of them should be a huge red flag that what they do is fundamentally undifferentiated and provided out-of-the-box by mongo)
- you don’t need to load balance, use AWS Application Load Balancing if you really think you do, but it’s better to just upgrade your instance and configure it to be backed-up regularly
- to run a new meteor instance, start a new AWS EC2 instance in the same VPC and specify the MONGO_OPLOG_URL and MONGO_URL to point to the database host.
Deployment seems complex, but I think people make these insane systems to do fundamentally really simple things.