In some instances, large communities are divided to provide easier and more effective management.
Higher Logic Vanilla’s cloud solution offers the following community implementations for enterprise-grade deployments:
- Single community
- Hub & node
- Subcommunities
Let's take a look at each in a little more detail.
Single Community
This classic community setup is the equivalent of one installation of Vanilla. It can support any number of Categories arranged in a hierarchy.
Each Single Community needs a domain or subdomain assigned.
Hub and Node
The Vanilla Hub is the ideal solution when dozens or hundreds of separate, self-contained communities are required. New instances of Vanilla can be spawned within seconds through the Admin Dashboard or via the API.
This type of implementation allows you to set up one community as a template (the Hub) and easily create copies (called Nodes).
In most cases, each Node is a Single Community with the added ability of being synced with changes made on the Hub. Each Node is otherwise independent (i.e., it has separate user lists, private message exchanges, activity streams, etc.).
Learn more
Check out the articles below to learn more about Hub and Node:
Subcommunities
This implementation divides a Single Community or a Node into different areas by making each of the top-level Categories into subcommunities.
- This implementation is particularly useful for creating a subcommunity for a language or product line. Unlike Categories, subcommunities can have their own home page, locale, and announcement messages. Users can navigate from one subcommunity to another without losing their reputation points and Ranks.
- Each subcommunity (and its top-level Category) must have a unique URL path prefix. For example, an English language subcommunity will have the URL prefix
/en/ , so its URL would be forums.example.com/en. - While in a subcommunity, Categories and discussions will be filtered to that subcommunity. In addition, Category lists and the Recent Discussions page will be filtered to only show content from that subcommunity.
- All subcommunities belong to a single, main “instance” - the user list (and therefore moderators / admins), private messages, and activity stream are shared across all subcommunities. For a more detailed list of what is and is not shared across subcommunities, refer to the Shared content list in the Subcommunities article.
- A common way of combining this implementation with the Hub is to create a Node per product, and use subcommunities for each locale within that product.
Learn more
Architectural considerations
Cluster management
Our physical server assets are arranged into clusters; each cluster can hold multiple Single Communities, or a single Hub and its Nodes. They cannot be mixed.
Scaling capabilities
Because each Node is a separate entity, there are significant scaling advantages to choosing a Hub setup over a Single Community + Subcommunities setup.
Member authentication
Another consideration is how to set up community member registration and login. Here are the three use cases we typically see:
- Members authenticate via single-sign-on (SSO) to any of the communities
- Members authenticate via SSO to only some of the forums
- Members authenticate manually using Vanilla’s login page or with social logins
In most of our multi-community implementations, authentication occurs via SSO, where members are already authenticated to your website or application and are able to access Vanilla seamlessly.
If SSO is not required, members will register and sign in to each community using Vanilla’s registration or a social login such Facebook Connect or Microsoft ID. If you're not using SSO, subcommunities may be a better option for you if users need to sign in to multiple sites with a single set of credentials.