Encryptable Laravel Package

Product Decisions This Supports

• Build vs. buy for field-level encryption. The package provides transparent attribute-level encrypt/decrypt for Eloquent models across Laravel, Webman, Hyperf, ThinkPHP, and plain PHP. This is table-stakes infrastructure, not differentiation — the default decision should lean "adopt," and PM time is better spent on key-management policy than on re-implementing cipher handling.
• Key-rotation roadmap (compliance-critical). previous_keys now accepts the base64: prefix format used by the master key. Practically, this means we can rotate the primary encryption key and still decrypt historical records during the transition window, with a single key format across primary and legacy keys. That directly supports SOC 2 / ISO 27001 key-rotation controls, GDPR erasure-and-reissue workflows, and any customer security questionnaire asking "how often do you rotate keys?"
• Multi-framework / multi-service consolidation. The v2.0.13 fix makes validation rules read the actually resolved encrypter cipher, and does so identically across four framework integrations plus native PHP. For a polyglot PHP estate (e.g., a Laravel monolith plus Hyperf or Webman services), this removes a real divergence risk: the same config source produces the same cipher behavior everywhere, including in validators.
• Fewer "validated but undecryptable" defects. Validation rules previously risked disagreeing with the runtime cipher (e.g., length/format checks tuned for AES-256 while the resolved cipher is AES-128). This patch closes that class of bug. For the PM this is a QA-surface reduction on every form that touches an encrypted column — fewer escaped defects, less manual regression on security-adjacent flows.
• Cheap handling of mixed plaintext/ciphertext state. The documented isEncrypted() lightweight format check enables idempotent backfill jobs, conditional display logic, and safe re-encryption migrations without trial decryption or try/catch control flow. This is the feature that makes incremental rollout of encryption to existing columns viable rather than a big-bang migration.
• Onboarding and vendor-risk cost. Synchronized EN/CN README (PHP 8.0+ baseline, Encryption::db()->encrypt() usage, project structure) lowers integration time for offshore/partner teams and reduces the "we couldn't figure out the API" tax during a spike.
• Release hygiene signal. Auto-generated release notes in CI is a maturity indicator worth noting in build-vs-buy scoring: it suggests sustained maintenance rather than a one-off internal extraction.

When to Consider This Package

Adopt when:

• You store PII or regulated data (email, phone, national ID, addresses, tokens) in relational columns and want encryption at the ORM layer rather than in application code scattered across services.
• You need decryption continuity across key rotation — i.e., previous_keys is a hard requirement, not a nice-to-have.
• You run more than one PHP framework/runtime and want one encryption library and one config contract.
• You want a low-ceremony migration path: additive adoption per model/column, with isEncrypted() supporting gradual backfill.
• Your runtime is PHP 8.0+ (now the documented baseline — verify your oldest service).
• You want a validation rule for encrypted fields that is guaranteed consistent with the cipher actually in use.

Look elsewhere or scope carefully when:

• You need to query ciphertext. Equality/range search on encrypted columns requires deterministic encryption or blind indexes. Confirm support explicitly; if your product requires "search users by email" on an encrypted column, that's a design decision this package does not make for you.
• You need envelope encryption with KMS/HSM. AWS KMS, GCP KMS, or Vault Transit give you audited key custody, per-tenant data keys, and rotation without redeploying config. This package manages keys via configuration — a weaker custody model.
• You need per-tenant or per-record keys. Config-level key sets don't scale to thousands of tenant keys.
• Your DB already provides what you need. TDE / encryption-at-rest covers the "stolen disk" threat; field-level encryption's value is defeating DBAs, backups, and read replicas. Be honest about which threat you're buying against.
• You cannot accept small-maintainer risk on cryptographic code. This appears to be a single-maintainer package. Crypto is high-blast-radius: a subtle bug is a data-loss or data-exposure event. Before production adoption, require an internal code read of the cipher/key-handling paths, a pinned version, a monitored advisory channel, and a documented exit path (ciphertext format must be recoverable by your own code if you ever fork).
• You're on 1.x. v2.0.x implies breaking changes from the prior major. Read the 2.0.0 notes before planning the upgrade, not just this patch.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost dependency that materially shrinks our compliance and breach blast radius. It encrypts sensitive customer fields inside the application, so the data is unreadable in database backups, read replicas, and to anyone with raw DB access — the scenarios that actually drive breach cost. The latest release makes key rotation operationally safe: we can change encryption keys on a schedule and still read historical records, which is the control auditors ask about. Cost is integration time, not licence spend, and adoption can be incremental, model by model.

To engineering: Drop-in trait-based field encryption, PHP 8.0+, one config source that behaves identically under Laravel, Webman, Hyperf, ThinkPHP, and vanilla PHP. This release fixes validation rules to key off the resolved encrypter cipher (no more validator/runtime cipher drift), lets previous_keys use the same base64: format as the master key, and documents isEncrypted() for cheap format checks so backfills and mixed-data columns are safe and idempotent. Known boundaries: no searchable encryption, no KMS/HSM envelope model, config-level key custody only.

To security/architecture (the honest caveat to include): We are adopting a single-maintainer cryptographic component. Recommend: pin the version, review the key-derivation and cipher-selection code paths once, log key-rotation events, and keep an exit plan (our own decrypt utility against the documented ciphertext format) so we are never locked in. If we later need per-tenant keys or audited key custody, that's the trigger to move to KMS-backed envelope encryption — and this package's ciphertext format should be treated as a migration constraint from day one.