Weave Code
Laravel Multisite Laravel Package
appstract/laravel-multisite
appstract/laravel-multisite is a Laravel package for serving multiple websites from one codebase. It resolves the current site by domain, adds site-aware models and middleware, and helps keep content and configuration separated across domains.
Multiple sites on one codebase
Frequently asked questions about Laravel Multisite
- What is appstract/laravel-multisite used for?
- It is a Laravel package for serving multiple websites from one codebase. It resolves the active site from the request hostname and provides site-aware models and middleware to separate content and configuration across domains. It fits a small, fixed portfolio of sites with different routes, views, and databases. It is not a full multi-tenant SaaS framework.
- Does appstract/laravel-multisite support modern Laravel versions like Laravel 9, 10, or 11?
- The last release was in January 2018, which places it in the Laravel 5.x and PHP 7.0 to 7.2 era. There is no evidence of support for Laravel 9, 10, or 11, and modern provider boot ordering, config caching, and route caching may break it. Assume a drop-in install will not work without patching. Verify any target version with a spike before considering it.
- How do I install appstract/laravel-multisite?
- Historically you would install it with Composer, register its service provider, and define your sites so host detection can swap configuration at boot. However, the package has had no release since 2018, so a modern Composer install is not a safe assumption. Do not add it directly to a production application without first checking compatibility. A short internal spike is the safer way to evaluate the pattern.
- How does appstract/laravel-multisite resolve the current site by domain?
- It resolves the active site from the incoming request hostname, typically via Request::getHost(), before configuration, views, routes, and database connections are bound. The package then applies site-aware configuration and middleware for the matched domain. This hostname-based seam fits Laravel's service container and provider model. Behavior outside HTTP requests is not clearly defined and needs explicit testing.
- Is appstract/laravel-multisite still maintained?
- No active maintenance is evident: the last release was 2018-01-22 and there is no CI against current Laravel or PHP versions. That means security and framework compatibility fixes should not be expected. Treat it as reference architecture rather than a production dependency. If you like the approach, reimplement the hostname-resolution pattern in your own small SiteResolver and service provider.
- Does appstract/laravel-multisite work with config:cache and route:cache?
- This is a high-risk area because hostname-conditional config and route loading often break under config:cache and route:cache. Those commands are standard in Laravel production deployments, so the package must be validated explicitly with caching enabled. Do not assume cached configuration will preserve per-domain behavior. Test each site's routes and config after running the cache commands.
- What happens in CLI, queue workers, and scheduled commands where no hostname exists?
- The package is designed around an HTTP hostname, so CLI commands, queue workers, scheduled jobs, and health checks may have no site context. Its behavior in those contexts is not defined by the description and should be treated as unspecified. You need a documented default site or an explicit site context for non-HTTP execution. Otherwise, DB connections, view paths, or config values can leak or fail.
- Can I use appstract/laravel-multisite for multi-tenant SaaS with dynamic tenant onboarding?
- No, it is not suited to multi-tenant SaaS with dynamic onboarding, per-tenant migrations, queue isolation, or cache and session partitioning. It targets a small, fixed portfolio of sites where full tenancy is overkill. If you need provisioning, job scoping, or storage isolation, those concerns are out of scope and must be built around it. A dedicated tenancy framework is a better fit for those requirements.
- How should I test hostname-based site resolution in Laravel?
- Write feature tests that send different Host headers and assert the correct site, config, views, routes, and database connection are used. Include tests with config:cache and route:cache enabled, because caching is where hostname-conditional behavior commonly breaks. Also test CLI, queue, scheduled command, and health-check contexts where no hostname exists. For an abandoned package, keep the tests in a spike and compare against your own resolver implementation.
- What are alternatives to appstract/laravel-multisite for serving multiple sites from one Laravel codebase?
- Alternatives include hand-rolled Route::domain() groups with per-domain config, a maintained tenancy package for heavier isolation, or a small in-house SiteResolver and service provider modeled on this package's hostname-resolution approach. For a fixed set of domains, custom middleware plus route groups can be enough and avoids abandoned dependencies. Choose a tenancy framework only if you need queues, cache, sessions, storage, or per-tenant migrations isolated. For this package specifically, the recommended path is to use it as a design reference rather than a production dependency.
Weaver
How can I help you explore Laravel packages today?