Jeśli jedna aplikacja ma obsługiwać wiele firm, zespołów albo organizacji — każda z własnymi danymi, użytkownikami i ustawieniami — mówimy o multi-tenancy. Filament 5 ma to wsparcie wbudowane: zamiast budować izolację ręcznie, wskazujesz model tenanta i framework sam skaluje zapytania, nawigację i uprawnienia do kontekstu organizacji. Ten artykuł wyjaśnia, jak to działa, kiedy warto z tego korzystać i na co uważać.
Jak działa multi-tenancy w Filament?
Włączasz je w konfiguracji panelu, wskazując model tenanta (np. Team, Organization, Company). Od tego momentu
- zasoby są automatycznie zawężane do bieżącego tenanta — zapytania list i relacji dostają scope po kluczu organizacji,
- użytkownik przełącza się między organizacjami (albo trafia do tej, do której należy), a panel pamięta kontekst,
- rejestracja nowej organizacji i zapraszanie użytkowników mają gotowe przepływy,
- uprawnienia działają w kontekście tenanta — rola „manager" znaczy „manager w tej organizacji".
To fundament aplikacji SaaS i portali B2B, w których jedna instancja obsługuje wiele firm.
Kiedy multi-tenancy ma sens — a kiedy nie
- SaaS dla firm — każdy klient widzi tylko swoje dane, jedna baza, jedno wdrożenie. Tak, to ma sens od pierwszego dnia.
- Portal B2B dla partnerów — partnerzy (np. dealerzy, agenci) obsługują własnych klientów w swoim kontekście.
- Agencja zarządzająca wieloma markami — jedna aplikacja, wiele marek z osobnymi zespołami.
- Zwykły panel wewnętrzny — jeśli dane dzieli jeden zespół, multi-tenancy to nadmiarowa komplikacja. Wystarczą role i scope po zespole (uprawnienia i role w panelu Filament).
Wskazówka: Multi-tenancy włączaj świadomie — to decyzja architektoniczna, nie ustawienie. Dodanie tenanta później, gdy dane już się wymieszały, jest kosztowną migracją. Z drugiej strony w projektach jednozespołowych bywa zbędnym narzutem.
Subdomeny czy ścieżka?
Filament obsługuje oba modele identyfikacji tenanta
- ścieżka (
app.pl/zespol/abc) — najprostsza, działa bez konfiguracji DNS, dobra na start i dla mniejszych wdrożeń, - domena/subdomena (
abc.app.pl) — lepsza dla SaaS: łatwiejszy branding, osobne certyfikaty, prostsze rozliczenia i SEO; wymaga obsługi wildcard DNS i certyfikatów.
W projektach SaaS zaczynamy zwykle od ścieżki, a na domeny przechodzimy, gdy klienci zaczynają prosić o własny adres — migracja jest wtedy kwestią konfiguracji panelu, nie przepisywania aplikacji.
Na co uważać przy wdrożeniu
- Izolacja danych to test, nie założenie — napisz testy, które próbują dostać się do rekordów innego tenanta (po ID, przez relacje, przez akcje masowe). To najczęstszy wektor błędów w aplikacjach multi-tenant.
- Indeksy w bazie — każda tabela z danymi tenantowymi powinna mieć indeks po
tenant_id; bez tego listy w panelu zwolnią przy wzroście danych (optymalizacja wydajności). - Pliki i załączniki — media per tenant trzymaj w osobnych katalogach (np.
tenants/{id}/...), żeby URL-e nie wyciekały między organizacjami. - Zaproszenia i offboarding — przepływ „zaproś użytkownika do organizacji" i „odbierz dostęp" zaprojektuj od początku; w praktyce to najczęściej zmieniane elementy panelu.
Najczęściej zadawane pytania
Czym jest multi-tenancy w panelu administracyjnym?
To obsługa wielu organizacji (tenantów) w jednej aplikacji: każda ma własnych użytkowników, dane i ustawienia, a system pilnuje, żeby nie widzieli się nawzajem. W Filament to wbudowany mechanizm — wskazujesz model tenanta i framework scope'uje zapytania oraz uprawnienia.
Kiedy wdrożyć multi-tenancy w aplikacji?
Gdy produkt ma obsługiwać wiele firm lub zespołów na jednej instancji — SaaS, portale B2B, platformy dla partnerów. Jeśli dane dzieli jeden zespół, wystarczą role i uprawnienia; multi-tenancy warto odłożyć.
Subdomeny czy ścieżka dla tenantów?
Na start ścieżka — prostsza i bez konfiguracji DNS. Subdomeny lub własne domeny mają sens w SaaS, gdy klienci oczekują brandingu i osobnych adresów. Filament obsługuje oba modele, więc przejście między nimi nie wymaga przepisywania aplikacji.
Jak zapewnić izolację danych między tenantami?
Scope zapytań po tenancie (automatyczny w Filament), indeksy po tenant_id, osobne katalogi plików oraz testy automatyczne próbujące sięgnąć po dane innego tenanta. Izolacja bez testów to założenie, nie fakt.
👉 Budujesz SaaS albo portal B2B dla wielu organizacji? Projektujemy aplikacje multi-tenant w Laravel i Filament — zobacz Laravel Development lub napisz na kontakt@informatix.com.pl.
📖 Zobacz również: Filament i Livewire — panele administracyjne w Laravel, panel administracyjny w Laravel krok po kroku oraz case study CRM dla agentów ubezpieczeniowych.