Admin Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for the "screen fleet" admin surface. The 2.2.1 release adds a screen administration feature to os2display/admin-bundle, which means CRUD-style management of physical displays (create, edit, group, assign to channels) now lives in the bundle instead of being custom-built. That shifts the build-vs-buy line: if screen management was on your roadmap as an internal admin tool, this is a candidate to inherit rather than fund.
• Scope of the MVP for a digital-signage admin. The addition signals that the package's admin layer covers the object model most signage deployments need first — screens as first-class, administrable entities. This supports deferring investment in a bespoke provisioning/administration console until you've validated that the bundle's model (screens, channels, content assignment) matches your operational vocabulary.
• Roadmap sequencing for a signage or place-based-display product. If your roadmap has a "manage displays" epic, this release moves the dependency from "must build" to "must evaluate and integrate." It also implies screens are now a stable enough concept in the package's domain model for the maintainers to expose them in admin — a reasonable signal to plan UI work on top rather than beside it.
• Operational model decisions. A screen admin surface is where you encode decisions about who owns a display, how displays are grouped (by site, by region, by campaign), and how content gets targeted. Adopting this bundle commits you to a specific grouping/assignment model; that's a product decision worth naming explicitly rather than discovering during integration.
• Use cases it unlocks. Municipal/campus/retail display fleets where a non-technical operator needs to register a new screen and place it in a channel without developer involvement — the classic "ops team self-serves" requirement.

When to Consider This Package

Consider it when:

• You are building on Symfony, or at least on a PHP stack willing to run a Symfony bundle. This is a Symfony bundle, not a Laravel package — the admin UI, routing, and service wiring follow Symfony conventions. In a Laravel codebase this is an integration project, not a composer require and go.
• Your domain is digital signage / place-based display: screens, channels, playlists, scheduled content. If you are building something adjacent (e.g. a generic asset manager), the domain model will fight you.
• You need an operator-facing admin ahead of a public API or player client. The admin bundle is the back-office half; expect to still own or integrate the player/display client and the content pipeline.
• You are comfortable inheriting upstream's UX and data model for screen administration and extending around it, rather than specifying your own.
• You can absorb open-source governance risk — community-maintained bundles move at contributor pace, and a single "add screen admin" PR in a point release is a reminder that feature velocity is lumpy.

Look elsewhere when:

• You need a SaaS signage product and screens are a commodity — buying (Screenly, Yodeck, OptiSigns, etc.) will beat self-hosting an admin bundle on total cost.
• You require deep customization of the screen-provisioning hardware flow (device pairing, firmware, EDID/display-control telemetry). This bundle is administration of records, not device management.
• Your team is Laravel-only and the cost of standing up Symfony just for admin outweighs building screens CRUD in your existing app — likely a week or two of work for a scoped screen model.
• You need vendor SLAs, support contracts, or a published security-response process.

How to Pitch It (Stakeholders)

To executives: An open-source component we're evaluating for the display-management side of the product just gained built-in screen administration. That's a chunk of back-office functionality — registering and organizing displays — we would otherwise have had to design, build, and maintain ourselves. It's a reason to shorten, not lengthen, the build estimate for the admin console. The caveat is that this is a community-maintained Symfony bundle, so we'd be adopting someone else's data model and release cadence; the recommendation is a time-boxed spike to confirm fit, not a commitment.

To engineering: Release 2.2.1 of os2display/admin-bundle adds screen admin (PR #25), extending the bundle from channel/content administration into screen management. Treat it as a feature-complete-ish admin layer over the signage domain model. Two things to validate in a spike: (1) whether the screen/channel model maps cleanly onto our grouping and targeting requirements, and (2) the integration cost of a Symfony bundle in our stack — service container, routing, auth, and template conventions all need a home. Also note the release cadence is contributor-driven and this is a point release carrying a notable feature, so pin versions and read diffs rather than tracking dev-main.