Multi Site Bundle Laravel Package

Product Decisions This Supports

• Multi-site vs. single-site architecture: Forces the team to decide early whether distinct brands/locales/regions share one codebase, one kernel, and one database, or get separate deployments. This bundle encodes the "one app, many sites" position and gives you a concrete implementation to cost against the alternative.
• Host vs. path vs. locale routing strategy: The bundle's core value is a pluggable routing strategy (host-based site-a.example.com, path-prefix /de/, or locale-driven). That is a genuine product decision — it changes SEO structure, cookie scoping, CDN config, and how marketing links are built. Use it to settle that decision in a design doc rather than in code review.
• Site configuration as first-class data: Site metadata (theme, locales, content roots, feature flags per site) living in configuration rather than scattered if ($host === ...) checks. This is the piece most worth copying even if you don't install the package.
• Roadmap sequencing: Supports a phased plan — Phase 1, register sites and route by host; Phase 2, per-site configuration/theming; Phase 3, per-site content or data isolation. Each phase is independently shippable.
• Build vs. buy: A useful benchmark for scoping. If your multi-site layer is genuinely just "resolve current site from request, apply config, expose to templates," the internal build is small — and this package shows you the shape of it.
• Use cases it legitimizes: Regional/country site rollouts, brand portfolios under one ops team, campaign microsites that must reuse shared auth and components, and staging-to-production parity across several domains.

Important caveat for the decision record: this is a Symfony bundle, not a Laravel package. On a Laravel stack it is not adoptable as-is — it is a reference architecture and a spec, nothing more.

Update from release 1.3.0 (informational): the project has added Symfony 7 support, PHPStan static analysis, a pinned php-cs-fixer toolchain, and a changelog-enforcer check on pull requests. That is a real but modest maturity signal — the codebase is now analysed and CI-gated, and the supported-version question that blocked a Symfony evaluation is answered. It does not change the adoption calculus for a Laravel team, and it does not change the community-size risk. Version 1.3.0 should be treated as the baseline for any reference-reading or spike work.

When to Consider This Package

Consider it when all of the following hold:

• The application is Symfony. Symfony 7 is now explicitly supported as of 1.3.0 (prior releases targeted Symfony 6-era stacks); still verify the specific minor versions you run against the bundle's composer.json before committing.
• Your "multi-site" need is shallow: shared database, shared users, different hosts/paths, and per-site configuration. No per-tenant data isolation requirement.
• The team is comfortable vendoring or forking a low-traffic dependency and owning it — treat it as internal code you happen to have downloaded.
• You want a working reference to shorten your own design phase, or you need something running this sprint and can accept the maintenance burden.

Look elsewhere when:

• The stack is Laravel. Use stancl/tenancy or spatie/laravel-multitenancy; both are maintained, widely adopted, and cover database-per-tenant isolation this bundle does not. The 1.3.0 Symfony 7 work does not change this at all.
• You need real multi-tenancy — per-tenant databases, queues, storage, migrations. This is site configuration and routing, not tenant isolation.
• Maintenance risk is unacceptable. The adoption numbers have not moved: two stars and zero dependents means no community to absorb a breaking change, no Stack Overflow surface, and effectively a single point of failure. 1.3.0 shows one maintainer doing hygiene work (a single new contributor, tooling/CI PRs, no feature work) — that is better than abandonment but is not a bus factor. For anything on the critical path, that is still a disqualifier.
• You need an admin UI, per-site asset pipelines, or per-site search/indexing. Out of scope, and unchanged by this release.
• You are on a long-lived product. The cost of a small internal implementation is likely lower than the lifetime cost of owning an orphaned dependency.

How to Pitch It (Stakeholders)

To executives: We are evaluating a small open-source component for serving several brands or regions from one application. It is MIT-licensed and free, and it would let us launch additional sites without standing up additional infrastructure — a meaningful reduction in hosting and on-call cost. The component is now on a current release (1.3.0) that adds support for the latest framework version and introduces automated code-quality checks, so it is better maintained than when we first looked. It is still a very low-profile project (two GitHub stars, no downstream users), so I am not recommending we depend on it in production. I am recommending we use it as a reference design and build a thin internal layer modelled on it. That gives us the same capability with no third-party maintenance risk, at an estimated effort of a few days rather than the multi-week scope of a full multi-tenant platform.

To engineering: The bundle solves two problems worth solving: resolving the current site from the request (host or path strategy) and exposing per-site configuration to the rest of the app. That abstraction is the right one and we should adopt the pattern. We should not adopt the dependency — it is a Symfony bundle, our stack is Laravel, and the adoption signal is still too weak to justify ownership. Read the code at tag 1.3.0 (it is now PHPStan-clean, which makes it a better spec to read than earlier versions), and spend a timeboxed spike implementing site resolution and configuration scoping ourselves, with this repo as the reference.

Recommendation: Adopt as a design reference; reject as a dependency. 1.3.0 improves the reference value (Symfony 7 support, static analysis, CI gates) but does not move the dependency decision. Revisit only if we move to Symfony and the upstream project gains dependents or a second active maintainer.