Product Decisions This Supports
- Data-at-rest encryption for sensitive columns (PII/PHI/PCI): enables a feature decision like "we can store customer emails, tax IDs, or health notes in this table" without waiting on a full database TDE or infrastructure-level encryption project. Encryption happens at the ORM layer, so ciphertext lands in the column while application code keeps working with plaintext values.
- Compliance and security-questionnaire unblockers: a concrete, demonstrable answer to "is sensitive data encrypted at rest at the field level?" for GDPR/CCPA data-subject requests, HIPAA-adjacent workloads, SOC 2 evidence collection, and enterprise security reviews. Often the difference between "deal blocked pending security review" and "deal closed."
- Scope decisions on which fields are protected: because encrypted columns are not queryable, sortable, or uniquely-indexable in the normal way, adopting this forces a useful product conversation — which fields do we actually need to search/filter on (blind index, deterministic encryption, or keep plaintext) versus which are write-and-display only. That mapping is a roadmap artifact in itself.
- Build vs. buy vs. borrow: the underlying mechanism is a Doctrine custom type plus a cipher. At ~5 stars and 0 dependents, treat this as borrow — a small, MIT-licensed reference implementation to adopt, fork, or reimplement — not as a strategic dependency. A "build" estimate is measured in days for the type itself; the expensive part is key management, rotation, and backfilling existing plaintext rows, which this package does not solve for you.
- Platform-upgrade sequencing: the 5.0.0 release ties this package's major version to the Symfony major version. That makes it a line item in any Symfony 7 upgrade plan — encrypt-at-rest capability on a given branch is now coupled to a framework upgrade, which belongs in the same roadmap slot as the framework jump, not after it.
- Migration and rollout planning: supports sequencing decisions — new columns encrypted from day one, existing columns encrypted in a backfill job, dual-read during transition, and whether to encrypt per-tenant with separate keys (a common enterprise-tier feature).
- Risk-surface scoping: decides whether plaintext leakage outside the DB matters — logs, queue payloads, error trackers, analytics exports, and search indexes will still contain plaintext even after this package is in place. That gap usually spawns its own roadmap items.
When to Consider This Package
Consider it when all of the following hold:
- Your stack is Symfony with Doctrine ORM, on Symfony 7.x for the 5.0.0 line (see the release note below). Note the mismatch with the "Laravel/PHP" framing: this is a Doctrine bundle, not an Eloquent package. In Laravel it is only relevant if you run
laravel-doctrine/orm or a similar Doctrine integration — otherwise it does not apply and you should look at an Eloquent cast/attribute-based equivalent.
- You need field-level encryption on a small, well-defined set of columns, and those columns do not need to be searched, sorted, joined on, or uniquely constrained in plaintext.
- You have — or will build — a key management story: where keys live (secrets manager/KMS vs.
.env), who can read them, and how rotation works. The package handles the cipher, not the key lifecycle.
- You accept the maintenance profile: single-agency maintainer, 5 stars, 0 dependents. The 5.0.0 release is a positive signal — the maintainer shipped Symfony 7 support — but it also demonstrates the shape of the risk: a major version bump whose only content is framework compatibility, which means version cliffs are tied to Symfony majors and older branches go stale rather than being patched. Pin the version, read the source (it's small), and assume you may own a fork.
- You want a low-ceremony starting point over a heavyweight platform (Vault transit, AWS KMS envelope encryption, a database TDE migration, or a commercial tokenization vendor).
Look elsewhere — or plan to build — when:
- You are on Eloquent/Laravel without Doctrine; the integration cost exceeds the benefit.
- You are on Symfony 6.x or earlier: 5.0.0 targets Symfony 7.x, so you would be pinning the prior major line. That is workable but means adopting a branch that is now in maintenance-only territory — factor the framework upgrade into the decision rather than deferring it.
- You need searchable encryption, deterministic equality queries, range queries, or blind indexes out of the box. This package does not offer those semantics.
- You need envelope encryption with KMS/HSM, automated key rotation, per-tenant keys, or audit logging as first-class features.
- You are high-assurance: regulated workloads that require a security-audited, vendor-supported library with a published threat model and CVE process. A 5-star bundle with no dependents will not survive procurement review on its own.
- Your real problem is broad at-rest coverage: full-disk/TDE plus secrets management plus log scrubbing may be cheaper and more complete than per-column encryption in application code.
- You cannot afford the migration work: backfilling encrypted values, updating unique constraints, and validating that no query path depends on the newly-opaque columns.
How to Pitch It (Stakeholders)
For executives: This is a small, free, MIT-licensed building block that lets us encrypt specific sensitive database fields — the kind of thing that shows up in security reviews and enterprise contracts. It is not a platform and not a silver bullet: it encrypts values in the database but does not manage our keys, does not make encrypted data searchable, and will not by itself satisfy an auditor's key-management questions. The latest release (5.0.0) is a maintenance release adding Symfony 7 support — a good sign the project is alive, and a reminder that the package tracks framework versions, so it should be sequenced with our Symfony upgrade rather than independently. The right framing is "low-cost enabler that removes a specific blocker," paired with a funded key-management and migration workstream. Budget accordingly: the package is free; the surrounding work is not.
For engineering: The value is a Doctrine custom type that transparently encrypts and decrypts mapped columns, so product code keeps reading and writing plaintext. The costs are real and specific: encrypted columns can't be queried, sorted, or uniquely indexed; existing rows need a backfill; query paths and unique constraints need an audit; plaintext still leaks to logs, queues, and error trackers; key storage and rotation are ours to design. New in 5.0.0: Symfony 7.x compatibility only — it is a major bump with no new cryptographic features and no new query semantics, so nothing on our earlier cost list has changed. Treat it as a compatibility bump: upgrade alongside the framework, pin the version, and don't expect it to close any of the searchable-encryption or key-management gaps. The project remains a single-maintainer bundle with zero dependents and five stars — read it, pin it, and be prepared to fork or reimplement (it's small). Recommendation: adopt as a time-boxed spike on one or two columns behind a feature flag, with an explicit fork-and-own decision recorded before it reaches any production data path.