# Multi-user app

**URL:** <https://www.ruby-forum.com/t/multi-user-app/127526>\
**Category:** Rails\
**Created:** [January 30, 2008, 2:09am UTC](https://www.ruby-forum.com/t/multi-user-app/127526 "2008-01-30T02:09:40Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![alce](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/f07891/32.png) [@alce](https://www.ruby-forum.com/u/alce)\
**Post date:** [January 30, 2008, 2:09am UTC](https://www.ruby-forum.com/t/multi-user-app/127526/1 "2008-01-30T02:09:40Z")

</div>

Hi All,

Which is the best way to handle multi-user applications in Rails  
(think backpack)?

Let me try to explain what I am trying to do:

I wrote an application and sold it to different companies. For every  
company I sold the  
app to, I deployed a fresh Rails app to a fresh 256MB VPS and provided  
a superuser  
account (to the app, not the server).

Customers handle their own users from there as they see fit. User  
administration is  
handled by a combination of acts\_as\_authenticated, a recipe from Chad  
Fowler’s Rails  
Recipes and a handful of rather ugly hacks. All in all, user  
administration is very  
complex since a superuser has very fine-grained control over which  
parts of the  
application and database operations and records a regular user can  
have access to.

I want to rewrite the whole thing from the ground up and one of the  
most significant  
changes will be to have only one code base shared by all users. (Maybe  
this is the  
way it should have been deployed in the first place but given my lack  
of experience  
and the fact that my customer base is very very small -think dozens,  
at most-  
multiple deployments were a good idea at the time).

Problem is, I am not exactly sure how to go about that:

First, it will add another layer of complexity to the user  
administration system and I still  
have to figure out how to handle it.

And what about the database?, should all companies and thus, users,  
share the same one?  
That worries me a bit considering:

a) Users of my system are direct competitors and the information  
contained in the database  
is critical.  
b) Although traffic is not a concern at all, the database can grow  
considerably large in a short  
period of time.  
c) If the database crashes ALL my customers will be affected, not  
just one. Granted, I really  
should backup regularly but still…

Is there a way to have multiple connections to different databases and  
decide which database  
to query given the user that has just accessed the app? If so, is that  
a good idea?

Thanks  
Juan

---

<div class="post-metadata">

**Author:** ![alce](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/f07891/32.png) [@alce](https://www.ruby-forum.com/u/alce)\
**Post date:** [January 30, 2008, 6:17am UTC](https://www.ruby-forum.com/t/multi-user-app/127526/2 "2008-01-30T06:17:38Z")

</div>

Hi Juan,

What in particular don’t you like about each company having their own  
server? Is it the increased effort to deploy software updates?

Wyatt G.

---

<div class="post-metadata">

**Author:** ![alce](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/f07891/32.png) [@alce](https://www.ruby-forum.com/u/alce)\
**Post date:** [January 30, 2008, 7:45am UTC](https://www.ruby-forum.com/t/multi-user-app/127526/3 "2008-01-30T07:45:07Z")

</div>

Hi Wyatt,

That bugs me a bit, yes. Although the whole process is pretty much  
automated  
(installing all software in a new server, deploying the app and  
pushing updates),  
I think it would be easier for me to maintain just one server.

What really bothers me though is monitoring all the servers (I am  
obsessive  
about that) and cost.

Right now I host each client on a 256MB VPS and costs are soaring  
quickly. I could  
host 2 apps per server, probably 3 but no more than that since I like  
to have at  
least 2 mongrels running per app.

The funny thing is, the apps have negligible traffic and a 1G VPS  
would probably  
be enough to give service to all my clients wit just one app and  
bigger cluster of  
mongrels.

Furthermore, unless I am missing something, all my clients can keep  
using  
the same url’s to access the service. (I could just create a new  
virtual host for  
each one and point it to the one app). I could even have the  
application query  
the proper database given the host.

Does that make any sense?

---

<div class="post-metadata">

**Author:** ![alce](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/f07891/32.png) [@alce](https://www.ruby-forum.com/u/alce)\
**Post date:** [January 30, 2008, 5:26pm UTC](https://www.ruby-forum.com/t/multi-user-app/127526/4 "2008-01-30T17:26:13Z")

</div>

On 30 Jan 2008, at 15:44, Wyatt G. wrote:

> If I understand correctly, switching from multiple VPSs to one server  
> for all companies would:
> 
> - decrease cost
> - decrease effort (to monitor the systems)
> - potentially increase risk

Rimuhosting offers the option of installing multiple VPSs on one  
server. That’s what we use and it’s the best of both worlds (we have  
a few customers that want a VPS so they don’t have to have us manage  
it and that’s fine by us, they are responsible for keeping it up),  
our other customers are on the same server in a different VPS with  
Plesk. They are limited to creating e-mail addresses and some FTP space.

Backups: such a setup provides an excellent environment: the RAID  
installation on the server keeps the data mirrored on a second disk  
and all VPSs are backed up twice a week in a rotation scheme (meaning  
two vps backups are always present on the disk). That’s quite a few  
backups already (considering they are mirrored on the RAID disk) and  
with the extra remote FTP backup space you get from Rimuhosting we  
can still do a daily dump of all our databases and put those on that  
extra FTP space.

> You mentioned some risks about the database, such as competitors’ data  
> being in the same database, and if the database goes down, all  
> customers will be affected. I think that pretty much summarizes the  
> types of risks you have to think about:
> 
> - risk that information will bleed over into an area where it  
> shouldn’t be accessed
> - risk that system failure means failure for all clients

That’s true, but with a multiple VPS on one server solution that risk  
is minimized to hardware failures, and keeping my fingers crossed, it  
hasn’t happened to us yet.

Best regards

Peter De Berdt

---

<div class="post-metadata">

**Author:** ![alce](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/f07891/32.png) [@alce](https://www.ruby-forum.com/u/alce)\
**Post date:** [January 30, 2008, 3:45pm UTC](https://www.ruby-forum.com/t/multi-user-app/127526/5 "2008-01-30T15:45:28Z")

</div>

Hi Juan,

If I understand correctly, switching from multiple VPSs to one server  
for all companies would:

- decrease cost
- decrease effort (to monitor the systems)
- potentially increase risk

You mentioned some risks about the database, such as competitors’ data  
being in the same database, and if the database goes down, all  
customers will be affected. I think that pretty much summarizes the  
types of risks you have to think about:

- risk that information will bleed over into an area where it  
shouldn’t be accessed
- risk that system failure means failure for all clients

I don’t think there’s anything wrong with putting all your eggs into  
one basket, just make sure you have a really good basket. 🙂 Watch  
out for subtle things like using class variables. These will stick  
around in Mongrel between requests, so if you have data in class  
variables that are different depending on the company, that’s one way  
for one company’s information to get sent to another company.

As far as having multiple databases with one Rails project: I think  
you can do that, although I don’t know whether it would be good or  
bad. I believe the book “Rails Recipes” by Chad F. has a recipe  
on having multiple databases in one Rails project.

The part about your clients keeping the same URLs makes sense to me.  
You should be able to make this type of change without impacting your  
users.

Good luck!

Wyatt G.
