Implementing Multi-Tenancy in Phoenix 1.8 - Single vs Multi-Organization Approaches

Phoenix Forum Chat / Discussions
, ,
1

[Guide] Implementing Multi-Tenancy in Phoenix 1.8 - Single vs Multi-Organization Approaches

Hello Elixir Community!

I’m excited to share a comprehensive resource I’ve put together on implementing multi-tenant applications in Phoenix 1.8. If you’re building a SaaS application or any system that needs to handle multiple organizations/tenants, this might save you a lot of research time!

What’s covered?

I’ve documented two distinct approaches to multi-tenancy with complete implementation guides:

  1. Single-Organization Model - Each user belongs to exactly one organization at a time

    • Simpler implementation with organization_id directly on users table
    • Straightforward role-based permissions within the single organization
    • Includes system administrator implementation that spans across organizations

  2. Multi-Organization Model - Users can belong to multiple organizations simultaneously

    • Uses a join table (organization_memberships) for flexible organization membership
    • Different roles in different organizations (admin in one, member in another)
    • Organization switching functionality

Both approaches leverage Phoenix 1.8’s new Scopes feature, which is a game-changer for implementing secure multi-tenancy by helping ensure proper data isolation between tenants.

Implementation Details

The documentation includes:

  • Complete database schema designs and migrations
  • Integration with phx.gen.auth
  • Role-based authorization using Bodyguard
  • LiveView implementations with Phoenix 1.8 components
  • Detailed implementation checklists to guide the development process
  • System administration functionality for cross-organization management

Repository Link

You can find everything here: GitHub - ZenHive/OrgsDocs

Which Approach Should You Use?

  • Single-Organization: Great for simpler applications where users typically belong to just one organization at a time (like most internal team tools)
  • Multi-Organization: Better for platforms where users regularly collaborate across multiple organizations (like freelancer platforms, consultancies, etc.)

I’d love to hear your thoughts, experiences, or questions about implementing multi-tenant applications in Phoenix. Have you tried different approaches? Any challenges you’ve faced? Any improvements you’d suggest to the implementations?

Happy coding!

26 Likes
2

Looks like a great resource, thanks for sharing it!

I’ve recently implemented the Multi-Organization Model with schema-per-tenant approach in the database and Organization slug used as subdomain in the URL.

Getting cookie sessions and content security policies all working correctly when redirecting between subdomains was a little tricky :sweat_smile:

Ash made the remaining work fairly simple, just had to map the Conn.assigns.scope to the tenant and actor opts when calling into the application layer from the web layer.

One challenge was how to implement tests that would create new tenants and trigger the tenant schema migrations, which can be quite slow. In the end we added a test_seeds script to pre-create a few tenants and randomly select one in each test. Seems to work well with the ecto sandbox.

3 Likes
3

4 posts were split to a new topic: Session cookies and CSP

4

Hello.

Thanks for your content. I’ve managed to create a tiny Multi-tenancy app following your instructions:

1 Like