Encrypt Bundle Laravel Package

Product Decisions This Supports

• Compliance-gated roadmap items. Answers the recurring security-questionnaire line "is sensitive data encrypted at rest at the application layer?" — relevant to GDPR Art. 32, HIPAA, PCI-DSS 3.4, SOC 2 CC6.1, and state privacy statutes. This is often a deal-blocker in healthcare, fintech, and public-sector pipelines.
• Feature scoping: selective field encryption. Encrypt only the columns that carry PII/PHI/PCI (SSN, DOB, medical notes, bank details, API tokens) while leaving the rest of the schema queryable. Cheap way to shrink breach blast radius without re-architecting storage.
• Build vs. buy vs. adopt. This is the "adopt" column: a small, single-purpose library that removes a 2–6 week internal build of encryption lifecycle plumbing. The real cost is not license (it's OSS) — it's data classification, key custody, and the query-layer workarounds.
• Enterprise/upmarket readiness. A credible answer here can unlock regulated-segment tiers, expedite vendor security reviews, and shorten procurement cycles.
• Data-residency / multi-tenant isolation decisions. Field-level encryption under a tenant-scoped key is a defensible answer to "can one tenant's data be read by another's operators?"
• Deprioritization decisions. Choosing this also means deciding not to support search, sort, aggregation, or unique constraints on the encrypted fields — a real product constraint worth writing down before it becomes a bug report.

When to Consider This Package

Consider it when:

• You run a Symfony/Doctrine stack and need transparent, per-field encryption with minimal application-code change. (Note: the package surfaces as a Symfony/Doctrine bundle, not a Laravel/Eloquent one — for Laravel-first teams, the equivalent decision is Eloquent's encrypted cast or a field-level library like CipherSweet, so evaluate this package mainly if you own Symfony services or are planning a mixed stack.)
• You have a small, well-bounded set of sensitive columns and no requirement to query, sort, or aggregate on them.
• You need audit-visible encryption now — e.g., a questionnaire is blocking a renewal — rather than a 12-month platform program.
• Your team can own key custody: secrets manager or env-based key injection, rotation runbooks, and disaster recovery for key loss.
• You're comfortable treating a 105-star, zero-dependent project as a dependency you may need to fork and own. Low adoption cuts both ways: small attack surface and easy audit, but no community safety net and no vendor SLA. Budget for a vendored fork and a named internal owner.

Look elsewhere when:

• You need searchable encryption or blind indexing — this pattern breaks WHERE, LIKE, sorting, joins, and uniqueness on encrypted columns.
• You're regulated at scale and need KMS/HSM-backed envelope encryption, automated key rotation, and per-key audit trails — evaluate cloud KMS, Vault Transit, or database-native column encryption instead.
• Your compliance requirement is already satisfied by storage/disk-level encryption (TDE) — adding app-layer crypto then buys complexity, not coverage.
• You need to protect files, blobs, or entire documents, not relational columns.
• You can't accept a hard boot-time dependency on key availability — a missing or rotated key becomes an outage, not a degraded feature.

How to Pitch It (Stakeholders)

To executives: This is a low-cost lever for unblocking regulated-segment revenue. It lets us truthfully answer "customer PII is encrypted at rest" on security reviews and materially reduces the impact of a database breach — an attacker who exfiltrates a dump gets ciphertext for the fields that matter. There is no license cost; the investment is a focused engineering sprint plus ongoing key-management discipline. Recommend a scoped pilot on one high-sensitivity dataset before committing to a broader rollout.

To engineering: Small, single-purpose library that encrypts designated ORM fields and decrypts them transparently on load — domain code stays largely untouched. Accept three trade-offs up front: (1) encrypted columns are not queryable, sortable, or uniquely indexable, so schema and reporting paths must be designed around them; (2) key management is our responsibility — key loss means permanent data loss, so runbooks and backups are part of the deliverable, not a follow-up; (3) the project has a small maintainer base (105 stars, no downstream dependents), so plan to vendor/fork it and assign an owner rather than assume upstream will absorb our edge cases. Treat it as infrastructure, not a convenience import.