Product Decisions This Supports
- Architecture shape: one deployable, many front doors. The bundle's premise — a single Symfony base hosting multiple apps (e.g. public site, admin back-office, partner API) — is a decision to keep one codebase and one deploy pipeline while isolating configuration, routing, and caches per app. This is a real lever for teams weighing a modular monolith against a set of small services.
- Code and vendor reuse. Shared domain models, bundles, and
vendor/ across apps means one upgrade of a shared dependency, one security patch, one CI run. Relevant when the roadmap shows several apps serving the same underlying data.
- Release cadence decisions. Separate kernels let the admin app ship on a different rhythm than the customer-facing app without splitting repositories — a middle ground between "one monolith, one release" and "three repos, three pipelines."
- Build vs. buy signal (weak). The capability is thin: multiple kernel classes and front controllers in one Symfony project are a documented, native pattern. The build cost of replicating this is small, which lowers the value of adopting any third-party wrapper — a useful data point when a team proposes adding a dependency for it.
- Consolidation roadmap input. If product strategy is "reduce the number of Symfony apps we operate," this bundle is a candidate mechanic for staging that consolidation without a rewrite.
- Not a strategic bet. With zero stars, zero dependents, and a Symfony2-era target, this should inform decisions only as evidence about the pattern, not as a platform commitment.
When to Consider This Package
Consider it only under narrow conditions:
- You are already maintaining a Symfony 2.x/3.x codebase that you cannot migrate this quarter, and you need per-app isolation of config and cache today.
- Your team is small, you want one deploy artifact and one ops story, and the apps genuinely share domain code.
- You have read the source and are comfortable vendoring or forking it — treat it as reference implementation, not a maintained dependency.
Look elsewhere — or build the ~100 lines yourself — when any of these hold:
- Greenfield work. Modern Symfony supports multiple kernels natively; no bundle required. Adopting a legacy wrapper adds migration debt on day one.
- Support and security expectations. Symfony2 is end-of-life. Zero dependents means no community triage, no CVE response, no compatibility guarantee with current PHP. Inability to answer "who fixes this in 18 months?" is a stop signal.
- You need independent scaling or deployment. If apps have materially different traffic, compliance boundaries, or on-call ownership, separate services or separate repos with shared Composer packages are the better fit.
- You want real modularity. Bundle-per-domain inside one kernel, or a monorepo with shared packages, delivers most of the reuse benefit with clearer boundaries and active maintenance.
- Procurement/compliance review. No visible license hygiene, CI, or release history makes this hard to approve through any standard dependency gate.
How to Pitch It (Stakeholders)
To executives — one paragraph: A small, unmaintained open-source bundle proposes letting one Symfony application host several apps (admin, public site, API) from a single codebase and single deployment. The idea is worth a look because it can cut infrastructure and upgrade overhead versus running three separate services. The package itself is not a candidate for adoption: it targets an end-of-life framework version and has no users, no maintainers, and no security response. Recommendation: treat it as a design reference, and if the consolidation pattern fits the roadmap, build it natively or fold it into the platform migration already planned. No new vendor dependency, no new support obligation, negligible engineering cost.
To engineering — the short version: This is a thin kernel-bootstrapping wrapper for running multiple kernels off one Symfony base. We're not taking the dependency: Symfony2 is EOL, there are zero dependents, and the capability is native in supported versions. Action: if multi-app hosting is on the table, spike the native multiple-kernel layout in the current framework version, document the shared-vendor and per-app cache/config boundaries, and estimate it — expect it to be small. Flag the pattern, drop the package.