Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message
Audit Bundle

Audit Bundle Laravel Package

pbweb/audit-bundle

Symfony bundle for auditing Doctrine entities: it automatically tracks create, update, and delete changes through Doctrine listeners, recording who changed what and when. Configurable storage and a simple API make it easy to review entity change history in your application.

View on GitHub
Deep Wiki
Context7

Easily extendible Symfony Bundle to create an audit log

Frequently asked questions about Audit Bundle
Can I use pbweb/audit-bundle in a Laravel application?
No. pbweb/audit-bundle is a Symfony bundle, not a Laravel package, so it depends on Symfony's Bundle class, DependencyInjection extension, YAML or XML service configuration, and compiler passes, none of which exist in Laravel's service-provider lifecycle. There is no realistic path to installing it via Composer into a Laravel app and having it work. Treat it as a reference implementation of an audit pattern rather than a dependency.
What does pbweb/audit-bundle actually do?
It is an extendible Symfony bundle that creates an audit log for Doctrine entities. It tracks create, update, and delete changes through Doctrine listeners and records who changed what and when. Storage is configurable and a simple API lets you review an entity's change history.
Why isn't a Symfony bundle compatible with Laravel?
Symfony bundles are wired through a Bundle class, a DependencyInjection extension, and compiler passes that Laravel never invokes. Laravel resolves services through its own container and service providers, so the bundle's configuration and bootstrapping simply never run. The audit concept is stack-agnostic, but the delivery mechanism is not portable.
What should Laravel developers use instead for audit logging?
Use a mature Laravel-native package such as owen-it/laravel-auditing or spatie/laravel-activitylog, both of which have meaningful adoption, active maintenance, and documented Laravel version support. Building a thin audit layer over Eloquent model events plus a queued writer is also viable and takes roughly a sprint. Porting the bundle's domain model only makes sense if it encodes non-obvious logic like field-level diffing or revision chaining.
Does the bundle record who made a change and when?
Yes, capturing who changed what and when is the core purpose of the bundle per its description. The open question is how actor identity is resolved in non-HTTP contexts such as CLI commands, queue workers, and system jobs, which the provided metadata does not document. You would need to read the source or ask the maintainer to confirm that behaviour.
How does pbweb/audit-bundle capture entity changes?
The blurb states it uses Doctrine listeners, which typically means prePersist or onFlush event subscribers coupled to ORM flush semantics. That coupling does not translate to Eloquent observers, so any port has to rethink the capture mechanism. Verify against the source whether an explicit service call is also supported.
Is pbweb/audit-bundle actively maintained?
There is little evidence of it. The package has 1 star and 0 dependents, meaning no production usage signal, no downstream issue reports, and no community-vetted edge cases. It is a single-maintainer project with an unstated support matrix, so abandonment risk is high. The MIT license is the clear positive, since it permits forking and vendoring.
What PHP and Symfony versions does it support?
The available metadata does not state a version constraint matrix for PHP, Symfony, or Doctrine. An audit bundle of this vintage may predate Symfony 5 or 6 and PHP 8.1, in which case it will not run on a modern runtime at all. Check composer.json and the last commit date before spending any evaluation time.
Are there security or PII concerns with using an audit log bundle?
Yes, and they matter more than usual because an audit trail is a high-value target that records actor identity and full change history. Audit tables frequently capture PII inside before-and-after diffs, and this package has no documented redaction, field exclusion, or retention policy. It also has no discoverable CVE or advisory process and no dependents to surface one.
Does the audit write share the business transaction, and why does that matter?
It is not documented in the provided metadata, and both answers carry risk. If audit writes share the business transaction, a logging failure can roll back or block the business operation. If they do not, you get silent gaps in a trail that is often relied on for compliance, so confirm the behaviour before depending on it.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console
pnscripts/filament-broadquill-lite
pnscripts/laravel-sentfold-lite
vleap/mx-sdk-laravel-internal
twidpay/utils
htetmyathlaing/scout-elasticsearch-driver
artisan-toolbox/front-awesome
ls/client-assistant
users-au/laravel-client
robertmarney/lara-hierarchial-collections
simonschaufi/rule-doc-generator
emissaoja/emissaoja
blackbricksoftware/gravityforms-civicrm-form-processor
al-rahabi/fancy-crud
jinas/dhivatar-component
mltstephane/laravel-quality
bernskiold/laravel-talentlms
bernskioldmedia/laravel-form-architect