- Can I use funkymed/tenant-aware-bundle in a Laravel application?
- No, not idiomatically. It is a Symfony bundle built around Symfony bundle conventions, a DependencyInjection extension, and the Symfony Config component, with no Laravel service provider, facade, or contract implementation. Pulling it into Laravel would be a port rather than an integration. The practical path is to extract its tenant-scoped config pattern and reimplement it natively on Laravel's config repository and middleware.
- What does funkymed/tenant-aware-bundle actually do?
- It is a Symfony bundle for multi-tenant applications that makes Doctrine entities tenant-aware. It handles tenant context and automatic query filtering so each tenant sees only its own data, reducing boilerplate and helping keep tenant data isolated. It is built around Symfony's config tree processing and container-driven tenant resolution rather than Laravel's architecture.
- How do I install and register this bundle?
- In Symfony it is installed via Composer and registered in bundles.php, with a DependencyInjection extension processing the tenant config tree. There is no Laravel installation path, no TenantAwareServiceProvider, and no facade. If you are evaluating it from Laravel, inspect composer.json first and expect to adapt or reimplement the config-loading logic.
- Does it support Laravel 10 or Laravel 11?
- Laravel version support is not applicable because this is a Symfony bundle, not a Laravel package. There are no Laravel service providers, facades, or version constraints in the repo. Treat any Laravel use as a custom port or pattern extraction, not a supported dependency.
- Is this package production-ready for tenant isolation?
- Technical risk is elevated and concentrated in tenant isolation. Multi-tenancy is a security boundary, and configuration leakage between tenants such as credentials, API keys, feature flags, or mailers is a cross-tenant data exposure incident, not a minor bug. With 0 dependents there is effectively no production battle-testing, third-party security review trail, or downstream issue history to mine for edge cases.
- How does tenant resolution work and can I customize it?
- The overview does not specify the resolver, but the bundle assumes container-driven tenant resolution. It may resolve by request host, header, subdomain, or user claim, and whether the resolver is pluggable requires a code read. You should also confirm fallback and default-tenant behavior, and whether failed tenant resolution fails closed or silently defaults.
- Does it load tenant configuration at container compile time or request time?
- This is a key production concern and is not answered by the overview. Symfony's compiled container is shared across tenants, a well-known footgun where cached config can leak between tenants if tenant config is merged at compile time. Loading at request time is more flexible but slower. Inspect the bundle before trusting it with sensitive configuration values.
- What are the alternatives for multi-tenancy in Laravel?
- A Laravel-native design is the safer alternative: a tenant-aware config repository, a ResolveTenant middleware writing the active tenant into a scoped container binding, and per-tenant cache namespacing to avoid shared-cache leakage. Dedicated Laravel tenancy packages exist, but the core idea here is the config-resolution and merge semantics. Treat funkymed/tenant-aware-bundle as a reference implementation rather than a dependency.
- What PHP and Symfony versions does it require?
- The exact constraints are unknown until composer.json is inspected, and that matters because if it pins Symfony 4 or 5 it is already behind. You should also verify whether the package is actively released, what its license is, and whether there is a test suite with isolation-specific cases. Those answers determine the real upgrade and maintenance risk.
- Should I adopt this bundle or fork the pattern?
- With 27 stars and 0 dependents, the package's worth is the idea rather than the artifact. The higher-value path is usually to fork or vendor the repo read-only, extract its config-resolution and merge semantics, and implement a Laravel-native equivalent with idiomatic tooling and a maintainable upgrade path. If your estate is polyglot and already runs Symfony services, adopt it where Symfony lives and mirror the pattern on the Laravel side.