DEV Community: rahul chavan

5 Features That Make AuditTrailBundle Stand Out

rahul chavan — Fri, 10 Apr 2026 14:14:52 +0000

Most Symfony audit bundles solve the same core problem: record Doctrine entity changes and let you inspect history later. Where AuditTrailBundle starts to separate itself is in the places where many audit packages stop: transport strategy, integrity guarantees, read-access logging, and recovery workflow.

Read-access auditing, not just write auditing
Most Doctrine audit tools focus on inserts, updates, deletes, and association changes. AuditTrailBundle goes further by documenting #[AuditAccess] for entity read tracking, including deduplication with a configurable cooldown. That is a meaningful distinction for teams working on privacy, insider-access monitoring, or regulated data access trails.
Multiple built-in transport targets
AuditTrailBundle is not framed as “database audit tables only.” Its docs explicitly present three delivery targets: Database[sync+async support], HTTP, and Queue/Messenger. That changes how you think about the bundle. It can act as an in-app audit logger, an integration point for external observability/compliance systems, or a queue-first pipeline.
Cryptographic integrity verification
A lot of audit libraries help you answer “what changed?” Fewer help you answer “can I prove this audit record was not tampered with?” AuditTrailBundle documents HMAC signing and integrity verification tooling, which pushes it closer to compliance-grade audit design rather than simple change history.
Split-phase audit architecture
One of the more technically interesting parts of AuditTrailBundle is that it explicitly documents a split-phase model: capture during onFlush, then dispatch during postFlush. That is not just implementation detail. It reflects a deliberate position on Doctrine lifecycle safety, write-path latency, and transport behavior.
Built-in revert and recovery workflow
AuditTrailBundle also distinguishes itself by documenting “Safe Revert Support” and dedicated revert/recovery guidance. That shifts the product from pure audit visibility toward operational remediation. In other words, it is not only about reading the past, but also about using that history to recover state.

Closing thought
What stands out about AuditTrailBundle is not that it audits Doctrine entities. Several bundles do that well. What stands out is that it treats auditing as a system design problem: capture timing, delivery strategy, tamper evidence, read access, and recovery all matter.

If AuditTrailBundle is useful to you, you can support the project by sharing feedback, starring the repository, reporting issues, or contributing pull requests.

From Personal Tool to Open Source: Console Profiler Bundle

rahul chavan — Wed, 25 Mar 2026 12:17:26 +0000

Hey everyone! 👋

If there's one thing I've learned from using Symfony since version 2, it's that as your application scales, so do your hidden bottlenecks. Over the years, I've built dozens of little utilities and scripts for my personal use cases to help debug long-running console queue workers, heavy data imports, and nightly cron jobs.

Recently, I looked back at some of these tools and realized they could be incredibly helpful to the broader community. So, I took one of my tools, completely modernized it for PHP 8.4 and Symfony 8.0, and decided to open-source it.

I'm excited to share the Console Profiler Bundle with you all.

But Why Another Profiler?

The standard Symfony Web Profiler is absolutely amazing for HTTP requests. It's the gold standard. But what happens when you run a heavy queue worker (messenger:consume) and you want to know if it's leaking memory? What if a CLI sync command is hammering your database with N+1 queries in the background?

You typically have to pepper your code with memory_get_usage() dumps or echo "Running query...", which is tedious and messy.

The Console Profiler Bundle solves this by hooking right into your terminal and giving you a live, auto-refreshing
TUI while your commands are actually running.

Key Features

I wanted this bundle to be as zero-config and plug-and-play as possible while providing deep insights. Here’s what it tracks for you in real time:

Memory Tracking: Live memory usage, peak memory, and even a live growth rate indicator (+X MB/s). If you see a steady red upward trend, you know you've got a memory leak.
SQL Query Counting: Zero-config automatic SQL query counting via Doctrine DBAL 4 Middleware. It tracks exactly how many queries your command is making in real time.
CPU Time: Tracks both user and system CPU time via getrusage().
Performance Trends: Real-time trend indicators (↑ ↓ →) for both memory and SQL queries so you can spot spikes instantly.
JSON Profiler Export: You can optionally dump a JSON report at the end of the command. I use this heavily in CI pipelines to automatically fail builds if a CLI N+1 regression sneaks in!

The Journey to Open Source

Moving from a "personal hack" to an open-source library was an eye-opening experience. I had to rip out a lot of hardcoded assumptions and ensure the codebase adheres strictly to modern standards.

Modernizing the code to leverage the features of PHP 8.4 and Symfony 8 was a blast, and honestly, seeing the live terminal dashboard update smoothly feels like magic. I also made sure the TUI degrades gracefully when ext-pcntl isn't available.

Try It Out!

If you are running PHP 8.4+ and Symfony 8.0+, you can load it in as a dev dependency right now:

composer require --dev rcsofttech/console-profiler-bundle

It works out of the box—just run any console command like bin/console messenger:consume async and look at the top of your terminal.

If you don't use it or want to turn it off, it gracefully steps aside. Oh, and it's smart enough to turn itself off in production!

You can find the repo here: rcsofttech85/ConsoleProfilerBundle

I Need Your Feedback!

Since this is my transition from keeping things internal to releasing them to the world, I would absolutely love to hear your thoughts.

Does this solve a problem you face with Symfony console commands?
Are there specific metrics you wish were tracked in the terminal?
Do you like the TUI layout?

Please drop a comment below or open an issue/PR on GitHub. Your feedback is what will shape the future of this tool. Let's build better CLIs together! 🚀

AuditTrailBundle now includes a Symfony Web Profiler integration, allowing developers to inspect audit logs recorded during a request directly from the debug toolbar and profiler panel. https://github.com/rcsofttech85/AuditTrailBundle

rahul chavan — Fri, 20 Mar 2026 06:12:27 +0000

GitHub - rcsofttech85/AuditTrailBundle: High-performance Symfony audit logging for Doctrine ORM. Async-ready, cryptographically signed, and optimized for enterprise compliance without the database overhead. · GitHub

High-performance Symfony audit logging for Doctrine ORM. Async-ready, cryptographically signed, and optimized for enterprise compliance without the database overhead. - rcsofttech85/AuditTrailBundle

github.com

Dispatching Audit Logs Asynchronously for Maximum Performance

rahul chavan — Tue, 24 Feb 2026 06:48:10 +0000

Audit logging is the backbone of any enterprise application. Whether you are building a healthcare portal, a fintech app, or an internal CRM where tracking "who did what and when" is legally mandated, audit logs are non-negotiable.

However, adding an audit trail often introduces a massive performance penalty. By default, every time you flush an entity in Doctrine, the audit system must compute change-sets, serialize old and new data, and execute additional INSERT statements to your database. In a high-traffic Symfony API, synchronous auditing can easily double your response times.

we're going to fix that. We will learn how to dispatch audit logs asynchronously using Symfony Messenger and the AuditTrailBundle.

If you are looking for the best Symfony audit log solution that doesn't sacrifice performance, this is for you.

The Synchronous Bottleneck

Before we optimize, let's understand the problem. In traditional audit logging, the lifecycle looks like this:

You create or update a Product entity.
You call $entityManager->flush().
An onFlush or postFlush listener intercepts the operation.
The listener builds an AuditLog entity (computes diffs, extracts user context, grabs IP addresses).
The listener forces another synchronous INSERT into the database.

In our internal benchmarks using an in-memory SQLite database, a standard synchronous Doctrine flush with audit logging takes ~10.2ms. In a real-world scenario with a networked relational database (MySQL/PostgreSQL), network latency can easily push this to 30-50ms per request. And if you are doing bulk inserts? The latency stacks up quickly.

The Solution: Asynchronous Queue Transport

The AuditTrailBundle solves this elegantly using a Split-Phase Architecture and native support for Symfony Messenger.

Instead of waiting for the database to write the audit log, the bundle serializes the audit data into an AuditLogMessage and pushes it to a message queue (like RabbitMQ, Redis, or Doctrine). A background worker then processes the queue, validating the integrity of the log and inserting it into the database.

By offloading the I/O operations to a worker, your main user request finishes instantly.

Step-by-Step Guide: Implementing Async Symfony Audit Logs

Here is how you can set up asynchronous audit logging in your Symfony application in under 5 minutes.

Step 1: Install the Bundle

First, install the rcsofttech/audit-trail-bundle via Composer:

composer require rcsofttech/audit-trail-bundle

Step 2: Configure Symfony Messenger

Before enabling the async transport, ensure you have a transport configured in Symfony Messenger. Let's create an audit_trail transport in config/packages/messenger.yaml:

framework:
    messenger:
        transports:
            # We use an async transport (e.g., AMQP, Redis, or Doctrine)
            audit_trail: '%env(MESSENGER_TRANSPORT_DSN)%'

Step 3: Enable the Queue Transport

Now, tell the AuditTrailBundle to use the queue transport instead of the default synchronous Doctrine transport. Update your config/packages/audit_trail.yaml:

audit_trail:
    transports:
        # Disable the default synchronous transport
        doctrine: false 

        # Enable the async queue transport
        queue:
            enabled: true
            # Optional: Specify a custom bus if you use multiple message buses
            bus: 'messenger.bus.default'

Step 4: Run the Consumer

In your production or local environment, start the Messenger worker to consume the audit messages in the background:

php bin/console messenger:consume audit_trail -vv

That's it! Your Symfony application is now dispatching audit logs asynchronously.

Under the Hood: How it Works

Let's look at the technical architecture of how AuditTrailBundle achieves this.

When you flush your EntityManager, the EntityProcessor captures the raw changes and delegates the dispatch to the AuditDispatcher. If the Queue transport is enabled, the QueueAuditTransport takes over.

1. Message Creation

The bundle prevents heavy ORM entity serialization by transforming the raw AuditLog into a lightweight, decoupled AuditLogMessage DTO:

$message = AuditLogMessage::createFromAuditLog($log, $entityId);

2. Extensibility via Events

Before the message is dispatched to the bus, the bundle fires an AuditMessageStampEvent. This allows you to programmatically attach Messenger stamps (like a DelayStamp or custom routing rules) to the audit log without overriding core services.

// Example: Adding a 5-second delay to all audit logs
public function onAuditMessageStamp(AuditMessageStampEvent $event): void
{
    $event->addStamp(new DelayStamp(5000));
}

3. Cryptographic Signatures (HMAC)

If you have data integrity enabled (audit_trail.integrity.enabled: true), the bundle signs the JSON payload of the message and attaches a SignatureStamp. When the worker consumes the message, it verifies the signature to ensure the audit log wasn't tampered with while sitting in the queue (e.g., Redis or RabbitMQ).

Hard Data: The Benchmarks

Does async logging actually make a difference? We ran rigorous automated benchmarks using PHPBench to measure the throughput of the QueueAuditTransport against the synchronous Doctrine approach.

Here are the results:

Worker Throughput: The background Messenger worker that un-serializes the AuditLogMessage, verifies its HMAC signature, and flushes it to the database takes roughly ~1.45ms per message. That equals a staggering ~690 messages processed per second per single worker thread.
Main Request Impact: In pure CPU time loops, serializing a message into the queue takes about ~12.2ms synchronously. While this sounds comparable to a pure in-memory SQLite flush (~10.2ms), the magic happens in a real networked environment. In production, a MySQL INSERT over the network introduces significant IO wait times. By pushing to Redis or RabbitMQ instead, your main user request bypasses database IO completely.
Bulk Processing: At scale, the overhead of the bundle drops to just ~3ms per entity, making it perfect for highly intensive import scripts.

Conclusion

Audit logging shouldn't be a bottleneck for your application's growth. By switching to an asynchronous architecture using Symfony Messenger and the AuditTrailBundle, you decouple your core business logic from compliance requirements, leading to virtually zero perceived overhead for your users.

Ready to supercharge your Symfony audit logs? Check out the AuditTrailBundle on GitHub, give it a star, and drop any questions in the discussions!

[Boost]

rahul chavan — Fri, 13 Feb 2026 16:01:57 +0000

Why I Built a New Audit Bundle for Symfony (And Why Your Project Needs It)

rahul chavan ・ Jan 13

#symfony #php #doctrine #security

AuditTrailBundle now has a Symfony Flex recipe

rahul chavan — Tue, 03 Feb 2026 07:53:37 +0000

AuditTrailBundle recipe has been merged into symfony/recipes-contrib

This adds automatic bundle enabling and default configuration when installing the bundle.Thanks to the Symfony team and maintainers for reviewing and accepting it.

[Boost]

rahul chavan — Thu, 29 Jan 2026 17:42:15 +0000

Why I Built a New Audit Bundle for Symfony (And Why Your Project Needs It)

rahul chavan ・ Jan 13

#symfony #php #doctrine #security

Why I Built a New Audit Bundle for Symfony (And Why Your Project Needs It)

rahul chavan — Tue, 13 Jan 2026 13:54:41 +0000

Update:

The EasyAdmin integration has been improved with a cleaner and more polished UI.

👉 Read the follow-up post for details.

When I started my latest Symfony enterprise project, I did what most of us do: I looked for a battle-tested Doctrine auditing solution. But I quickly realized that existing options often felt like a trade-off. Some were too heavy, others were a nightmare to customize, and almost none addressed the critical 2026 need: Data Integrity.

I spent way too much time fighting performance lags and database bloat. That frustration led me to build a solution that is both lightweight and enterprise-ready.

That’s why I built AuditTrailBundle. It’s a modern alternative for Symfony entity tracking that focuses on performance and compliance.

1. Stop Logging "Noise" (Conditional Auditing)

In high-traffic apps, logging every tiny change is a mistake. Do you really need to log a last_login timestamp every 5 minutes? It wastes storage and clutters your audit log history.

I integrated Symfony Expression Language directly into the bundle. Now, you can set "Smart Rules" to only trigger an audit if a specific condition is met. It’s conditional logging that keeps your database clean and searchable.

2. The "Anti-Tamper" Proof (Audit Compliance)

If your app needs to be GDPR or SOC2 compliant, simply having logs isn't enough. You need to prove those logs haven't been modified.

I added a Data Integrity Check feature—a digital seal for your history. If a DBA or an attacker manually edits a log entry to hide their tracks, the bundle flags the discrepancy. It’s a built-in safety net for your audit trail.

3. Performance That Won't Slow You Down

A common complaint with Symfony audit bundles is the "request lag." This bundle hooks into the Doctrine onFlush event, ensuring the audit is part of the same atomic transaction.

No Orphaned Logs: If your data rolls back, the audit rolls back.
Split Transport Support: To keep your primary database fast, you can route audit logs to a different database connection or an external service. This is essential for scaling Symfony applications.

4. Tracking Changes (Collection Diffs)

Most bundles fail when it comes to Many-to-Many relationships. They might tell you a collection "changed," but not what moved.

AuditTrailBundle performs a deep Collection Diff. It identifies exactly which IDs were added or removed from a relation, giving you a crystal-clear picture of your entity's history without the guesswork.

Quick Start

Install it via Composer:

composer require rcsofttech/audit-trail-bundle

Summary: A Modern Tool for Modern Devs

I built this to offer a performance-first architecture for developers who need precision. Whether you’re worried about database scalability or strict security compliance, this bundle handles it without the overhead.

Check it out on GitHub:
Audit Bundle

I’m actively looking for feedback! If you find it helpful, please consider dropping a Star ⭐ on GitHub! It helps the project reach more developers in the Symfony community.