I have designed a meteor.js application and it works great on localhost and even when deployed to the internet. Now I want create a sign-up site that will spin up new instances of the application for each client who signs up on the back-end. Assuming a meteor.js application and python or javascript for the sign-up site, what high level steps need to be taken to implement this?

I am looking for a more correct and plete answer that takes the form of my poorly imagined version of this:

1. Use something like node or python to call a shell script that may or may not run as sudo
2. That script might create a new folder to hold instance specific stuff (like client files, config, and or that instances database).
3. The script or python code would deploy an instance of the application to that folder and on a specific port
4. Python might add configuration information to a tool like Pound to forward a subdomain to a port
5. Other things....!?

I don't really understand the high level steps that need to be taken here so if someone could provide those steps and maybe even some useful tools or tutorials for doing so I'd be extremely grateful.

I have designed a meteor.js application and it works great on localhost and even when deployed to the internet. Now I want create a sign-up site that will spin up new instances of the application for each client who signs up on the back-end. Assuming a meteor.js application and python or javascript for the sign-up site, what high level steps need to be taken to implement this?

I am looking for a more correct and plete answer that takes the form of my poorly imagined version of this:

1. Use something like node or python to call a shell script that may or may not run as sudo
2. That script might create a new folder to hold instance specific stuff (like client files, config, and or that instances database).
3. The script or python code would deploy an instance of the application to that folder and on a specific port
4. Python might add configuration information to a tool like Pound to forward a subdomain to a port
5. Other things....!?

I don't really understand the high level steps that need to be taken here so if someone could provide those steps and maybe even some useful tools or tutorials for doing so I'd be extremely grateful.

• javascript
• shell
• architecture
• meteor
• web-deployment

• Are you against using meteor's hosting for the solution? Do you have a script you launch the application with now? – user728291 Commented Aug 9, 2013 at 18:25
• I am somewhat against it for two primary reasons... but they could be invalid: 1. In the very near term I intend to add the ability for user uploaded content. I do not believe it is possible to control storage space or implement this with meteors solution for anything but files that can fit into the DB. 2. Crafting a backup solution around the meteor hosting is difficult. Accessing the databases for each application requires responding to a password prompt to get a short term mongo password, which makes automation a challenge. Even if 1) is possible, backing up those files is not AFAIK. – funkyeah Commented Aug 9, 2013 at 20:18
• ... and I use meteor's deploy now, but the actual the impetus behind the question es from the reasons above causing that to no longer be a viable approach – funkyeah Commented Aug 9, 2013 at 20:21

3 Answers 3

I have a similar situation to you but ended up solving it in a pletely different way. It is now available as a Meteor smart package:

https://github./mizzao/meteor-partitioner

The problem we share is that we wanted to write a meteor app as if only one client (or group of clients, in my case) exists, but that it needs to handle multiple sets of clients without them knowing about each other. I am doing the following:

• Assume the Meteor app is programmed for just a single instance
• Using a smart package, hook the collections on server (and possibly client) so that all operations are 'scoped' only to the instance of the user that is calling them. One way to do this is to automatically attach an 'instance' or 'group' field to each document that is being added.

Doing this correctly requires a lot of knowledge about the internals of Meteor, which I've been learning. However, this approach is a lot cleaner and less resource-intensive than trying to deploy multiple meteor apps at once. It means that you can still code the app as if only one client exists, instead of explicitly doing so for multiple clients. Additionally, it allows you to share resources between the instances that can be shared (i.e. static assets, shared state, etc.)

For more details and discussions, see:

• https://groups.google./forum/#!topic/meteor-talk/8u2LVk8si_s
• https://github./matb33/meteor-collection-hooks (the collection-hooks package; read issues for additional discussions)

Let me remark first that I think spinning up multiple instances of the same app is a bad design choice. If it is a stop gap measure, here's what I would suggest:

1. Create an archive that can be readily deployed. (Bundle the app, reinstall fibers if necessary, rezip). Deploy (unzip) the archive to a new folder when a new instance is created using a script.

2. Create a template of an init script and use forever or daemonize or jesus etc to start the site on reboot and keep the sites up during normal operation. See Meteor deploying to a VM by installing meteor or How does one start a node.js server as a daemon process? for examples. when a new instance is deployed populate the template with new values (i.e. port number, database name, folder). Copy the filled out template to init.d and link to the runlevel. Alternatively, create one script in init.d that executes other scripts to bring up the site.

3. Each instance should be listening to its own port, so you'll need a reverse proxy. AFAIK, Apache and Nginx require restarts when you change the configuration, so you'll probably want to look at Hipache https://github./dotcloud/hipache. Hipache uses redis to store the configuration information. Adding the new instance requires to add a key to redis. There is an experimental port of Hipache that brings the functionality to Nginx https://github./samalba/hipache-nginx

What about DNS updates? Once you create a new instance, do you need to add a new record to your DNS configuration?

I don't really have an answer to your question... but I just want to remind you of another potential problem that you may run into cuz I see you mentioned python, in other words, you may be running another web app on Apache/Nginx, etc... the problem is Meteor is not very friendly when it es to co-exist with another http server, the project I'm working on was troubled by this issue and we had to move it to a stand alone server after days of hassle with guys from Meteor... I did not work on the issue, so I'm not able to give you more details, but I just looked up online and found something similar: https://serverfault./questions/424693/serving-meteor-on-main-domain-and-apache-on-subdomain-independently.

Just something to keep in mind...