Doctrine Encrypt Laravel Package

Technical Evaluation

Architecture fit

• This is a Doctrine ORM persistence-layer extension, not a Laravel/Eloquent package. Laravel's default ORM is Eloquent, so adopting it means either running a second ORM via a Doctrine bridge (laravel-doctrine/orm) or confining it to a Doctrine-based service. Both add architectural surface area disproportionate to the benefit.
• Field-level encryption belongs at the persistence or KMS boundary. Introducing a dormant, unmaintained package into that boundary is a poor architectural trade regardless of how clean the API is.

Integration feasibility

• Composer-installable, MIT-licensed, so there is no legal blocker. Everything else is a blocker.
• The description reads "WIP DO NOT USE." That is an explicit author warning, not a maturity caveat. Combined with 1 star, 0 dependents, and a single release dated 2022-01-03, there is zero evidence of production use anywhere.
• Integration would be entirely greenfield: no documentation, no examples, no issue history worth relying on, no downstream consumers to sanity-check behavior against.

Technical risk

• Highest risk tier. Encryption is a security control; an unreviewed, abandoned implementation can create false assurance and turn into a compliance finding rather than a mitigation.
• Unverified: cipher selection, IV/nonce generation and reuse handling, key derivation, key rotation and re-wrap, deterministic vs. randomized mode, ciphertext length handling, and interaction with Doctrine types and migrations.
• Abandonment risk is realized, not theoretical: no releases in roughly three years, no maintainer activity assumed, and modern PHP 8.2+/Doctrine 3.x compatibility is unproven.

Key questions

• What is the actual driver — a compliance obligation (PCI DSS, HIPAA, GDPR, SOC 2), a customer contractual clause, or internal preference? The answer determines whether a homegrown WIP package is even in scope.
• Does the team genuinely run Doctrine, or is this an Eloquent codebase where the package simply looked close enough?
• Who owns key management (AWS KMS, GCP KMS, Vault, envelope encryption), and who owns rotation and re-encryption?
• Is queryability required on encrypted fields (equality search, sorting, partial match)? If so, plain field encryption cannot satisfy it and the alternative set narrows to CipherSweet-style searchable encryption or DB-native options.
• What PHP, Laravel, and Doctrine versions are targeted, and is there a security review board that must sign off on third-party crypto?

Integration Approach

Stack fit

• Misaligned by default. For an Eloquent codebase, the native encrypted cast covers the common case with zero new dependencies and first-party support. For searchable encryption, paragonie/ciphersweet is maintained and audited. For broad coverage, disk/DB-level encryption (pgcrypto, TDE) or a KMS envelope pattern is preferable to per-field application crypto.
• Doctrine is only justified if the service already runs Doctrine; even then, a maintained Doctrine encryption bundle is the sane comparison, not this one.

Migration path

• There is no migration path because there should be no adoption. If the package already exists somewhere in the estate, treat removal as a replacement project with a data re-encryption plan, not a version bump.
• Any pre-existing ciphertext written by an unknown implementation must be treated as needing decrypt-then-re-encrypt under a reviewed scheme.

Compatibility

• Assume unsupported until proven otherwise: PHP 8.2+, Laravel 10/11/12, Doctrine ORM 2.x vs. 3.x, PHP 8 Attributes vs. legacy annotations, custom DBAL types, and migration tooling all need explicit verification. The 2022 release date makes breakage likely across the board.

Sequencing

1. Write the encryption requirement down (data classes, threat model, compliance citation, key ownership) before evaluating any library.
2. Timebox a research spike on this package to at most two days, on a throwaway branch, never in a shared environment. Goal is a go/no-go note, not a prototype.
3. Run a bake-off of maintained alternatives against the written requirement — Eloquent encrypted cast, CipherSweet, DB/KMS-native — with a working encrypt/decrypt/rotate test on real schema.
4. Route the winner through security review and record an ADR, including why this package was rejected.
5. Only then sequence delivery: key management, rotation runbook, backfill of existing rows, and observability.

Operational Impact

Maintenance

• Effectively zero upstream maintenance. One release in 2022, one star, no dependents, single-maintainer bus factor. Any defect, PHP incompatibility, or CVE becomes entirely our problem to patch — and patching crypto in a fork is not a task to hand to an on-call engineer.

Support

• GitHub issues only; no vendor, no SLA, no security disclosure process, no CVE pipeline. Internal support would mean designating an owner with crypto competence, which is a staffing commitment far larger than the package's apparent convenience.

Scaling

• Ciphertext expansion increases row and index size.
• Encrypted columns cannot be indexed or range-queried, so any reporting or filtering path touching those fields degrades to full scans or application-side filtering.
• Per-row encrypt/decrypt on every hydrate adds CPU on hot read paths; key rotation at scale means a full-table re-encryption campaign with downtime or dual-write planning.

Failure modes

• Lost or rotated-away key = unrecoverable data. This is the dominant risk and is a process problem no library solves.
• Partial rotation leaves mixed ciphertexts with no version tag to distinguish them.
• Doctrine or DBAL upgrades break hydration silently, surfacing as decrypt failures in production rather than at deploy.
• Rollback after a schema or cipher change can leave rows undecryptable by the previous release.
• Any undiscovered crypto weakness produces silent exposure with no upstream patch coming.

Ramp-up

• Cheap to install, expensive to trust. No docs, no examples, no community corpus means every question routes to reading the source, and the team must independently validate crypto correctness before it can be relied on. That is weeks of specialist effort for a package already labeled do-not-use.

Recommendation: Do not adopt. Classify as rejected — unmaintained, self-declared WIP, security-sensitive, and architecturally misaligned with Laravel. Redirect the effort to a maintained alternative selected against a written encryption requirement.