Weave Code
Laravel Process Stamps Laravel Package
orisintel/laravel-process-stamps
Laravel Process Stamps adds lightweight provenance to Eloquent models, automatically recording the command, job, request, or test that created or updated each record. Trace data changes, debug background workflows, and answer "where did this row come from?" with minimal setup.
Logs which process created or modified a record
Frequently asked questions about Laravel Process Stamps
- What does the orisintel/laravel-process-stamps package actually do?
- It is an Eloquent event sidecar: it hooks the created and updated model events, resolves the current execution context (HTTP request, artisan command, queued job, or scheduler), and writes that context into columns on the model's own row. The result is lightweight row-level provenance that answers "where did this row come from?" for Eloquent writes. It is a correlation aid for debugging background workflows and tracing data changes, not a full audit logging system.
- How do I install laravel-process-stamps in a Laravel app?
- Install with composer require orisintel/laravel-process-stamps, then publish the package config. Add the stamp columns to each opted-in table via a migration, and add the HasProcessStamps trait to the models you want stamped. There is no service provider gymnastics or schema ownership involved, but expect one migration and one index decision per stamped table.
- Which Laravel and PHP versions does laravel-process-stamps support?
- Check the package's composer.json constraints against your target Laravel and PHP version before anything else, because the last release was 2021-04-16. That is roughly four years old against a framework that ships a major annually, so it may cap at Laravel 8 or earlier. If the constraint does not cover your version, the real decision is whether to vendor and maintain a fork, not whether the feature is nice.
- Does laravel-process-stamps record which user changed a record?
- No. It records which process wrote the row (request, command, job, or scheduler, plus an identifier), not which person did it. If your underlying requirement is "who changed this record" in a compliance or customer-facing sense, you still need request-ID-to-user mapping in your logs. Treat it as a correlation aid rather than a solution for audit logging.
- Which database writes are not stamped by laravel-process-stamps?
- Any write that bypasses Eloquent model events is silently missed: DB::table() bulk inserts and upserts, raw SQL, queue consumers outside Laravel, ETL jobs, and another service sharing the database. Those rows will carry no stamp, which is worse than having no feature at all if people start trusting it for forensics. Coverage, not capability, is the gating question before rollout.
- Does laravel-process-stamps work correctly inside queue workers, the scheduler, and Laravel Octane?
- It should, but this is the risk you must validate empirically rather than read off the README. Queue workers, schedule:run, and Octane keep processes alive across many units of work, so if context is resolved once at boot or not reset between jobs, stamps will look plausible but be wrong. That is the most expensive failure class for this kind of tool, so test it under your real worker setup.
- What is the performance overhead of laravel-process-stamps on writes?
- The "zero-overhead" claim is marketing: it is a small constant cost per create and update, not zero, and it compounds with the index decisions you make on hot tables. An event listener sits on the critical path of every stamped write, so measure on your highest-write model before broad rollout. Also confirm the package swallows its own resolution failures and writes null stamps rather than throwing exceptions that fail a legitimate write.
- Can laravel-process-stamps leak PII, tenant IDs, or secrets into stamped columns?
- Process names often derive from routes, URIs, or command strings, so treat stamped columns as exportable data and review them before they reach logs, dashboards, or customer-facing screens. Confirm that no PII, tenant identifiers, or secrets can land in a stamp column. This is a data hygiene decision you own, not something the package enforces for you.
- When is laravel-process-stamps a good fit versus a poor fit?
- It fits Laravel monoliths and modular monoliths where Eloquent is the only write path and no existing row-level provenance exists. It is a poor fit where writes arrive through raw SQL, bulk upserts, external queue consumers, ETL, or another service sharing the database, because those writes will silently carry no stamp. It is also the wrong tool if the requirement is a compliance-grade "who changed this" audit trail.
- Is laravel-process-stamps still maintained, or is it effectively end-of-life?
- The last release was 2021-04-16, the repo has around 94 stars, and it has a single-maintainer profile, so you should not assume security responses or compatibility backports. Open the repository and read the actual changelog and PR queue before deciding. If it is stale for your Laravel version, plan to vendor and maintain a fork or choose a different approach.
Weaver
How can I help you explore Laravel packages today?