Doctrine Encrypt Bundle Laravel Package

Product Decisions This Supports

• Stack-fit check, not a Laravel decision. Despite the "Laravel/PHP" framing, this is a Symfony bundle built on Doctrine ORM. It has no bearing on Laravel/Eloquent roadmaps. It is only relevant if the portfolio includes Symfony or plain-Doctrine PHP services.
• Feature: field-level encryption at rest. Enables column-level encryption for sensitive attributes (PII, PHI, financial identifiers, auth secrets) declared on Doctrine entities, with minimal schema churn.
• Roadmap: compliance enablement. Useful as a tactical lever for GDPR/HIPAA/PCI/SOC 2 obligations that require sensitive columns to be unreadable at the storage layer. It addresses storage encryption, not access control, audit logging, or key lifecycle — those remain separate roadmap items.
• Build vs. buy vs. borrow. The honest framing is borrow. The delta between this package and a hand-rolled Doctrine Type + event subscriber is small (a few hundred LOC). The real decision is whether to own that code or adopt a maintained cryptographic stack (libsodium/paragonie/halite, a cloud KMS SDK, envelope encryption).
• Use cases where it fits: retrofitting encryption into an existing Doctrine schema without a migration-heavy redesign; internal tooling; prototypes where data sensitivity is moderate and the blast radius of a bug is contained.
• Use cases where it does not fit: searchable/indexable ciphertext, per-tenant key isolation, key rotation, or any system where an auditor will ask "who maintains this and when was it last patched?"

When to Consider This Package

Adopt-consider criteria:

• The consuming service is Symfony + Doctrine ORM (or Doctrine standalone). Laravel/Eloquent shops should stop here — there is no integration path without adding Doctrine first.
• You need only straightforward symmetric column encryption, applied via entity annotations/attributes, with no querying on encrypted fields.
• You are willing to treat it as source code, not a dependency: vendor it, pin it, fork it, and assign an owner. Zero stars and zero dependents means no community backstop, no CVE watch, and no maintenance cadence to rely on.
• Security engineering can review the implementation — cipher selection, IV/nonce generation, key derivation, and key storage. The description's claim of "verified and standardized libraries" is a claim; validate it against the actual composer constraints and code path.
• Your key management story is already solved elsewhere (env/KMS/secret manager) and this package only needs to consume a key.

Look elsewhere when:

• You need key rotation, envelope encryption, HSM/KMS-backed keys, or per-tenant key isolation.
• You need deterministic/searchable encryption or format-preserving tokenization.
• Procurement or compliance requires vendor support, an SLA, release history, or active security response.
• The team's default stack is Laravel — evaluate laravel-doctrine/orm plus a maintained encryption layer, or an Eloquent-native alternative, instead.
• The package's Doctrine/PHP version constraints don't match your runtime; with no dependents, compatibility lag is likely and unowned.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed helper that encrypts individual database columns in Symfony/Doctrine applications. It can close a compliance checkbox quickly, but the project has no visible community, no dependents, and no maintenance signal — so it is not a strategic dependency we should standardize on. Recommendation: use it as a reference implementation or in contained internal contexts only, and budget a short spike to decide between forking it under our ownership or building the equivalent in-house on a managed key service. Licensing (MIT) is not a concern; supply-chain and cryptographic correctness are.

For engineering: Integration cost is genuinely low — a Doctrine type plus an event subscriber, configured per entity. The cost you inherit is ownership. Two viable paths: (1) vendor and fork, ~1 week to audit the cipher/IV/key-derivation path and add tests, then own it; or (2) implement the same behavior in-house against libsodium with keys from our managed KMS, which gives us rotation and auditability the package doesn't offer. Do not add it as an unpinned dependency. Either way, keep key management and rotation out of scope of the library and in our platform layer.

For security and legal: MIT license is permissive and compatible with commercial use. The residual risks are (a) unmaintained cryptography code and (b) unverified claims about the underlying primitives. Both are addressable with a focused review before any production use, and both argue for fork-and-own rather than consume-as-is.