Multiple redmine instances best practices

Question

I'm studying the best way to have multiple redmine instances in the same server (basically I need a database for each redmine group).

Until now I have 2 options:

1. Deploy a redmine instance for each group
2. Deploy one redmine instance with multiple database

I really don't know what is the best practice in this situation, I've seen some people doing this in both ways.

I've tested the deployment of multiple redmines (3 instances) with nginx and passenger. It worked well but I think with a lot of instances it may not be feasible. Each app needs around 100mb of RAM, and with the increasing of requests it tends to allocate more processes to the app. This scenario seems bad if we had a lot of instances.

The option 2 seems reasonable, I think I can implement that with rails environments. But I think that there are some security problems related with sessions (I think a user of site A is allowed to make actions on site B after an authentication in A).

There are any good practice for this situation? What's the best practice to take in this situation?

Other requirement related with this is: we must be able to create or shut down a redmine instance without interrupt the others (e.g. we should avoid server restarts..).

Thanks for any advice and sorry for my english!

Edit:

My solution: I used a redmine instance for each group. I used nginx+unicorn to manage each instance independently (because passenger didn't allow me to manage each instance independently).

Answer 1

The two options are not so different after all. The only difference is that in option 2, you only have one copy of the code on your disk.

In any case, you still need to run different worker processes for each instance, as Redmine (and generally most Rails apps) doesn't support database switching for each request and some data regarding a certain environment are cached in process.

Given that, there is not really much incentive to share even the codebase as it would require certain monkey patches and symlink-magic to allow the proper initialization for the intentional configuration differences (database and email configuration, paths to uploaded files, ...). The Debian package does that but it's (in my eyes) rather brittle and leads to a rather non-standard system.

But to stress again: even if you share the same code on the disk between instances, you can't share the running worker processes.