In this tutorial, I’ll cover the step-by-step process to setting up a multitenant Rails 5 application that doesn’t use subdomains. For this tutorial, I’ll be focusing on acts_as_tenant (see why I’m not using Apartment below).
Why shouldn’t you use subdomains for multitenant apps?
Well, it just depends. There are pros and cons to each approach.
Pros of using subdomains for multitenant sites
Subdomains can be a good approach when you create each subdomain. This might be the case for an auto dealer who needs a single backend to manage multiple sites (audi.x.com, bmw.x.com, mercedes.x.com, and so on).
If you plan to let users create their own subdomains, subdomains also allow them to point a custom domain to your site. So instead of theirname.yoursite.com, they can use something like xxx.theirsite.com. Is this a dealbreaker for you? It can always be set up as one of your future features, and you can charge extra for it (since it’s more expensive for you to manage).
Some people like the way subdomains look. They think that theirname.example.com is professional, while example.com/theirname is not.
Cons of using subdomains for multitenant sites
If you plan to let users create their own subdomains, SSL becomes a pain to manage. In other words, it’s difficult to add
https:// to every one of your subdomains. You can do this with something called a wildcard DNS certificate, but it’s more expensive than the alternative, and it’s harder to set up on a platform like Heroku. Since it’s 2018, letting sites fall back to
http:// just won’t cut it – you definitely don’t want Chrome to display that your SaaS app isn’t secure.
Many companies have made the switch off of subdomains in the last several years, possibly due to this problem. One that comes to mind immediately is Basecamp. Medium is also doing away with subdomains and their custom domain feature and opting house all users’ posts on their base URL.
“At this point, I cannot recommend going the Postgres schema approach given the headaches we’ve seen above. I hope this post helps you all avoid some of the pitfalls that we’ve encountered and are still digging ourselves out of.” – blog post from Influitive, the creators of Apartment
Heroku also recommends against using the Postgres schema approach and have experienced problems with even just 50 schemas:
The most common use case for using multiple schemas in a database is building a software-as-a-service application wherein each customer has their own schema. While this technique seems compelling, we strongly recommend against it as it has caused numerous cases of operational problems. For instance, even a moderate number of schemas (> 50) can severely impact the performance of Heroku’s database snapshots tool, PG Backups. – Heroku docs
I didn’t want to worry about these limitations, so I decided to look into the second most popular multitenant Rails 5 gem out there: acts_as_tenant. I think it would be more popular if it had a simpler name. And while the documentation isn’t bad by any means, I think it could use a step-by-step tutorial such as this one. So I’m here to provide that.
How to set up acts_as_tenant
1. Add acts_as_tenant to your Gemfile.
3. Let’s separate customer data into
rails g scaffold Account name:string
4. Start your app and create two accounts. Give the first one your name and the second one my name (“Mark”).
5. Now, let’s create projects.
rails g scaffold Project name:string
rails g migrate add_account_to_projects.
7. Inside the file generated by Step 6 (inside the db/migrate folder), change it to this:
# xxx_add_account_to_projects.rb class AddAccountToProjects < ActiveRecord::Migration[5.2] def change add_column :projects, :account_id, :integer add_index :projects, :account_id end end
8. Now, add
acts_as_tenant inside your Project model since it’s a tenant of Account.1
# project.rb class Project < ActiveRecord::Base acts_as_tenant(:account) end
9. Since we’re not using subdomains, we need to set the tenant per request. The best place to do this is inside the application controller, and acts_as_tenant gives us a handy filter for this. Change your application controller to this:
# application_controller.rb class ApplicationController < ActionController::Base set_current_tenant_through_filter before_action :find_current_tenant def find_current_tenant # set to Account.first for now, you'll change this later current_account = Account.first set_current_tenant(current_account) end end
10. The tenant is set to
Account.first, so all projects will be scoped to the account under your name (we created this in Step 4).
11. Create a new project at localhost:3000/projects/new.
12. Now look at localhost:3000/projects.
13. Now change your application controller to reflect the second tenant:
# application_controller.rb class ApplicationController < ActionController::Base set_current_tenant_through_filter before_action :find_current_tenant def find_current_tenant current_account = Account.second # this line set_current_tenant(current_account) end end
14. Take another look at localhost:3000/projects. The project you created in Step 11 should be gone! That’s because you’re currently viewing the instance for another account. If this works, nice job – you’ve successfully set up acts_as_tenant.
15. Now, you’ll need to find a way to switch your application controller’s
current_account based on who’s accessing your app or what URL they’re accessing it from. This varies greatly depending on your app, so I’ll turn the reins over to you. For instance, if you set the
current_account per user, you could do something like:
current_account = current_user.account
Or if you want to pull it off the URL, you could define a parameter in routes.rb and pull from it inside your controller:
current_account = params[:account_id]
You could even use a gem like FriendlyId to create nice routes for your users, so if someone from Google was using your app, they could navigate to example.com/google/projects.
So there you have it: a simple way to set up multitenancy without subdomains for Rails 5 applications. Like I said in my Apartment post, you’ve now created a multi-tenant application. Only a small amount of people ever have, so you should feel pretty good about yourself.
When I first used acts_as_tenant, this terminology confused me. I was expecting a “tenant” to be your customer’s whole account – you know, a “tenant” in your application. Nope, that’s wrong! In actuality, it’s just the data that account contains:
acts_as_tenant(:account)means “data inside this model belongs to an account”. ↩︎