Is there a chance to setup Multi-Site or Network Installations?

(sJeev) #1


I like the idea about of new age discussion forum. Would like to know if the self-hosted open -source script let us maintain a Multi-Site Installation(Not Multiple Installations. It is about multiple sub-site creations such as, Just like WordPress Multisite.

Shapado already has the multisite functionality and other CMS’s implemented it

These are some points:

  • The setup should be a Single Installation enabling multiple site creations:

  • Each site or network will share a single userbase. But will have restrictions based on permissions network wide.

  • Every admin have full rights specified to his own sub-site and the
    Super admin’s rights are network specific.

  • Auto-mated site creation from front-end.

Looking forward for your response


(Philip James) #2

Excellent idea! Given that this is being created by the guys who did the multi-faceted StackExchange sites, I would imagine that a multi-site option is in the works.

(Sam Saffron) #3

Already implemented, the same pool of processes that are serving is serving this very site.

(sJeev) #4


In that way, you need to create the sub-sites by editing -multisite.yml each time you create a sub-site. That is just a lesser impact to “Multisite” and better than Individual site set up.

But what I need is a full fledged Multisite setup, enabling any of my friends to create their own discussion site just as main site.

Thank you!


I Hope they would implement it. is a best example(It used to be a SaaS application letting any one to create a site. Later, that was deprecated and they provided an option to export the data to move. Only the popular sites and topic specified sites were remained on their network, those we see now) .

Shapado is another example.

(ayush) #5

But what I need is a full fledged Multisite setup, enabling any of my friends to create their own discussion site just as main site.

Building on that, it’ll be great if the multisite support is dynamic. Perhaps an API which can be called to create/manage these “Sites/Networks”. This is especially useful for use cases where discussions are not in a single forum but there is a need for multiple forums. For example at flickr groups.

(Richard - #6

[first post here, just started playing around with Discourse, bit of a RoR newbie though so please forgive any ignorance].

Ok, so how do you get such a multisite setup to work? Can you give me some pointers here? I see some mentions of multisite.yml, what it would have to look like. I did find out that host_names in database.yml has to do with this. But how does this interact?

(Richard - #7

Ok, I have been playing around a bit longer, and I figured it out. Just copy database.yml to multisite.yml, duplicate your entries, change the hostname, and you’re set to go.

However, this will not scale very well, since a full connection pool is maintained. So if I have 50 virtual hosts and 20 thin processes, this will result in 1000 database connections. Also, as far as I can see, adding a host requires restarting.

I would like to see if we (I) can make this better. Since this can lead to some quite deep architectural changes (and as I said in my previous post, I’m not very experienced in RoR - I do have enough experience with other technologies though) I’d like to discuss some options here.

  • switching should be possible per-request so should be done with little effort
  • if possible, database connections should be reusable across different vhosts
  • changing configuration should be possible at runtime without reloading etc

If I add it all up, we need some kind of sharding or schema-based multitenancy - or maybe both.

Any ideas, thoughts, pointers ?

(Sam Saffron) #8

I wonder, what is your exact use case here? Why are you interested in “uber scalability” of this sub system?

That said, I have some ideas I plan to implement when Discourse the company is ready to provide a wider “pay-per-month” Discourse instance to our customers.

  1. Amend multisite gem so it can be DB driven
  2. Amend unicorn so it dispatches to “sticky” pids per hostname. That way you limit the amount of connection pools you create.
  3. Ensure AR winds down connection pools properly after a certain timeout (cc / @tenderlove)

That said:

(Richard - #9

Why are you interested in “uber scalability” of this sub system?


  1. Good scalability is one of the most important success factors for almost any piece of software
  2. I think Discourse currently scales not so well
  3. This is an area of expertise and interest for me

And I’m not going to beat around the bush: I’m looking into the possibilities of offering some kind of Discourse hosting in the future as well.

Can you elaborate on your remark about why multiple Discourse instances in a single DB (but different schemas!) would be insecure. Because I don’t get that.

(Sam Saffron) #10

Sure, and I am relentless about it. However scaling this sub-system is only about making it easier for 3rd-parties to host a huge number of Discoruse forums.

This is in direct competition with what we plan to do, we will only prioritize work in this area when we are ready to start taking a huge amount of customers, though PRs are welcome.

Plugins can run arbitrary SQL and may register custom tables, requiring namespacing at the db level would add a large amount of complication, validating plugins would be way more complex, if we were to way table level namespacing as an option we would have to see the benches that show us how much it improves things.

(Richard - #11

Not necessarily, that depends on both our business models. I’m not really looking to compete - that makes it harder for everybody.

But you’re right, and I understand your point of view: this is not the most valuable thing to focus on from a normal user point of view.

I haven’t looked into the plugin architecture yet, so that explains why I completely missed this. Although any hosted solution would have to do extensive plugin validation anyway, and a plugin would namespace automatically if it doesn’t try otherwise.

(Sam Saffron) #12

namespacing has some serious complications around SQL generation, it basically makes all places you write inline SQL much less pretty.

(Neil Lalonde) #13

You already figured it out, but for others I wrote a guide here: