# tenancy/tenancy for Laravel Multi-Domain Websites > tenancy/tenancy separates tenant-specific data while multiple websites run from one Laravel installation. The project suits SaaS applications that need domain-based tenant identification, database management, affects, and hooks, but its installation leaves several design decisions to the application. **tenancy/tenancy** — Run multiple websites using the same Laravel installation while keeping tenant specific data separated for fully independent multi-domain setups. - Repository: https://github.com/tenancy/tenancy - Website: https://tenancy.dev - Stars: 1,341 · Forks: 93 - Language: PHP - License: MIT - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/tenancy-tenancy ## What tenancy/tenancy is intended to solve tenancy/tenancy addresses the case where one Laravel installation must serve multiple websites with independent tenant data. The repository description identifies the intended pattern as fully independent multi-domain setups, which makes it relevant to SaaS products, agency platforms, and other applications where each customer or site needs its own application data while the framework installation remains shared. The project is an ecosystem of packages rather than a single tenant model with one fixed configuration. Its README directs implementers to choose database drivers, identification drivers, affects, and hooks after installation. That separation matters because a multi-tenant application still needs decisions about where tenant records live, how a request identifies a tenant, which application behavior should be affected, and which lifecycle events should trigger custom code. The package supplies the framework for those choices, but the README does not document a universal configuration for all four areas. The repository also identifies itself as the successor to hyn/multi-tenant. That history is useful when comparing migration options or understanding why package names and documentation may differ from older Laravel tenancy projects. It does not mean that tenancy/tenancy preserves the older package’s complete API or configuration without review. The current README points users to the 2.x documentation and describes the repository as the development location for all tenancy packages. ## The tenancy/tenancy package boundaries The installation section exposes four configuration boundaries: database drivers, identification drivers, affects, and hooks. The README does not describe their internal classes, default values, or request lifecycle in enough detail to reproduce them here. Still, the names define the project’s practical architecture. Database drivers concern tenant-specific data storage, while identification drivers determine how the application recognizes the relevant tenant for a request. Affects and hooks provide places for application-specific behavior and lifecycle integration. This arrangement is more configurable than a single-package setup with hard-coded tenant behavior. The trade-off is that configuration is part of adopting the project. An engineer cannot select `tenancy/tenancy`, assume that every tenant-related concern is enabled, and expect a complete multi-domain deployment. The README explicitly makes these decisions mandatory parts of the setup sequence. The repository layout includes `src/`, `test`, and `tests/`, along with multiple PHPUnit configuration files and Composer metadata. The README also links a tests workflow and code coverage badge, so the project presents automated testing as part of its development setup. It does not, however, provide test coverage figures in the text or document which Laravel versions are supported by the current default branch. Those details must be checked in `composer.json`, the `2.x` documentation, or the relevant release before adoption. ## Installing the Laravel tenancy ecosystem The documented starting point is Composer. Install the complete set of tenancy components, or install the framework package and select other packages separately. The README gives these commands: ```bash $ composer require tenancy/tenancy ``` The all-in-one command is the shorter path for trying the ecosystem. After it completes, the application still needs the database, identification, affects, and hooks configuration described above. The command does not itself document a web-server setup, DNS configuration, tenant creation step, or a production migration procedure. If the application needs only selected components, the README gives this alternative: ```bash $ composer require tenancy/framework ``` This selective path is useful when the surrounding Laravel application already supplies or will supply some tenancy behavior. It also increases the number of integration decisions because the implementer must identify which additional packages are needed. The README does not name every optional package or provide flags for selecting drivers, so adding package names beyond the documented framework installation would require consulting the linked 2.x documentation. After installation, follow the linked sections for `Database drivers`, `Identification drivers`, `Affects`, and `Hooks`. Those links are the project’s actual configuration reference. The repository’s local test workflow is documented separately and requires Docker, docker-compose, and Bash. ## Running tenancy/tenancy tests locally The README documents a Docker-based local test path for contributors and evaluators. It requires Docker, `docker-compose`, and Bash. The command below runs the ecosystem test suite in containers. By default, the README says that the tests use the most recent versions of the project dependencies. ```bash $ ./test ``` This command is not a tenant bootstrap script and does not create websites, add domains, or populate tenant data. It is a repository test entry point. Its presence is useful when judging the project’s development workflow, but it does not confirm that a particular Laravel application has been configured correctly. The test setup is separate from application installation. A developer following the installation tutorial still needs to configure the tenancy components in the Laravel application. A developer evaluating the repository can run the documented test command only after providing Docker and Bash. The README does not document database credentials, environment variables, ports, or cleanup steps for the test containers, so those details should come from the repository files or `test` script rather than assumptions. ## Domain-based tenancy and data separation The central operational idea is to let multiple websites share one Laravel installation while keeping tenant-specific data separated. The README does not promise that all tenants use one database table or one database server. In fact, its reference to configurable database drivers indicates that storage behavior is selectable. Engineers therefore need to inspect the chosen driver documentation before making assumptions about schema names, connection switching, migrations, backups, or data export. The identification driver is equally important. In a multi-domain setup, the application must determine which tenant belongs to an incoming website request. The README does not state how domain matching is configured, how central domains are treated, or whether a default tenant exists. It also does not document wildcard domains, custom host resolution, or local development hostnames. Those omissions are significant: a package can provide a mechanism for tenant identification while the application still needs a precise domain-to-tenant configuration. This design makes tenancy/tenancy different from maintaining a separate Laravel installation for every website. The shared installation can reduce duplication, but it concentrates concerns such as request identification, data isolation, and tenant-specific behavior in one application. The project description claims fully independent multi-domain setups, but the README alone does not define the operational guarantees for provisioning, deletion, migrations, or tenant-level backups. Those are adoption checks, not documented defaults. ## Trade-offs and practical failure points The clearest limitation is configuration ownership. The README does not provide a complete application setup example. It tells the developer to decide four areas, which leaves unanswered questions about driver selection, domain configuration, lifecycle hooks, and the exact Laravel integration points. A successful Composer installation can therefore produce a partially configured application. A second limitation is that the repository’s central promise concerns tenant-specific data separation, not every feature of a multi-tenant SaaS. The README does not document billing, role management, tenant provisioning, custom-domain onboarding, per-tenant deployment, background jobs, queues, caching, file storage, or observability. Those concerns may exist elsewhere in the documentation or application code, but they cannot be inferred from this README. An application that expects the package to resolve all of those concerns is using the wrong abstraction. The ecosystem also creates an upgrade surface. The default branch is `2.x`, and recent releases include `v2.5.0`, `v2.4.2`, and `v2.4.1`. Upgrading across versions requires checking the release notes and package constraints, especially when the application uses selectively installed components. The README does not provide an upgrade command or a compatibility matrix, so a migration plan cannot be based on the installation page alone. ## tenancy/tenancy versus hyn/multi-tenant and separate Laravel apps The README explicitly positions tenancy/tenancy as the successor to hyn/multi-tenant. That relationship provides the clearest project-level alternative: hyn/multi-tenant is the earlier tenancy project, while tenancy/tenancy is the current ecosystem being developed here. A team maintaining an older tenancy implementation must compare package APIs, supported framework versions, configuration concepts, and documentation rather than treating the names as interchangeable. The other practical alternative is to run a separate Laravel installation for each website. That approach gives each site its own application process and configuration boundary, at the cost of duplicating installation and release management. tenancy/tenancy instead targets a shared Laravel installation with tenant-specific data separation. The repository description does not quantify deployment savings, and the README does not claim that one approach is faster or cheaper, so the decision should be based on the application’s isolation requirements and operational model. The package is therefore not a drop-in replacement for every multi-site strategy. It is most relevant when central code and a shared Laravel application are desired, with tenancy behavior integrated through selectable drivers, affects, and hooks. Teams needing independent deployment per website may prefer separate Laravel applications unless they have decided that shared code and tenant-level data separation are worth the added configuration. ## Maintenance, releases, and adoption boundaries The repository is not archived, and its last push was on 2026-07-01. The recent release history includes `v2.5.0` on 2026-05-11, `v2.4.2` on 2025-05-10, and `v2.4.1` on 2025-05-03. Those facts indicate a repository with recent recorded changes, but they do not establish a particular upgrade cadence or guarantee compatibility with every Laravel release. The project is licensed under the MIT License. That license permits use and modification under its terms, but license obligations and dependency licenses still need to be reviewed for the intended distribution model. This article does not provide legal advice. The README does not document a project-specific upgrade service, long-term support policy, or migration compatibility matrix. The practical adoption boundary is clear. Choose tenancy/tenancy when one Laravel codebase should serve multiple domains with tenant-specific data separation, and when the team can configure database and identification drivers plus affects and hooks. Choose separate Laravel installations when independent application deployment is more important than shared code. Before selecting either path, inspect `composer.json`, the `2.x` documentation, the selected database and identification drivers, and the application’s provisioning and migration process. ## Conclusion Adopt tenancy/tenancy when a Laravel application needs several websites to share one installation while retaining tenant-specific data boundaries. Do not assume that installing the package alone configures tenancy or completes domain routing. Check the database driver, identification driver, affects, hooks, and the application’s deployment topology first, because the README leaves those choices to the implementer. ## FAQ ### How do I install tenancy/tenancy in a Laravel application? The README documents `composer require tenancy/tenancy` to install all components, or `composer require tenancy/framework` for a selective installation. It then requires decisions about database drivers, identification drivers, affects, and hooks. ### What does tenancy/tenancy separate between websites? The repository description says it keeps tenant-specific data separated while allowing multiple websites to use the same Laravel installation. It does not prescribe one storage architecture because database drivers are configurable. ### Does the tenancy/tenancy README explain tenant setup and production deployment? No. The README links to the 2.x documentation for database drivers, identification drivers, affects, and hooks, but it does not provide a complete tenant provisioning or production deployment procedure. ## Sources - [License: MIT](https://github.com/tenancy/tenancy/blob/2.x/LICENSE) - [Project website](https://tenancy.dev) - [README](https://github.com/tenancy/tenancy/blob/2.x/README.md) - [Releases](https://github.com/tenancy/tenancy/releases) - [tenancy/tenancy on GitHub](https://github.com/tenancy/tenancy) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tenancy-tenancy