Laravel Multisite Laravel Package

Technical Evaluation

Architecture fit

• The package targets a genuine need: one Laravel codebase serving multiple branded/regional sites with hostname-based resolution. Architecturally it sits at the HTTP kernel boundary — resolving the active "site" from Request::getHost() before config, views, routes, and DB connections are bound. That is a clean seam and fits Laravel's service-container/provider model well.
• It is best suited to a small, fixed portfolio of sites with meaningfully different route sets, themes, and databases, where full multi-tenant SaaS (per-tenant provisioning, queue scoping, cache partitioning) is overkill.
• It is a poor fit if you need dynamic tenant onboarding, per-tenant migrations, job/queue isolation, or cache/session isolation — those concerns are out of scope and would need to be built around it.

Integration feasibility

• The value proposition is high (shared codebase, isolated config/views/routes/DB) and the integration surface looks small: register a service provider, add site definitions, and let host detection swap configuration at boot.
• The practical blocker is vintage. Last release 2018-01-22 places it in the Laravel 5.x / PHP 7.0–7.2 era. Modern Laravel (9–11) changed service provider boot ordering, config caching, route caching, and the HTTP kernel sufficiently that a drop-in install should be assumed not to work without patching.
• A 2.01 score and 214 stars are consistent with a package that was useful once but has no active maintenance signal. Treat it as reference architecture, not a dependency.

Technical risk

• Abandonment risk (high): no release in ~7 years, no evidence of CI against current Laravel/PHP. Security and framework-compat fixes will not arrive.
• Config/route cache risk (high): hostname-conditional config and route loading frequently breaks under config:cache and route:cache, which are standard in production. This must be validated explicitly.
• Bootstrapping fragility (medium): swapping DB connections and view paths mid-request can leak state into queues, scheduled commands, and CLI contexts where there is no hostname. Behavior outside HTTP requests is undefined by the description.
• Hidden coupling (medium): per-site route files and view namespaces can quietly diverge from the shared app, eroding the "one codebase" benefit over time.
• Licensing/supply chain (low): MIT is permissive and favorable; the risk is technical, not legal.

Key questions

1. Which Laravel and PHP versions are actually in scope for our target apps, and has anyone verified this package boots cleanly on them?
2. Do we need isolation beyond config/views/routes/DB — queues, cache, sessions, storage, scheduled jobs? If yes, this package is insufficient.
3. What happens on CLI, queue workers, and health checks where no hostname exists? Is there a documented default site?
4. Is the expectation to adopt the package, fork it internally, or reimplement the ~hostname-resolution pattern in-house?
5. How many sites, and how often do they change? A fixed set of 3–10 sites behaves very differently from a growing portfolio.
6. What is the rollback story if host detection misroutes traffic in production?

Integration Approach

Stack fit

• Fits classic monolithic Laravel apps with a small, stable set of domains. Does not fit API-only services, single-domain apps, or teams already standardizing on a tenancy framework.
• Where it fits, it substitutes for hand-rolled Route::domain() groups plus per-environment config — a modest but real reduction in boilerplate.

Migration path

• Recommended: do not add the abandoned package as a production dependency. Instead, run a short spike that reproduces its hostname-resolution pattern inside our own SiteResolver/SiteServiceProvider, using the package as a design reference.
• If the package must be trialed, do it on a greenfield or low-traffic app first, behind a feature flag, with the existing single-site behavior as the fallback path.
• For existing single-site apps, migrate incrementally: introduce the resolver with one site defined (behavior identical), then add a second site's config/views/routes, then split its database connection.

Compatibility

• Pin and verify: Laravel version, PHP version, config:cache/route:cache behavior, octane/swoole if used (long-lived workers make hostname-based container swapping unsafe), and queue worker behavior.
• Anything using Laravel Octane or persistent workers should be treated as incompatible until proven otherwise, because per-request config/DB mutation persists across requests.

Sequencing

1. Discovery (1 week): confirm site count, isolation requirements (DB only vs. queues/cache), target Laravel/PHP versions.
2. Spike (1–2 weeks): stand up two sites on a scratch app; test config cache, route cache, CLI, and queue behavior. Decide adopt vs. fork vs. build.
3. Internal implementation (2–3 weeks): implement hostname resolver + per-site config/route/view/DB binding with tests, if the spike shows the pattern is sound.
4. Pilot (1 site pair, 2–4 weeks): run one real secondary site through it, monitor misrouting and cache issues.
5. Rollout: expand site-by-site; keep a kill switch that forces a default site.

Operational Impact

Maintenance

• Adopting the package as-is means owning an unmaintained dependency. Budget for an internal fork with a named owner, or expect to rewrite it within a release cycle.
• Per-site config/views/routes multiply files; without conventions (shared base + explicit overrides), drift becomes the dominant maintenance cost.

Support

• No upstream support channel, no security patch stream, no compatibility guarantees. Internal expertise must be built, not bought.
• On-call needs a documented runbook: how to identify which site a request resolved to, how to add/remove a site, and how to recover from a bad host mapping.

Scaling

• Application scaling is unaffected — this is a routing/config concern, not a throughput one. Each site can scale independently at the database tier.
• Weak spots at scale: config/route cache correctness, and any long-lived worker model (Octane) where per-request state mutation is unsafe. Horizontal scaling of PHP-FPM workers is fine.
• Operational tooling (per-site migrations, backups, monitoring dashboards) must be built per site; the package provides none of it.

Failure modes

• Misrouting: unknown or misconfigured hostname resolves to the wrong site — potentially the wrong database. Highest-severity failure; mitigate with explicit allowlists and a hard default.
• Cache staleness: config:cache/route:cache baking in one site's config, causing all sites to serve the wrong routes.
• CLI/queue ambiguity: jobs and commands executing without a hostname pick up the wrong DB connection.
• Silent config leak: a site missing a config key inherits a sibling's value instead of failing loudly.

Ramp-up

• Low individual learning curve (Laravel developers will read the resolver in an hour), but the operational model — per-site deploys, configs, and databases — is the real onboarding cost.
• Estimate 1–2 days for a Laravel developer to be productive, plus a written internal standard for how sites are defined and how shared vs. site-specific code is organized.

TPM recommendation

• Do not adopt as a dependency. Use it as a design reference and budget roughly 4–8 engineer-weeks to build and pilot an internal hostname-resolution layer with tests, cache-safe bootstrapping, and explicit CLI behavior. Revisit only if the spike shows the package works unmodified on our target Laravel version — which the 2018 release date makes unlikely.