Laravel Rewind Laravel Package

Product Decisions This Supports

• Build vs. buy for audit history. Rewind answers the recurring "do we build our own versioning/audit table?" question with a drop-in Eloquent trait. Default answer changes from "engineer it in each sprint" to "adopt, configure, and spend the sprint on the customer-facing surface." Saves an estimated multi-week build plus ongoing maintenance for every model that needs history.
• Whether to ship an "undo / restore" capability. Because Rewind::goTo(), rewind(), fastForward(), restore(), and cloneModel() are one-liners, "restore this record to how it looked yesterday" becomes a shippable feature rather than a research spike. This is a roadmap unlock for admin tooling, CMS-style products, and any surface where customers edit records they later regret.
• Compliance and audit-trail commitments. restore() is explicitly non-destructive (creates a new version with event_type = 'restored' and meta['restored_from_version']), while goTo() moves the pointer without an audit record. That distinction is a product decision in itself: you can offer a compliant "revert with recorded justification" path and a separate non-audited "preview" path, and say so accurately in a security questionnaire.
• Temporal querying and point-in-time reporting. versionAt($model, Carbon), getVersionAttributes(), and replay() over a version range enable "what did this record look like on the date of the dispute/audit/invoice?" — a feature that otherwise lands as a bespoke data-warehouse ask.
• Support-cost reduction. Undo/restore replaces a class of "we deleted the wrong thing" tickets and manual DB restores. amendCurrentVersion() and excludedFromVersioning() let you keep noisy counters and secrets out of history so the audit trail stays readable by support staff, not just engineers.
• Incident recovery from bad bulk writes. Rewind::batch() groups multi-model changes under one batch_uuid, so a botched bulk operation becomes an identifiable, queryable unit (RewindVersion::inBatch($uuid)) rather than an archaeology exercise.
• State-machine observability. Declaring $rewindStateFields and querying whereStateBecame / whereStateTransition / stateHistory() turns order/payment status history into a first-class, queryable timeline. This supports ops dashboards, SLA measurement ("time from pending to shipped"), and dispute resolution without adding a separate event-tracking system.
• Storage-cost trade-off as an explicit lever. snapshot_interval (default every 10 versions) is a dial between storage spend and reconstruction latency; pruning (rewind:prune --keep --days) plus per-model $maxRewindVersions gives you a defensible retention policy you can write into a DPA or retention appendix.

When to Consider This Package

Consider it when all of the following hold:

• The system is Laravel + Eloquent, the models needing history live in your own database, and you can add a current_version column and a versions table via migrations.
• You need reconstructed full state at a point in time, not just a log of who changed what. This is the differentiator versus activity-log packages: getVersionAttributes(), replay(), and versionAt() give you the whole row.
• History is a product feature or a compliance requirement, with a named owner and a retention policy — i.e., someone will actually be paged when it breaks.
• Write volume is moderate and predictable, and you can enable listener_should_queue for the hot models. Batch versioning and lock-timeout handling (log / event / throw) show the author anticipated concurrency, but you should still load-test your real write path.
• You are comfortable adopting a pre-1.0, single-maintainer, low-adoption package for a non-critical path first (see risks below).

Look elsewhere — or build — when:

• You need true event sourcing with projections, replay-driven read models, or cross-aggregate consistency. Rewind is linear row history per model, not an event log you can rebuild a service from.
• Your history must cover non-Eloquent writes (raw SQL, other services, external CDC, data warehouse). This package only sees Eloquent model events.
• You have very high write throughput where an extra version row per change and a cache lock per write are unacceptable, and you can't queue.
• You need field-level encryption or PII redaction in history — excludedFromVersioning() keeps fields out entirely, but it is not a redaction or crypto layer. Sensitive attributes previously versioned stay in the versions table.
• You need a vendor with a support contract, security review, or SLA. With 209 stars and 0 dependents on record, you are effectively the first serious adopter in your risk tier. For a payments or health-compliance audit trail, that may be disqualifying on its own.
• Simpler needs are met by updated_at/updated_by columns or an existing activity-log package. Don't buy a reconstruction engine for a "who touched this" widget.

How to Pitch It (Stakeholders)

One-liner for executives: Rewind is an MIT-licensed Laravel package that adds full version control to our database records — every model change is stored, any version can be inspected, diffed, or restored, and storage stays small because it stores diffs with periodic full snapshots. It converts "audit trail" and "undo" from a multi-sprint build into a configuration task.

Why it matters commercially: it lets us commit to audit and restore capabilities in RFPs and security questionnaires, reduces the support load from accidental edits and bad bulk updates, and gives customers a trustworthy "revert with a recorded reason" workflow — without a bespoke platform investment.

For engineering: a Rewindable trait on the model plus one migration; hybrid diff/snapshot storage with a tunable snapshot_interval; cache-based locking for concurrent writes; queued version creation for hot tables; pruning and per-model version caps for retention; batch grouping across models; and structured state-transition queries for status fields. The API is expressive and the README documents the sharp edges — notably the goTo() vs. restore() audit distinction and how edits on older versions are recorded against the previous head.

Risks to state plainly:

• Adoption risk. ~209 stars, 0 dependents, and a single primary maintainer. Treat this as an evaluated dependency, not a foundation. Mitigations: pin the version, wrap all calls behind a thin internal HistoryService interface, keep the ability to swap to a self-built table, and contribute fixes upstream.
• Pre-1.0. Latest line is v0.9.x; breaking changes are plausible. Budget a small recurring maintenance allocation per Laravel major upgrade.
• Performance is a claim, not a benchmark. The queue option and lock-timeout handling are reassuring, but we should benchmark against our own write volume and reconstruction depth before enabling it on the highest-traffic tables.
• Scope is Eloquent events only. Any writes that bypass Eloquent are invisible in history — that has to be an explicit, documented limitation rather than a surprise during an audit.

Recommendation: pilot on a single low-risk, high-visibility model (e.g., CMS content or an internal admin record), measure storage growth and reconstruction latency at our real snapshot_interval, and gate broader rollout — and any compliance claim — on those numbers.