Laravel Gdpr Exporter Laravel Package

Product Decisions This Supports

• Build vs. buy for DSAR fulfillment. The package covers roughly the plumbing third of a subject-access capability — config-driven model/column discovery, serialization, archive generation, delivery notification. Framed honestly to stakeholders, it removes weeks of low-value engineering (a controller that dumps a user's rows) and buys nothing on the hard parts: the data inventory, DPO sign-off, identity verification, the 30-day clock, and the operational runbook. Use it to shorten the build, not to justify deferring the program.
• Roadmap sequencing for compliance commitments. If a customer contract, enterprise deal, or EU market entry depends on Art. 15/20 readiness, this package lets you ship a credible internal capability behind a flag in a single sprint, then invest the following sprints in the data map and process. It de-risks the "we said we'd have this by Q3" commitment without pretending the compliance obligation is met by a composer require.
• Feature scope negotiation. The package's config-as-API model gives you a concrete artifact — the published, version-controlled config — to put in front of legal and a DPO. That converts an open-ended "what counts as personal data?" debate into a reviewable diff, which is far easier to schedule and sign off than a spec document.
• Scope triage for distributed estates. If personal data lives in Stripe, Mailchimp, Sentry, or object storage, this package explicitly cannot see it. That boundary is a useful forcing function for a roadmap decision: commit to a documented manual processor-collection step now, or fund an aggregation layer later. Do not let the package's existence imply the problem is solved.
• Support and legal enablement. DSARs arrive at support and legal, not engineering. A standardized exporter produces an identical artifact whether triggered by a console command or an agent, which is what makes a self-service or support-facing intake workflow safe to introduce. That is a measurable reduction in engineering interrupt load per request.
• Reusable pattern for other data-handling obligations. The same config-driven export declaration tends to become the reference for erasure/redaction decisions (null PII vs. delete rows) and for consent-history inclusion. Treating it as a shared internal pattern, rather than a one-off, pays back on retention and audit-logging work.

When to Consider This Package

Adopt when most of the following hold:

• One app, one database. Personal data for a data subject lives in first-party Eloquent models on a conventional Laravel monolith. This is the designed case and where the leverage is real.
• Boring prerequisites already exist. Queue workers, a private storage disk, and working transactional mail are configured. Without these, you are building infrastructure before you build compliance.
• The framework is in the supported window (roughly Laravel 8–11) and the package's composer.json constraints do not cap below your next Laravel major — a cap there becomes a migration blocker with a legal dependency attached.
• You have an owner and a runbook plan. Someone in legal or support operations is named, deadlines are tracked, and escalation paths for "export is empty" and "export is late" exist or will exist before the first request. Without this the capability exists on paper and fails in practice.
• You accept permanent ownership of two drifting artifacts — the published config and the data map. Both decay silently as the schema evolves. Budget a recurring review and a CI check that every column tagged as personal data is mapped, not a one-time setup.
• A small dependency surface is worth a single-maintainer risk. The package is narrow, MIT-licensed, and low-blast-radius on the read path. Judge that trade explicitly rather than by default.

Look elsewhere — or budget heavily for bespoke work — when:

• The estate is distributed. Multi-tenant databases, microservices, documents in object storage, or event streams mean the package becomes one contributor among many and you still hand-build the aggregation layer.
• The bus factor of one is unacceptable on a legally consequential path. A silently dropped model produces an incomplete statutory response, which is a compliance incident, not a bug ticket. If your risk posture forbids that on regulated code paths, the honest options are a fork you own or a commercial DSAR vendor.
• The release signal is too thin for your change-control regime. The 1.4.0 release body is an auto-generated compare link with no feature summary, migration notes, or security reference. Semver here is self-certified. If you cannot read the diff and composer.json constraints before every bump, this dependency will fight your process.
• You need guarantees, not mechanisms. The package produces a file. Lawful basis, requester identity verification, and the response clock remain yours. If the ask is "buy compliance," no package in this category answers it.
• The target is high-volume, tail-heavy accounts. Long-tenured users with hundreds of thousands of rows across many tables need chunked queries, concurrency caps, and possibly replica reads. Confirm the package queries in chunks before committing; if it does not, you are wrapping it anyway.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed Laravel dependency that mechanizes the repetitive half of responding to a GDPR subject-access or data-portability request — pulling a user's records from our own database and packaging them for secure delivery. It is not a compliance product and it does not make us compliant. What it does is let us stand up the technical mechanism in one sprint so that the real work — legal sign-off on what our export must contain, a named owner, and a documented runbook with deadline tracking — proceeds in parallel instead of after. The cost is one dependency with a single maintainer and a permanently maintained configuration file; the risk is that an unmapped new column silently drops out of future exports, which we mitigate with a CI check and a recurring review. Recommend adoption for our Laravel monolith, scoped to first-party database records only, with an explicit manual step documented for data held by third-party processors.

To engineering: Narrow, low-install-cost package that standardizes model and column discovery, serialization, archive creation, and delivery notification for DSAR exports. The composer require is trivial; correctness is not. Three things to nail down before we trust output: read the 1.3.2→1.4.0 diff for changes to config keys and archive format (the release body is only a compare link), pin an exact version, and publish plus version the config as a reviewed artifact. Queue the work rather than inlining it, verify chunked queries and peak memory on a realistic account, store exports on a private encrypted disk with a 24–72h TTL, and log every request with subject and artifact hash. The failure mode that matters is under-exporting — a relation missing from config, a $hidden attribute vanishing from the export, or a column never selected. Build a schema-introspection test asserting every tagged personal-data column is mapped, and reconcile one generated export line-by-line against a hand-assembled one before we call it done. If the package exposes a custom-exporter interface, implement it for non-standard storage rather than forking.