Event Sourcing Dashboard Bundle Laravel Package

Product Decisions This Supports

• Committed to event sourcing as an architecture: This bundle makes the event store, aggregates, and subscriptions observable. It provides the operational layer that makes event sourcing a viable production architecture rather than an opaque liability.
• Build vs. buy on internal tooling: Avoids building a custom admin dashboard for events, aggregates, and subscriptions. The dashboard (store browsing, aggregate inspection, time travel, subscription lifecycle management) is commodity tooling that would otherwise consume engineering sprint capacity.
• Support and debugging workflow: Time travel to any playhead and full state dumps enable support engineers to reproduce the state of an aggregate at a specific moment, reducing escalation to developers.
• Operational control of subscriptions: Boot, pause, reactivate, run, setup, rebuild, and remove subscriptions from the browser. This supports incident response and release/rollout decisions around projection rebuilds.
• Developer experience and onboarding: Browsing registered events alongside their listeners/subscribers, plus the #[Inspect] attribute (description, icon, color, size), lowers the ramp-up cost for new engineers joining an event-sourced codebase.
• Security and deployment posture decision: Disabled-by-default configuration and the explicit "no built-in access control" stance mean this is a development tool first; deciding whether to enable it in production is a real, deliberate product/security decision that requires placing it behind Symfony security.

When to Consider This Package

Adopt when:

• You are building on patchlevel/event-sourcing (requires ^3.8, with patchlevel/event-sourcing-bundle ^3.7). This is a hard prerequisite — it is a Symfony bundle, not a Laravel package, so Laravel teams are not a fit without an adapter strategy.
• Your team is on a supported stack: PHP 8.2–8.5, Symfony 5.4, 6.4, 7, or 8, Twig ^3.20.
• You need to operate an event-sourced system: inspect event stores, debug aggregates, and manage subscription lifecycle, not just write events.
• You are currently on the legacy admin bundle (patchlevel/event-sourcing-admin-bundle): it is no longer maintained, making migration to this dashboard a maintenance-risk decision rather than an optional upgrade.
• Your organization can accept the limited backward-compatibility surface: route names and paths are covered, but Twig templates and controller internals are explicitly not.

Look elsewhere when:

• The system is not built on patchlevel/event-sourcing (e.g., a different event-store library, a Laravel/non-Symfony stack, or a custom event log).
• You require an out-of-the-box secure admin surface. This bundle has no built-in access control and is documented as a development tool; production use requires you to own the security layer.
• You need stability guarantees over Twig templates or controller internals — these are outside the BC policy and may churn.
• Your PHP or Symfony versions fall outside the supported matrix.

Adoption also requires a migration step, not just an install: the package name, bundle class, configuration root (patchlevel_event_sourcing_dashboard.enabled: true), and route names have all changed, and the config and routes import must be updated per the getting-started guide. Assets are served via assets:install or Symfony's asset mapper. Plan for this as a discrete task and a config change, not a drop-in dependency bump.

How to Pitch It (Stakeholders)

For executives: This is the operational control panel for our event-sourced platform. It replaces the unmaintained admin bundle and gives us a supported, stable (1.0.0) way to inspect and operate our event data. The business value is risk reduction and cost avoidance: we are not paying engineers to build and maintain bespoke admin tooling, and when something goes wrong the team can inspect state and manage subscriptions directly instead of improvising.

For engineering leadership: Adopt patchlevel/event-sourcing-dashboard-bundle and retire patchlevel/event-sourcing-admin-bundle, which is no longer maintained. The 1.0.0 release is the first stable version, so we now have a version target. Budget for a migration: bundle class, config root, routes, and package name all change. Requirements are PHP 8.2–8.5, Symfony 5.4–8, and patchlevel/event-sourcing ^3.8 — confirm we are within that matrix before committing.

For security and operations: The dashboard ships without built-in access control and is intended for development use. It is disabled by default, and when disabled registers no controllers, routes, or services. Enabling it is an explicit decision. If we expose it in production, the route prefix must sit behind Symfony security, per the production-usage docs — that is a scoped security task, not a configuration toggle.

Risks to flag: The backward-compatibility policy excludes Twig templates and controller internals, so any deep customization of the UI is our maintenance burden. Route names and paths are covered, which protects our links and deep-linking, but not template-level overrides. Keep customizations minimal to stay close to the supported path.