13 thoughts on “Why do people keep asking about an “official” way to build a multi-tenant app on Laravel?”

  1. At my company, we are using laravel for new development on a customer portal. We are basically building a CRM that our users can use to maintain contacts. This means we need to make sure we don’t let other accounts/users see the wrong information. Took me a while to realize this is the definition of multi-tenancy.

    For us, I’m simply using a few traits and IoC things to make it easier to pull in the “current account” when browsing the website. It usually means adding account\_id automatically to any query, if it is present in the IoC.

    Reply
  2. When I wanted to implement tenancy into my e-commerce system, I was overwhelmed. It isn’t exactly straightforward what it means to implement multi-tenancy. You need to know a lot about the inner workings of Laravel.

    Say you figure out that you need to switch the database connection after you identify the tenant. Your app now works, but then you show one tenant’s data to another because you forgot to make the cache multi-tenant. Then the same thing happens because you forgot to make Redis multi-tenant. And then you want to store files, so you have to think about the structure of the `storage` directory. Is it `storage/app/tenant123/photos` or `storage/tenant123/app`? And how do you manage tenant databases (migrations, seeding, etc)?

    I also felt a lot like having to change my code to be multi-tenant is problematic because I forgot about one model, or one Cache facade call and there’s a data leak.

    When I was implementing tenancy into my app, I decided to first build a [multi-tenancy package](https://github.com/stancl/tenancy) so that others don’t have to face this (and so that I can code my future SaaS projects as if tenancy didn’t exist and let the package automatically everything related to tenancy).

    Before making that package I tried to implement the hyn/multi-tenant package into my project but was [*very* overwhelmed](https://i.imgur.com/gJ6rFJy.png).

    (I don’t mean to put down other packages, I’m simply saying that I created mine because I was overwhelmed with them.)

    If you want to make it easier for developers to implement multi-tenancy, write a documentation page about it, split into two sections — single-database tenancy and multi-database tenancy. With single-database tenancy, explain that model traits should be used, etc.

    Explain all the changes that need to be made and exactly how they should be made (switching DB connection, setting Redis prefix to specific connections, tagging cache and extending `’cache’` in the IoC container, changing filesystem roots (storage_path() and the Storage facade have to be configured separately).

    Speaking of storage, it isn’t as simple as appending the storage root with `tenant123`. I have a section [about that](https://github.com/stancl/tenancy#filesystemstorage) in my package’s docs. (I had to come up with a somewhat ugly hack to correctly change the fs roots).

    Reply
  3. if you want to provide a SAAS platform multi-tenancy is about the only way to go. There are deeper levels of multi-tenancy like Main account and then users with access so that could be another thing to consider

    We have one level where user gets campaign builder, map search, credit purchases etc in the platform for their account

    Then another level of User where its a more or less company account and then sign up users to share the information in the company account (you can go down the road of permissions for users as far as modules they can use and data they can access within the company account but that might be a little difficult for a package)

    Reply
  4. I’d like to jump on this topic – why is multi-tenancy dealt with so differently to multi-user?

    With multi-user, surely you have the same requirements. An entity across which you don’t want to leak data/files. Why does multi-tenancy mean you have to have separate databases and folder structures?

    Reply
  5. It’s often a legal requirement or stipulated as a ‘must-have’ in some finance industry regulations.

    Not saying I agree in every case, but it does seem to go one step further to preventing data leaking possibilities.

    Reply
  6. I’m not sure what “official” multi-tenancy functionality would look like. I’ve been supporting the https://www.laravel-tenancy.com package(s) for a while now, both as a contributor and maintainer, and the one thing I’ve learned is that everyone’s needs are completely different.

    u/themsaid, I mean absolutely no disrespect, but your recent blog posts on multi-tenancy are not really fair to the readers. You make some very good points, but miss the mark on a number of more complex topics, which may lead your readers to believe it’s an incredibly easy topic. As another user has already said on here, what about database switching? What about cache? What about filesystem storage? What about sessions? If you don’t want separate databases per tenant, then you need to make sure you’re keeping all of your tenant data separate.

    Anyway, you’re doing great work, and I do hope you keep at it. If you ever figure out a good way to build dynamic multi-tenant functionality into laravel, I’m all for it. But for now, I think the https://github.com/tenancy packages meet that need quite well.

    To anyone curious about the packages or needing help with implementation, please join our discord server and/or post on our forum (recently started, so not much there). If you’re interested in contributing, we welcome the help! The successor to hyn/multi-tenant is coming along nicely and we hope to have it released soon.

    Reply
  7. Anyone who has asked seems to not even know basic Laravel yet alone how to do multi tenant in a good way. It makes me feel like it’s someone asked to upgrade a legacy system 90% of the time.

    Or a legal requirement. But it seems so easy to do it with Laravel if you have used it for even a single real project that I don’t understand why people have such issues in doing it.

    Reply
  8. my .02 – people are so used to ‘install these packages to do your work for you’ so they expect a multi-tenancy package along with everything else. That you can handle multi-tenancy in 12 lines of code or less is often lost on most people. Everyone wants the “easy” way and a few lines of code is scary.

    Reply
  9. The hardest part I’ve run into is getting routes to to work with both a default domain name, and with a custom domain name.

    Furthermore, using the route () helper to work with both styles of domain names.

    Reply
  10. I think the biggest reason people ask is thst its one of those things that genuinely does sound more complicated than it is. It throws so many theoretical spanners into the work that it breaks the normal train of thought.

    The problem as you’ve stated, is that there are so many different options for how to implement multi-tenancy, and so many side effects that’d have on the rest of the codebase that an official solution would be considerably difficult to achieve without discounting some options, or making life hard for those that don’t want to use it.

    I’ve written an article that goes into multi-tenancy with laravel in quite some detail, and it’s a fairly simple process. It requires more explanation and reasoning than code.

    That being said, there is definitely an interest in it, and I’m working on both a course and packaged solution that hopefully helps those in this situation.

    Reply
  11. Isn’t multitenancy simply a concept of running the same application instance but serving multiple consumers? If I add a global scope to every model that scopes to the current tenant id, this is, by definition, a multi tenancy, right?

    I don’t understand the need for a database-per-customer need. What is the point of this? Leaking data? Well, you have tests that cover that…

    Reply
  12. There’s an abundance of tutorials in the Laravel community that focus on smaller concepts like: toast notification, relating objects, building a blog. These concepts are easy to rip out and replace and don’t have a larger impact on a codebase.

    Multi-tenancy is a larger, more impactful, feature to implement that, if done incorrectly, can really screw a developer over in the long run.

    A developer knows that Laravel provides features, like query scoping, that can make multi-tenancy a breeze. Identifying the right features to use and implementing them the “Laravel way” can be challenging for a beginner.

    When faced with a significant task, like multi-tenancy, I like to mimic the Laravel way and to do that I often look to the official Laravel resources to guide me. It gives me more confidence in my solution and it lets me focus my anxiety on my cruddy business logic–something I can’t always find guidance on.

    Reply

Leave a Comment