Product Decisions This Supports
- Framework fit check — the first decision. Despite being filed under a PHP/Laravel package index, this is a Symfony bundle built on Doctrine ORM/Dbal event subscribers, not a Laravel package. It cannot be dropped into an Eloquent codebase. The realistic PM decision it informs is build vs. buy vs. borrow: for a Laravel product, this is a borrow (design reference), not a buy.
- Compliance scoping. "Aid with GDPR and general field encryption" maps to concrete roadmap work: a data-classification exercise (which columns hold PII — email, name, address, government IDs, health/financial data), then a decision on which fields are encrypted at rest versus protected only by DB/disk-level encryption.
- Queryability trade-offs. Any field-level encryption breaks
WHERE, ORDER BY, LIKE, and unique constraints on that column. This package's existence forces the product question early: do we need searchable encryption via blind indexes, exact-match lookups, or can these fields be display-only? That decision changes schema design and admin tooling scope.
- Key management roadmap. Field encryption implies envelope keys, a KMS (AWS KMS/GCP KMS/Vault), and rotation. Reference implementations like this one surface the decision points — per-tenant keys vs. global key, rotation cadence, and what happens to encrypted data during a restore or tenant offboarding.
- Backfill/migration planning. Encrypting existing plaintext columns is its own project: dual-write, backfill job, cutover, and rollback plan. Worth a line item in any "enterprise readiness" epic.
- Deal enablement. These features typically get pulled forward by a specific trigger: an enterprise security questionnaire, a DPA requiring encryption of personal data, SOC 2 CC6.1 evidence requests, or a customer asking where PII lives. Use that trigger to justify the sprint.
When to Consider This Package
Adopt (or fork) only if all of these are true:
- The codebase is Symfony + Doctrine ORM, not Laravel. There is no Eloquent integration here.
- You are prepared to own a fork: 1 star, 0 dependents, and a single maintainer is a hard blocker for a dependency that sits directly on your most sensitive data path. Crypto code without independent review and a maintainer bus factor of one is supply-chain risk, not a shortcut.
- Your scope is genuinely "encrypt this column, decrypt on read" with no search, sort, or uniqueness requirements on the encrypted fields.
- You have budgeted for your own test suite around the subscriber behavior, migration path, and rotation — the package will not provide assurance there.
Look elsewhere or build in-house if:
- You're on Laravel — the idiomatic path is a custom Eloquent cast backed by a vetted crypto library (
libsodium / paragonie/halite), plus a separate blind-index column for equality search. That is roughly a one-to-two sprint build, and you keep the dependency surface to audited libraries.
- You need searchable or sortable encrypted fields, format-preserving encryption, or per-field access policies — out of scope for a bundle this thin.
- You need vendor or community support for an audit (SOC 2, ISO 27001, pen-test remediation). "One maintainer, one star" will not survive a security review conversation.
- You need key rotation and KMS integration as first-class product features.
Reasonable use regardless: read the source as a pattern reference for how Doctrine subscribers intercept hydration/persistance, and reuse that mental model when designing the Eloquent equivalent.
How to Pitch It (Stakeholders)
To executives: We evaluated an open-source field-encryption library for PII protection. It's a Symfony/Doctrine component — incompatible with our Laravel stack — and it has effectively no adoption (1 star, no dependents, single maintainer), which makes it unsuitable as a production dependency for regulated data. Recommendation: do not adopt; instead budget one to two sprints to build a small in-house encryption layer using audited crypto primitives and a managed KMS. This unblocks the enterprise security questionnaires currently gating deals and gives us a rotation story we control.
To engineering: Treat the repo as a design reference only. Key design decisions to carry forward: encrypt at the model/persistence boundary, store ciphertext plus a deterministic blind index for equality lookups, version your keys per row to make rotation possible without downtime, and keep encryption/decryption out of query builders entirely. Every encrypted column needs an explicit note in the schema docs about what queries are no longer possible against it.
Risk framing in one line: A one-star, single-maintainer crypto dependency is an unacceptable risk surface for personal data — the value here is the pattern, not the package.