@chipcastle This is possible without having to have a new instance of your app for every customer, but you would lose the benefits of Meteor's
Mongo.Collection functions, because all of Meteor's built-in db calls rely on a global
MONGO_URL env var. Unfortunately, to my knowledge, the only way right now to retain all Meteor functionality while supporting multiple customer databases would be to have separate app instances for each customer, and each instance has it's own unique
MONGO_URL pointing to that customer's db. That's totally possible and not too complicated, but it is very expensive to scale and it could be more trouble than it's worth, depending on your situation.
If you want to go the former, less expensive but more janky route, you can use node's native mongodb driver separately from Meteor for all your db operations, and each time you perform a db call, you use a dynamic per-customer
mongo_url field that you store in your users collection, for example. When the customer creates an account on your system, have them provide the url and credentials to their MongoDB instance. Therefore, the only data you need to store on your servers is user data. You'd also need to provide some sort of public API docs so that they know what kind of data your system supports. However, storing the
mongo_url for each customer is the core concept.
When implementing your methods, depending on the user and what "customer group" they belong to, you can make the calls using the customer's
mongo_url that you have stored in your own db. This allows you to host identical production instances of your app that you can scale as needed without having to manage separate instances for each customer. It also saves you tons of space since you don't need to host your all customers' data. If you have a lot high frequency reads and you're worried about speed, I'd suggest caching your customers' data on your system with something like redis.
That's the jist of it.