- What is tenancy/framework and should I install it directly?
- tenancy/framework is the low-level engine behind tenancy/tenancy. It wraps Laravel's application and kernel bootstrap so tenant applications can be created, booted, and torn down inside one PHP process. Most teams should consume it transitively through tenancy/tenancy, not add it directly unless an architecture exception is approved.
- How is tenancy/framework different from tenancy/tenancy?
- tenancy/tenancy is the higher-level package developers normally use. tenancy/framework supplies the application-swapping primitives, lifecycle hooks, and tenant-aware container indirection that tenancy/tenancy composes into a usable API. Calling the framework package directly means owning a lower-level internal API.
- Which Laravel and PHP versions does tenancy/framework support?
- The provided overview does not publish a tested support matrix. You must verify the illuminate/* and PHP constraints in the package composer.json against your current Laravel version and your next two planned upgrades. Do not assume compatibility, because the dangerous failure mode is an install that boots but misbehaves.
- How do I install tenancy/framework in a Laravel application?
- Add tenancy/tenancy to the application and let Composer resolve tenancy/framework transitively. A direct Composer require of tenancy/framework should require an explicit architecture exception because it pins you to an internal API. After install, prove isolation in CI rather than relying on manual QA.
- Can tenancy/framework handle row-level multi-tenancy on a shared database?
- It is not designed for simple row-level scoping on shared tables. That requirement is usually better solved with a global scope and middleware. Using an application-swapping framework for shared-table scoping is over-engineering and adds debugging cost.
- Does tenancy/framework work with Laravel queue workers and Octane?
- Yes, long-running processes are a primary reason the package exists. It provides lifecycle and container primitives for booting tenant applications inside queue workers and Octane. However, container or static state surviving a context switch is the critical leakage risk, so test worker and Octane paths explicitly.
- How should I test tenant isolation with tenancy/framework?
- Use a bidirectional isolation test suite in CI. A tenant context must be unable to read central data, and a central context must not leak tenant state. Include long-running worker and Octane scenarios because silent cross-tenant leakage is most dangerous there.
- What are the production risks of tenancy/framework?
- The main risks are cross-tenant data leakage, breakage from Laravel bootstrap internal API changes, and a small maintainer base with no commercial backing. The package is powerful but fragile because it deliberately couples to framework internals. Treat adoption as a platform decision, not a feature-level choice.
- Is tenancy/framework actively maintained and commercially supported?
- The package has a very small contributor base, about 13 stars, and no stated commercial backing. Its adoption is masked because most teams use it through tenancy/tenancy. Before a go decision, identify a sponsorable maintainer or plausible commercial support route and confirm the disclosure process for leakage-class bugs.
- What alternatives are there to tenancy/framework for Laravel multi-tenancy?
- If you need only row-level scoping, use global scopes and middleware instead of an application-swapping framework. If you need hard tenant isolation with separate databases and per-tenant bootstrapping, use tenancy/tenancy, which composes tenancy/framework. The overview does not name other packages, so evaluate any alternative against your required isolation model.