How to turn a single-site app into a mantainable multi-site app without code changes?

Question

It's an application that we use internally at the office that I would like to offer as a hosted service for anyone.

How can I do that without making major code changes?

The first thing that occurs to me is to have the app select which database to connect to based on the domain.

So each instance of the app would have its own database, but all instances would share the same code.

The only changes required to the code would be the database selection.

Is this approach maintainable? I've heard wordpress.com does this and that it offers a couple of advantages. I'm mainly looking to do it this way to avoid have to scope my entire set of database queries to a certain site within the same database.

Thanks!

Answer 1

The simplest way to do this is to clone the application, and create another server instance to handle it. This actually the way I handle multiple wordpress blogs on my server

Pro:

• This process can be streamlined into a utility script.
• Can be easily maintained if symlinks are used for the common code. IE: Everything but branding and some of the things in the config directory.

Cons: - If you're using passenger it will require an apache restart for each new instance. - Same if you're using Apache to route subdomains on different virtual hosts to different mongrel clusters.

However the better way comes from the question: Rails - Separate Database Per Subdomain

The method in the accepted answer is much more robust. It might require more changes than you're looking for, but it has all the benefits without the drawbacks of any other methods. Each new instance requires a new entry in the master database with the table name and other instance specific information. You'll also want custom rake task to build the database for each new instance.

Answer 2

I would suggest switching the database connection and adding a view_path based on the domain, I have posted code in this question.

I hope this helps!

Answer 3

I wouldn't do this with multiple databases as you mentioned. Keeping all your schemas/migrations in sync with all the db's could become painful.

I would look into simply making it a multi-tenant app where you have some sort of "Account" model and then all your existing models are scoped to it ... in other words, if this was a blog app, your Account has_many :posts, etc.

With this approach, you can identify accounts by subdomain ... have people choose their subdomain when they create an account and go from there.

It's pretty straightforward to do. If you need add billing into the mix, you might look at the SaaS Railskit (which handles all the signup and subdomain stuff) or Chargify.

You can also identify accounts Twitter-style ... with http://myapp.com/someuser