Managing Multiple Brands in Rails: Multi-Tenant Patterns from RobinReach

Scaling a SaaS application is one thing; letting a single user manage multiple brands, each with its own isolated data, is another.
At RobinReach, we faced this challenge head-on: users needed to handle multiple workspaces, each with its own social profiles, posts, and team members, all while switching seamlessly between them.
Here’s how we built it in Rails, and the lessons learned along the way.

The Challenge: Multi-Brand Management

Imagine a user managing three different companies on your platform. Each company has:

• Its own social media profiles
• Scheduled posts
• Team members and roles
• Analytics and performance data

Without proper isolation, cross-tenant data leaks become a nightmare.
Multi-tenancy is not just a database pattern, it’s a mindset for every layer of your application.

Workspace-Based Multi-Tenancy

At RobinReach, we modeled each brand or workspace as a tenant. All core models—Posts, SocialProfiles, Members, are scoped to a tenant. We use a thread-safe Current object to hold the tenant context:

class Current < ActiveSupport::CurrentAttributes
attribute :company
end

This allows all models to reference the current tenant easily:

class Post < ApplicationRecord
belongs_to :company
default_scope { where(company_id: Current.company.id) }
end

With this pattern, every query automatically respects tenant boundaries.

Seamless Workspace Switching

Users expect to switch between workspaces without logging out. We store the current workspace in the session:
def switch_workspace(company_id)
session[:current_company_id] = company_id
Current.company = Company.find(company_id)
end
This ensures that every action like viewing posts, scheduling content, or managing members, is scoped correctly to the selected workspace.

Background Jobs in a Multi-Tenant Environment

Multi-tenancy isn’t just about database queries; background jobs must also respect tenant boundaries.

Lessons Learned:
Always pass the tenant ID to background jobs.

Make jobs idempotent to prevent cross-tenant side effects.

Use Sidekiq queues strategically; high-volume tenants might need separate queues.

Best Practices for Workspace Multi-Tenancy

• Enforce tenant isolation at all layers – models, services, jobs, and controllers.
• Use thread-safe context objects (Current) for tenant information.
• Design for fast workspace switching in the UI.
• Keep background jobs idempotent and tenant-aware.
• Cache per tenant when appropriate to reduce database load.
• Monitor performance per workspace to detect heavy tenants early.

Conclusion

Building a multi-brand SaaS in Rails isn’t just a technical challenge, it’s a design mindset.
RobinReach demonstrates that with careful scoping, background job design, and workspace isolation, you can deliver a seamless multi-tenant experience.

For Rails developers building SaaS platforms, these patterns can save you from future headaches and set your app up for scale.