Multidomain Bundle Laravel Package

Product Decisions This Supports

• Consolidation vs. proliferation of web properties. The core question this package addresses is "do we run one CMS instance for N brands/markets, or N instances?" That's a build-vs-buy and opex decision, not just a technical one — one instance means one deployment pipeline, one backup/DR story, one upgrade cycle, one admin surface.
• Market and brand rollout strategy. If launching a new country site or sub-brand is a configuration task (add domain, add content tree, add locale) rather than a new project, it changes how you sequence international expansion and how you forecast delivery cost per market.
• Editorial operating model. Multi-domain-from-one-installation forces a decision: central content team with per-domain scoping, or federated teams with permissions per site. That determines whether you invest in a shared taxonomy, shared media library and shared component library, or let each brand diverge.
• Design system and frontend architecture. Serving multiple domains from one codebase pushes you toward shared templates/themes with per-domain overrides. That's a roadmap commitment to a component library and a constraint on per-brand creative freedom — worth surfacing before the brand teams assume full autonomy.
• Re-platforming scope. If the goal is retiring several legacy CMS installs, this bundle defines what "done" looks like for the merge and what stays out of scope (per-tenant data isolation, per-tenant release cadence).
• Buy vs. build for multisite. The presence of a bundled solution on your existing CMS is an argument for extending rather than procuring a dedicated multisite/multitenant platform — but only if you're already on that CMS.

Caveat for the intake record: despite being filed as a Laravel/PHP package, this is a Symfony bundle for KunstmaanCMS. Correct the record before it reaches a Laravel team — it is not installable there.

When to Consider This Package

Consider it when:

• You are already running KunstmaanCMS and the alternative is a full re-platform to get multi-domain behavior.
• The estate is modest — roughly 2–15 domains sharing a brand family, a hosting environment, and (mostly) an editorial team.
• You have in-house Symfony capability and are willing to vendor or fork the bundle rather than depend on upstream releases.
• Per-domain content trees, host-based routing and locale switching are the actual requirement — you don't need hard tenant isolation, per-tenant billing, or per-tenant data residency.

Look elsewhere when:

• You're a Laravel shop. Wrong framework. Evaluate stancl/tenancy for multitenancy, or a CMS with first-class multisite (Statamic, Craft, Wagtail, WordPress multisite) instead.
• It's greenfield. There is no reason to start a new product on an end-of-life CMS ecosystem to gain a feature that modern platforms ship natively.
• You need independent release cadence per site. Single-instance multidomain means one deploy for everyone. If brand A can't accept brand B's release risk, the architecture is wrong regardless of the package.
• You need vendor support, an SLA, or a security patch commitment. Zero stars and zero dependents is not a popularity contest result — it's an absence of maintainer and community signal. Assume you own the code.
• You need hard isolation (separate databases, per-tenant encryption keys, regional data residency, noisy-neighbor guarantees). Shared-instance multidomain is the wrong shape.
• You're on a current Symfony LTS. Verify compatibility early; older Kunstmaan bundles target Symfony 3.4/4.x-era stacks, and bridging to 5.4+/6+/7 is likely a fork, not a composer update.

How to Pitch It (Stakeholders)

To executives — frame as cost avoidance with an ownership caveat. One CMS serving multiple brands collapses infrastructure, hosting and upgrade costs, and makes launching a new market a configuration exercise instead of a project. That's the upside: lower marginal cost per site, faster market entry, one place to enforce brand and compliance standards. The downside is equally clear: this is an unmaintained component with no community footprint, so the maintenance burden transfers to us. Present it as "consolidate and own a small piece of glue code" — not as adopting a supported product. Do not let it appear on a slide as a strategic platform bet.

To engineering — pitch the pattern, not the package. The bundle is thin: it resolves incoming host to a site definition and scopes content trees and locales accordingly. That logic is a few days of work in any framework. Ask for a timeboxed spike (1–2 days) to read the source as a reference implementation and confirm Symfony-version compatibility. If we proceed, plan from day one to vendor or fork it, pin the version, and add it to the internal patch rotation — treat upstream as read-only inspiration.

Default recommendation: no, unless we are already on Kunstmaan. If we are, adopt with an explicit fork-and-own plan and a documented exit path. If we are not, the correct output of this evaluation is a decision record explaining why we're building multi-domain behavior ourselves on our actual stack — and the answer to "isn't there a package for this?" is "yes, and it's for a framework and CMS we don't run."