854
Multi-tenancy
candidate
Aurélien Georget
It might happens that you're going to develop a website which includes a blog. It could be interesting to split the APIs into two different projets. However, it can be annoyed to deploy on two different servers for such a little API. That's why the multi-tenancy is interesting!
The multi-tenancy (or multi-projects) changes the architecture of an application to allow multiple projects in a single Strapi application. Each project is fully independent, you can use different databases, configurations, plugins, etc.
More details https://github.com/strapi/strapi/issues/1465
Daniel Varentsoff
In our application we have several departements and editors / creators should be responsible for editing only content belongs to their departement.
We solved it with custom roles named as departement and a middleware which restrics access to specified APIs by taking departement id by user role and the field of departement in entity.
But, as you can see, it is not really the most comfortable way, so having some sort of group/tenant management might be a great feature.
Also can see that one of the possible solution is to make a "Can edit when" and some custom like content.departementID = user.departementID, but can't find any docs related to extension of rules.
M
MGRV
weird to think I originally post my comment for this back in 2018.
Lilith River
I plan to use Strapi for a 1-2 person team managing 8+ website domains with Astro 2. I don't want or need separate permissions and databases, but I'm hesitant to adopt Strapi without a clear definition of what's feasible/easy and what's not when it comes to managing a lot of different websites.
T
Torinagrippa
This isn't a hard engineering problem to solve with a K8 cluster. We've been doing it for over a year. Given that this is such an edge case (and that engineering teams can easily solve it) I hope this does not move forward. The core team's time is much better spent on things that benefit the community at-large, especially while other areas of the v4 platform need improvements to remain competitive.
Igor Novosel
Maybe the simplest way to implement multi tenancy would be to use the same database, but in Admin and API enable filtering content and users based on their organization. Admin users should have option to limit data/content type access only to specific organizations. You could check Directus for some ideas 😉
D
Donald Osgood
Igor Novosel: Great thought, I am using Strapi as a mutlti-tenant solution. I ended up tweaking some pages, then patched it and also via the extensions Content-Manager/Upload/Permission adjusted some quires via strap-server.ts. I plan to post an article over the holidays.
Kevin Vugts
Igor Novosel: This is bad practise in terms of data isolation. I wouldn't say there is no use case for it. But in terms of security most multi tenant systems nowadays have a form of data isolation, in other words, a database per instance / tenant.
itai@alphadeltas.com
Kevin Vugts: I second that. Try deleting data for some ex-customer, from a table of 1 Trillion rows, and you'll see why not isolating data is a bad idea :)
Kevin Vugts
itai@alphadeltas.com: I just said that. I actually applaud applying data isolation by creating a database instance per user.
itai@alphadeltas.com
Kevin Vugts: I meant that I agree with you :D
Kevin Vugts
itai@alphadeltas.com: I am sorry. I misunderstood! :D
Slava Kurilyak
+1 for allowing Strapi customers to build their own SaaS applications on top and let Strapi handle the API, security, and data storage for them.
Derrick Mehaffy
candidate
Kevin Vugts
Derrick Mehaffy: Awesome! 🚀
muro
Derrick Mehaffy: Great! Hopefully with Strapi Cloud launch.
Kevin Vugts
Please take this into consideration as it's one of the most important features as of this moment. We know this involves a lot of changes in the strapi back-end, but we think this is the best moment as things in v4 have changed dramatically anyway.
Dean
sad that i've to leave my fav open source cms and go for paid one because of one feature
Vladimir Kudinov
This is the second top voted feature request. Why it still be ignored?
Marcin Stawowczyk
Vladimir Kudinov: It's complicated to implement.
H
Hi
Marcin Stawowczyk: Not particularly, it doesn't have to be that complicated. You could have separate database definitions per project set in the config file and role based access to each project for users if you want full data autonomy or you could simply have a relationship on all model records to a project table.
Marcin Stawowczyk
Hi: So why do you think they didn't implemented it yet?
H
Hi
Marcin Stawowczyk: lack of will? Other, more pressing (to them) issues to resolve?
Load More
→