Devserver Bundle Laravel Package

Product Decisions This Supports

• Dev environment / developer-experience roadmap: informs whether to invest in first-party local tooling (Docker Compose, Sail/Herd, Symfony CLI) versus adopting a community bundle for local subdomain routing and asset compilation.
• Build vs. buy vs. borrow: the package's two headline features — wildcard/subdomain dev hosting and automatic asset compilation — map directly onto capabilities already shipped by Symfony's own tooling (Symfony CLI local web server, Webpack Encore/Vite). This is a "borrow, then replace" decision at best, not a strategic build.
• Use-case validation for multi-tenant work: useful as a reference design if the roadmap includes subdomain-per-tenant routing and we want to prototype that locally without standing up DNS or a reverse proxy.
• Stack-fit check: the package is a Symfony bundle, not a Laravel package. Any decision record should flag this explicitly — it is not adoptable in a Laravel codebase without forking, which converts a "dependency" decision into an "internal maintenance" decision.
• Not a product differentiator: nothing here touches customer-facing capability; treat it purely as an engineering-enablement line item with no revenue or retention impact.

When to Consider This Package

Consider it only when all of the following hold:

• The codebase is Symfony (this is a bundle; it will not work in Laravel).
• You are on an older Symfony line and cannot adopt the Symfony CLI local web server for subdomain support.
• You specifically need per-request subdomain routing in local dev and containerized/VM-based alternatives are off the table for the team.
• You are willing to vendor or fork it, because the maintenance signals are poor.

Look elsewhere when:

• You are on Laravel. Use Laravel Sail, Herd, or Valet; the subdomain problem is already solved.
• You are on modern Symfony. The Symfony CLI (symfony serve) plus Encore/Vite covers subdomains and asset compilation with a maintained, first-party toolchain.
• Maintenance risk matters. 0 stars, 0 dependents, and an apparent lack of activity mean no security review, no CVE response, and no upgrade path. A dev-only tool with zero dependents is a supply-chain and onboarding liability disproportionate to the small convenience it provides.
• You need reproducibility. Ad-hoc dev servers drift from CI and production; Docker Compose or DDEV gives you parity that this bundle cannot.

How to Pitch It (Stakeholders)

One-line: A small, unmaintained Symfony dev-server helper that adds local subdomain support and automatic asset compilation — features now covered by official Symfony tooling, so we should not adopt it.

For executives: This is a developer-productivity convenience, not a product capability. It has no adoption (0 stars, 0 dependents) and no maintenance signal, so the expected benefit is small and the support cost is unowned. Recommendation: do not adopt; if the underlying pain is real, fund a short spike using supported tooling instead.

For engineering: It is a Symfony bundle and incompatible with our Laravel stack without a fork. Even in a Symfony context, Symfony CLI plus Encore/Vite supersedes both of its features. The only defensible use is as a design reference for wildcard subdomain routing in local environments. If the team genuinely needs subdomain-per-tenant dev hosting, the cheaper and more durable path is a Docker Compose service with a wildcard TLS cert or dnsmasq/*.localhost resolution — roughly a day of work, fully owned, and identical across machines and CI.