Doctrine Encryption Extension Laravel Package

Product Decisions This Supports

• Compliance scope for a specific feature or data domain. Field-level (application-layer) encryption is what satisfies auditors when disk-level TDE isn't enough — e.g. PII/PHI/PCI columns that must be unreadable to DBAs, cloud provider staff, or anyone with a database snapshot/backup. This package is a candidate only for those named columns, not the whole schema. Use it to answer: "Which fields must we encrypt to close this control gap, and what's the smallest change that does it?"
• Build vs. buy for column encryption. The build option is a Doctrine custom type + key provider + migration; this package (or a fork) is the buy/shortcut option. Decision inputs: how many entities/columns, whether keys come from env vars vs. a KMS, and whether you accept a low-adoption dependency. Note the "free" alternative if the team is on Eloquent: Laravel's built-in encrypted cast already covers the common case.
• ORM strategy / architecture direction. This is a Doctrine 2 extension, not Eloquent. Adopting it in a Laravel app implies laravel-doctrine (or a mixed ORM setup) — a multi-sprint architectural decision, not a package install. It's more naturally a fit for Symfony/Doctrine services. This should be framed as "does this feature justify introducing Doctrine?" rather than "should we install this package?"
• Searchability tradeoff, which is a real product decision. Application-layer encryption typically means ciphertext columns can't be WHERE-filtered, sorted, LIKE-searched, or uniquely indexed (unless deterministic encryption is used, which leaks equality patterns). That directly blocks features like "find user by email," admin search, dedupe, and reporting. Product must decide up front: encrypt-but-unsearchable, add a blind index / keyed hash column for exact-match lookups, or leave the field plaintext and rely on access controls. Retro-fitting this after shipping is expensive.
• Key management and rotation roadmap. The package encrypts; it doesn't solve where keys live, envelope encryption, per-tenant keys, or rotation with re-encryption of existing rows. That's a platform-level workstream with its own cost and on-call implications — worth scoping as a dependency before committing to encrypted columns.
• Data residency / multi-tenant isolation. Per-tenant or per-region keys are the usual reason teams go application-layer rather than TDE. If that's on the roadmap, evaluate whether the key-provider abstraction here is pluggable enough.
• Migration and rollback planning. Encrypting existing columns means backfill jobs, dual-read/dual-write windows, and a rollback path (you can't "un-encrypt" a bad deploy cheaply). This is a release-planning decision with downtime and data-loss risk, not just a code change.

When to Consider This Package

Consider it when all of these hold:

• The service is already on Doctrine ORM 2 (Symfony, or Laravel with laravel-doctrine), and adding a custom Doctrine type is a low-friction change.
• You have a small, well-bounded set of sensitive columns (a handful of entities), and those columns don't need to be searched, sorted, or uniquely indexed — or you're prepared to add separate blind-index columns for lookup.
• You need application-layer encryption specifically (threat model includes DBAs, backups, snapshots, or the managed-DB vendor), beyond what TDE/at-rest disk encryption gives you.
• Your team can read, audit, and vendor/fork the code. With effectively zero stars and zero dependents, treat it as source you own, not a maintained dependency: pin it, review the crypto (cipher choice, IV/nonce handling, authenticated encryption, key derivation), and be ready to maintain it yourself. Provenance from a security-focused org (YesWeHack) is a mild positive signal, not a guarantee of maintenance.
• Key sourcing fits your model — env/KMS-injected key via a provider interface, no hardcoded secrets, rotation story understood.

Look elsewhere — or don't do this at all — when:

• You're on Eloquent. Use Laravel's native encrypted cast (and encrypted:array/:json); introducing Doctrine for this is almost certainly the wrong trade.
• You need searchable encryption, range queries, or sorting on encrypted fields. Look at blind-index/hash-column patterns, or a KMS-backed tokenization service; this package won't give you that.
• You need managed key lifecycle (AWS KMS / GCP KMS / Vault envelope encryption with automated rotation) as a first-class feature. You'll be building that layer yourself around this.
• A maintained, widely adopted alternative exists for your stack — e.g. the established Doctrine encryption bundles, or paragonie/halite-based column encryption. Prefer something with a real issue tracker and release cadence.
• You need format-preserving encryption, per-field access policies, or auditor-facing key-separation evidence. Those are vendor/procurement territory.
• Compliance requires FIPS-validated crypto modules. Verify the cipher implementation first; don't assume.

Also weigh: performance (per-row encrypt/decrypt on hydration and on every query result), bulk import paths that bypass the ORM type and would write plaintext, and any reporting/analytics pipeline that reads the table directly — encrypted columns break those silently.

How to Pitch It (Stakeholders)

For executives (one paragraph): We have a compliance requirement to protect a small number of sensitive data fields (PII/health/payment data) at the application layer, so they remain unreadable in database backups, snapshots, and to anyone with database access. This package is an open-source Doctrine extension that does that transparently. The tradeoffs are: it's a low-adoption dependency we'd effectively own and audit ourselves, it requires dedicated key-management work, and encrypted fields can't be searched or sorted the way they are today — which may limit some reporting and admin features. Recommendation: treat it as a spike, not a commitment — one sprint to prototype on the target columns, prove out key handling and the search limitation, then decide build vs. buy with real numbers. If the app is Eloquent-based, the answer is likely Laravel's built-in encryption and this evaluation closes immediately.

For engineering (bullets):

• Doctrine 2 custom-type extension; encrypts/decrements at the ORM layer. Confirm supported Doctrine version and whether it uses attributes or annotations.
• Read the crypto before adopting: cipher, authenticated encryption (AEAD), nonce/IV handling, key derivation, and whether decryption failures are handled safely. Audit the whole codebase — it's small enough, and there's no community review to lean on.
• Expect to vendor/fork and pin; no release cadence or dependent ecosystem to rely on.
• Design in the constraints: no WHERE/ORDER BY/LIKE/unique index on encrypted columns unless deterministic; plan blind-index columns for exact-match lookups (e.g. hashed email for login).
• Plan the migration: backfill job, dual-read window, rollback path, and an inventory of code paths that write those columns outside the ORM (raw SQL, bulk loads, queue workers, analytics exports).
• Key management is the real project: KMS/Vault integration, rotation, per-environment and per-tenant keys, and a documented break-glass procedure.
• Success criteria for the spike: target columns encrypted end-to-end, key rotation demonstrated on a copy of production data, no measurable latency regression on the hot read path, and a written list of product features the encryption blocks.