Auto Delete Bundle Laravel Package

Product Decisions This Supports

The capability this package addresses — automatically deleting records once they exceed a retention window — maps to several recurring product decisions, even though the package itself is not a strong candidate for adoption:

• Data retention & compliance posture. GDPR Article 5(1)(e) (storage limitation), CCPA/CPRA deletion obligations, and sector rules (HIPAA, PCI) all require that stale personal data not live forever. A retention mechanism is the difference between "we have a policy document" and "we can evidence the policy is enforced."
• Build vs. buy for platform hygiene. Retention is horizontal infrastructure. The real decision this surfaces is whether retention is a shared platform capability (one scheduler-driven pruning layer every team inherits) or something each feature team reinvents. Given the package's maturity signals — 0 stars, 0 dependents, score 0.1, single-vendor Symfony bundle — the build side of that decision is heavily favored.
• Roadmap placement. Retention tends to be deferred until an audit, a DSAR (data subject access request) backlog, or a storage-cost spike forces it. The PM decision is whether to pull it forward as a small, unglamorous platform story rather than a reactive fire drill.
• Use cases worth scoping: expired session/token records, notification and email logs, soft-deleted records past their grace period, abandoned carts and trial accounts, marketing consent expiries, audit trails with legally mandated minimums (note: these need a floor and a ceiling, not just a ceiling), and staging/anonymized dataset refresh.
• Cost and risk modeling. Retention directly reduces row count and index size, which shows up in backup windows, replica lag, and managed-database bills. That is a quantifiable input to prioritization.
• Erasure workflow design. Auto-deletion is a scheduled control, whereas DSAR erasure is an on-demand control. Deciding which is which — and where both write to the same audit log — is a product/legal decision this capability forces into the open.

When to Consider This Package

Consider it only under a narrow set of conditions:

• The codebase is Symfony with Doctrine ORM (the bundle is a Symfony bundle; its conventions — bundle registration, service container config, Doctrine entity hooks — do not translate to Laravel).
• You need entity-level TTL expiry and are willing to vendor or fork the source, since 0 stars / 0 dependents means no community backpressure on bugs, no security advisories, and no guarantee of a next release.
• You have someone who can read the deletion logic during due diligence. Auto-delete is destructive by definition: the diligence questions are what is the delete strategy (hard vs. soft), what happens to foreign keys and cascades, is the deletion transactional, is there a dry-run mode, and what gets logged when a record is destroyed? A misconfigured retention job is a data-loss incident, not a bug.
• You are not on Laravel. For a Laravel application, look elsewhere — specifically at first-party options: the Prunable trait with model:prune, a scheduled console command, or database-native partitioning/TTL. These cost a few hours, are already in the framework's support envelope, and carry no third-party risk.

Look elsewhere if any of the following are true: you need vendor support or an SLA; the data is regulated and requires an auditable, tested deletion path; you need retention rules configurable by non-engineers; you're on Laravel; or the maintainer cannot confirm ongoing maintenance in writing.

How to Pitch It (Stakeholders)

For executives: We have a retention obligation and a retention opportunity. The obligation is regulatory — data we no longer need should not be retained, and today we have policy but limited enforcement. The opportunity is cost — stale rows inflate storage, backups, and query times. The specific third-party package evaluated here is not the answer: it is a single-vendor Symfony bundle with no adoption, no dependents, and no maintenance signal, and it does not fit our Laravel stack. Recommendation is to implement a thin, first-party retention layer using Laravel's built-in pruning and scheduler, estimated at one to two engineer-days plus a legal review of the retention windows. This avoids an unmaintained dependency in a destructive code path and gives us an auditable, testable deletion mechanism we control.

For engineering: This is a small, well-understood piece of platform work, not a research project. Proposed shape: a Prunable model contract plus a scheduled model:prune run, retention windows expressed in configuration (not code) so legal can review them, dry-run and count-only modes for the first release, every deletion written to an append-only audit log, and hard-delete only after a soft-delete grace period. We should also confirm with legal that any records under a minimum-retention rule (invoices, tax, audit) are explicitly excluded from pruning rather than accidentally swept up. The evaluated package's deletion semantics — cascades, transactionality, logging — are undocumented and would need source review before we trusted it with production data, which is a cost we don't need to pay given the in-house alternative is this small.