Foggy Laravel Laravel Package

Product Decisions This Supports

• Compliance-driven roadmap work (GDPR/CCPA/DPDP): Foggy is the mechanism by which production PII can legally flow into staging, QA, and demo environments. This turns "we can't use real data in staging" from a blocked initiative into a one-sprint enablement task, and it creates a defensible, auditable answer for security reviews and DPIAs.
• Build vs. buy: A hand-rolled scrubbing script is the default alternative, and it is a permanent maintenance tax — every new PII column becomes a silent data-leak bug. This package externalizes that to a declarative config with an upstream maintainer, so the decision is "buy small, configure, and keep ownership of the column policy" rather than "build a masking pipeline."
• Environment parity as a quality lever: Production-shaped data in non-prod environments reduces the "works in staging, fails in prod" class of bugs (edge-case names, nulls, encoding, cardinality) that synthetic fixtures never reproduce. This is a direct input to release-confidence and incident-rate metrics.
• Infrastructure choice flexibility (this release): v0.8.1 fixes streaming dumps to S3 where the object size is not known up front. Practically, this removes a constraint that forced teams to either buffer large dumps to local disk before upload or cap dump size. It unblocks S3 as the dump destination for large production databases — relevant if your roadmap includes scheduled, automated refresh of non-prod environments from object storage rather than manual DBA-driven restores.
• Developer onboarding & demo velocity: Self-serve access to realistic data shortens time-to-first-meaningful-commit for new engineers and makes sales/demo environments viable without bespoke data-copying requests to the platform team.
• Scoping signal, not a feature: The release is a narrow, single-issue bugfix from a pre-1.0 package. It supports the decision to pilot Foggy on a non-critical pipeline, not the decision to make it a load-bearing part of a compliance program.

When to Consider This Package

Adopt when most of the following hold:

• You run a Laravel/PHP application with a relational database and a genuine need to move production-shaped data into staging, QA, local dev, or CI.
• You have an identifiable PII/PHI/financial-data surface (users, customers, orders, addresses) and either an existing compliance obligation or a security team asking "where does production data go?"
• Your dump destinations include object storage (S3-compatible), especially with dumps large enough that buffering to local disk is impractical — this release is specifically aimed at that case.
• You want declarative, reviewable masking config in the repo rather than an opaque DBA runbook, so changes go through code review and are diffable.
• You can accept a pre-1.0 dependency (currently 0.8.x) on a non-critical path, with an owner assigned to track breaking changes.

Look elsewhere or defer when:

• No PII in the database, or non-prod already uses fully synthetic fixtures — the value is near zero and the config surface is pure overhead.
• You need true tokenization, format-preserving encryption, or referential-consistent pseudonymization across systems (e.g., a masked user ID must still join to a masked record in another service). Masking-on-dump is a narrower tool than enterprise DLP/tokenization platforms, and the distinction matters to auditors.
• You require vendor support, SLAs, or a security certification. This is a small open-source package with no commercial backing; that is a procurement blocker in regulated environments regardless of code quality.
• Your data movement is not dump-based — CDC pipelines, logical replication, or managed snapshot/restore tooling sit outside this package's scope.
• You are on a non-Laravel PHP stack or a polyglot data platform, where a language-agnostic masking layer is the better long-term investment.
• You are pre-1.0-averse: if your engineering standards forbid 0.x dependencies in production-adjacent tooling, wait for 1.0 or vendor a fork.

How to Pitch It (Stakeholders)

To executives (risk + cost framing): We currently copy production customer data into lower-trust environments, or we avoid it and ship on unrealistic test data. Both are expensive. This package closes the first gap with configuration rather than a bespoke engineering project: sensitive columns are masked at dump time, so the data leaving production is already sanitized. It lowers breach exposure and audit findings, and it improves release quality by letting teams test against realistic data shapes. Cost is a small integration effort plus ongoing config hygiene — no license, no vendor, no new infrastructure. v0.8.1 is a targeted bugfix that makes S3 uploads work for large, streamed dumps; it is non-breaking and needs no migration.

To engineering: Lightweight, idiomatic Laravel package for sanitizing database dumps. Masking rules live in config and are code-reviewed like anything else. v0.8.1 fixes INFRA-480 — streaming dumps to S3 when the total size isn't known ahead of time — which means we can stop staging large dumps on local disk and can push big databases straight to object storage. Caveats to plan around: it is pre-1.0 (0.8.x), so pin the version, expect possible breaking changes on minor bumps, and keep it off the critical path until 1.0. It handles column-level masking, not cross-system tokenization or referential pseudonymization — if compliance asks for those, we need a different conversation. Proposed next step: a one-pipeline pilot against a non-critical staging database, with a written column inventory as the acceptance criterion.