Weave Code
Doctrine Encrypt Laravel Package
51systems/doctrine-encrypt
Transparent field-level encryption for Doctrine entities in Laravel. Custom DBAL types and event subscribers encrypt sensitive columns at rest, keeping normal ORM reads and writes seamless while protecting stored data.
Package allows you to create Doctrine entities with fields that will be protected by encryption algorithms such as AES.
Frequently asked questions about Doctrine Encrypt
- Can I use 51systems/doctrine-encrypt in an Eloquent-based Laravel app?
- No, this is not an Eloquent-native package; it encrypts Doctrine ORM/DBAL fields, so it only fits a Laravel app that already uses Doctrine through a bridge such as Laravel-Doctrine. For typical Eloquent models, use Laravel's encrypted casts, a custom cast, or database/KMS envelope encryption instead. Forcing this package into an Eloquent codebase adds architectural mismatch and little leverage.
- How do I install 51systems/doctrine-encrypt in Laravel?
- Install it with Composer and register the custom DBAL types and event subscribers in your Doctrine configuration, but the package was archived in 2017 and has no modern Laravel integration. Expect dependency resolution conflicts with current PHP and Doctrine ORM/DBAL versions. Run a compatibility spike and avoid greenfield adoption.
- Which Laravel and PHP versions does doctrine-encrypt support?
- The last release was in 2017, so there is no declared support for modern Laravel or PHP versions. Compatibility depends entirely on the Doctrine ORM/DBAL versions your app can resolve and whether the package's old constraints still install. Test Composer resolution, static analysis, and encrypt/decrypt round trips before assuming support for Laravel 10, 11, or current PHP.
- How does field-level encryption work with Doctrine entities?
- The package uses custom Doctrine DBAL types and event subscribers to encrypt sensitive columns on write and decrypt them on read. That keeps normal Doctrine entity reads and writes largely seamless while data is encrypted at rest. It does not provide the same transparent behavior for Eloquent models, and you must still review the cipher, mode, IV/nonce handling, and key storage.
- Is 51systems/doctrine-encrypt safe for production?
- Treat it as high risk for production because the package is archived, has no upstream security patching, and carries outdated cryptography and key-management assumptions. It may be tolerable only for an existing Doctrine-based system with low-sensitivity data, explicit internal ownership, and a funded exit plan. Do not use it for new work or regulated data without a security review.
- Can I query, sort, or index encrypted Doctrine fields?
- Encrypted columns generally cannot be searched, sorted, joined, or indexed normally unless the package uses deterministic encryption. Deterministic encryption enables equality lookups but leaks patterns and requires an explicit leakage trade-off. Plan reporting, filtering, and indexing before encrypting fields, because you may need blind indexes or application-side search.
- What are alternatives to doctrine-encrypt for Laravel encryption?
- For Eloquent-based Laravel apps, prefer Laravel's built-in encryption with encrypted casts, a custom cast backed by KMS, or database-level envelope encryption. For Doctrine-based apps, use a maintained Doctrine encryption package or an application-owned encryption service behind a repository boundary. Avoid adopting an archived package just for field-level encryption.
- How should I test encryption and decryption with this package?
- Write round-trip tests that save an entity, reload it through Doctrine, and assert the plaintext is restored while the raw database column is ciphertext. Also test schema tooling, migrations, fixtures, serialization, null handling, and key rotation behavior. Keep the proof of concept on one low-risk field in a non-production environment first.
- Does doctrine-encrypt support key rotation and key management?
- The package has no clear, modern key-management or rotation story, and its 2017-era design predates common KMS-backed rotation patterns. Assume you must own key storage and implement decrypt-and-re-encrypt or dual-read/dual-write migration yourself. Define rotation and incident response before any production data is encrypted.
- What maintenance risks should I expect from a 2017 archived package?
- An archived 2017 package has no upstream maintenance, so any bug, security issue, or PHP/Doctrine compatibility break becomes an internal fork obligation. Community scrutiny and adoption are low, which raises the risk of unnoticed cryptographic or integration problems. Budget for documentation, patching, and an exit plan rather than treating it as a strategic dependency.
Weaver
How can I help you explore Laravel packages today?