Loggastic Laravel Package

Product Decisions This Supports

• Build vs. buy for audit/activity history — materially improved by v2.1.0. The package previously forced an Elasticsearch cluster; it now ships a storage abstraction with three backends (elasticsearch, doctrine, in_memory). A "who changed what, when" feature can now be scoped against the database you already run. That removes the single largest cost line from the buy case and turns this from "buy, plus a cluster" into "buy, plus two tables."
• Reversibility as a product decision. v2.1.0 is effectively the fallback architecture the earlier assessment recommended building by hand: a storage interface with swappable drivers. That means the buy-vs-build decision is no longer one-way — you can start on relational storage and move to Elasticsearch later without re-instrumenting the domain layer.
• Customer-facing activity feeds. Per-record history in the UI (order changed, invoice edited, role updated) is a retention and trust feature for B2B/SaaS, and a frequent support-ticket defuser. Adoption no longer implies a new piece of infrastructure on the roadmap.
• Compliance and security questionnaire readiness. Supports GDPR access logging and SOC 2 / ISO 27001 "change tracking" controls. The limit is unchanged: this is operational activity logging, not tamper-evident/WORM audit. The Doctrine backend inherits your database's access controls, backups, and retention tooling — which is often easier to defend in a questionnaire than an ES index nobody owns.
• Retention and data-lifecycle policy. Events now land in tables you already back up, or in ES indexes you must explicitly manage with ILM. Either way it forces an explicit retention-window decision instead of an unbounded table that grows forever.
• Roadmap sequencing signal — reversed. Previously this package silently pulled an ES cluster onto the roadmap. Now: if Elasticsearch is already in the stack, you get full-text search over activity metadata; if it is not, the capability costs two tables and a config line. The infrastructure dependency is no longer a gating factor.
• Incident triage and support tooling. On the Doctrine backend you lose ES full-text search over metadata, but gain transactional consistency and direct joins to your users table — usually the better trade for "what did this user do before the bug" at typical volumes.
• Testing strategy as a product-quality lever. storage: in_memory mirrors real backend semantics (sorting, pagination, per-class isolation) in-process. Activity-logging behaviour becomes unit-testable with zero external services — a small but real reduction in CI cost and flake.

When to Consider This Package

Consider it when most of the following hold:

• The application is Symfony (5/6/7) — this is a bundle with DI extensions and Doctrine event subscribers, not a framework-agnostic library. This constraint is unchanged and remains the decisive one for a Laravel team.
• You need entity-level change history (field diffs, actor, timestamp) rather than free-text PSR-3 log lines.
• Either Elasticsearch is already operated by the team and you want full-text search over activity metadata, or you are content with relational storage and want the ES option to remain open. As of 2.1.0 the second path is a supported, first-class configuration.
• You want a thin, forkable integration you can own and patch, and you are comfortable with a small, single-vendor project.

Look elsewhere — or plan a spike/fork — when:

• You are on Laravel. Still the critical caveat, and v2.1.0 only partly softens it. There is no service provider and no Eloquent hooks; integration means porting Doctrine listeners to observers. What v2.1.0 does change: the Doctrine DBAL storage adapter is now a working, readable reference implementation of a multi-backend activity store, so the port is "write an Eloquent storage driver against an existing contract" rather than "invent the whole design." That is a smaller, better-bounded piece of work — but it is still build-on-top-of-someone's-code, and the de-facto Laravel answer remains spatie/laravel-activitylog (DB-backed, or with a custom ES driver). A narrow exception: a Laravel app already running Doctrine ORM entities via laravel-doctrine is a genuinely closer fit than before, since doctrine/dbal is now a hard dependency.
• You need tamper-evident or regulator-certified audit. Unchanged. ES documents are mutable and deletable; the Doctrine backend is ordinary tables with ordinary UPDATE/DELETE rights. No signing, hash-chaining, or WORM guarantee. For SOX/financial-grade audit, buy a dedicated solution.
• The requirement is application log aggregation. That is a Monolog handler + Filebeat/OTel problem, not this.
• The requirement is product analytics (funnels, cohorts, feature adoption). Use PostHog/Amplitude; activity logs are the wrong primitive.
• Procurement requires vendor support or an SLA. The release does not change the adoption picture: single agency maintainer, no meaningful dependent base, bus factor effectively 1. Treat it as "open source you may need to maintain."

Configuration note for the spike: the storage key defaults to elasticsearch, so an install that never sets it will still register ES services and require a PSR-18 client. Setting storage: doctrine is what actively avoids that.

How to Pitch It (Stakeholders)

To executives (one paragraph): We have a recurring ask to show who changed what, and today we have no reliable answer — support reconstructs it by hand and compliance questionnaires are answered with screenshots. Loggastic is a free, MIT-licensed Symfony bundle that records structured activity events, and as of release 2.1.0 it can store them directly in our existing relational database instead of requiring a new Elasticsearch cluster. That changes the economics: the capability is now two database tables and a config line rather than a new piece of infrastructure plus on-call. The remaining trade-off is ownership, not licence cost — it is a small, single-vendor project with negligible industry adoption, and it is Symfony-native, so on our Laravel codebase it is a fork-and-adapt exercise rather than a composer require. Recommendation: on Laravel, default to spatie/laravel-activitylog for the initial ship and treat Loggastic's storage adapter as the reference design if we later need multi-backend flexibility. If any service in the estate is Symfony, this is now a low-risk buy.

To engineering (summary):

• What changed in 2.1.0: the 2.0 storage abstraction now has real backends — doctrine (DBAL schema API, JSON columns, PostgreSQL/MySQL/SQLite, DBAL 3.8+/4.x both in CI, UTC-normalised timestamps, overridable table names, upsert-based tracker writes) and in_memory (full logging semantics in-process for tests). doctrine/dbal ^3.8 || ^4.0 is now an explicit dependency. No breaking changes; default storage is still elasticsearch, so selection is opt-in.
• Fit: strong on Symfony regardless of whether we run ES. On Laravel it remains a port — but the port surface has shrunk from "reimplement lifecycle capture and a persistence model" to "implement an Eloquent storage adapter against a documented contract."
• What it is not: not tamper-evident audit, not log aggregation, not product analytics, and not a substitute for PSR-3/Monolog.
• Cost of ownership: one set of tables (or one ES index), a retention policy on whichever store we pick, and a fork we control. The ES cluster is no longer mandatory, so it drops off the on-call surface if we choose Doctrine.
• Decision requested: approve a timeboxed spike with a go/no-go gate: (1) can we produce the audit view from Doctrine-backed documents, including the sort/pagination semantics the UI needs, (2) what is write throughput and table growth at 10x current event volume, (3) for a Laravel port, how many lines is an Eloquent storage adapter against the existing interface, and (4) what a fork-and-own patch cadence costs per quarter.
• Fallback, slightly revised: DB-backed activity table behind a repository interface — spatie/laravel-activitylog on Laravel, or Loggastic itself on Symfony — with an Elasticsearch driver swapped in later. v2.1.0 is evidence that this seam holds up in practice, which is the strongest argument for keeping framework-specific coupling out of the domain layer.