Eloquent Encryptable Laravel Package

Product Decisions This Supports

• Data-at-rest compliance scoping. Packages like eloquent-encryptable (v0.1.3) let a team satisfy "PII must be encrypted in the database" requirements at the model layer without a schema migration or a database-level encryption project — a fast path for GDPR/CCPA/HIPAA-adjacent obligations on fields such as names, emails, phone numbers, and government IDs.
• Build vs. buy vs. adopt. The alternative is hand-rolling encrypted casts plus key management in every model. A package consolidates that into a trait, which reduces duplicated crypto code — but at v0.1.x it is a source of leverage, not a strategic dependency: plan for the option to fork or vendor it.
• Feature-level go/no-go on searchable fields. Encrypted columns are not queryable with WHERE, LIKE, sorting, or unique constraints. This package therefore forces an explicit product decision per attribute: encrypt it and lose filtering/reporting, or keep it plaintext and accept the risk. Surface that trade-off before commit, not after.
• Roadmap sequencing. If encrypted search, blind indexes, or per-tenant keys are on the roadmap, a v0.x package makes that a later investment (build or replace) rather than something you get for free — it should be sequenced as its own epic.
• Scoping of analytics and support tooling. Because values are opaque in the DB, admin dashboards, exports, and support "find user by email" flows need application-level decryption paths. Budget that work in the same epic as adoption.
• Migration and key-rotation planning. Product-visible decisions (can we rotate keys without downtime? can we re-encrypt historical rows?) belong in the plan, since key loss equals irreversible data loss.
• Not a decision this supports: field-level access control, masking in logs, or audit trails. Encryption at rest is not an authorization model, and adopting the package should not be pitched as closing those gaps.

When to Consider This Package

Consider it when:

• You have a small, well-defined set of sensitive scalar attributes (few columns, few models) and a compliance or security-review requirement to encrypt them at rest.
• You are already on Laravel's APP_KEY / encrypter infrastructure and are comfortable with its operational model (key custody, rotation, environment parity).
• You can tolerate losing SQL-level querying on those columns — or you have a deliberate plan (blind index, separate search store) for the fields that need it.
• The team is small and time-constrained, and vendoring or forking a ~v0.1 dependency is acceptable risk for the velocity gained.
• You need a prototype or MVP to demonstrate encryption-in-place before committing to a heavier solution.

Look elsewhere (or build) when:

• The package version is pre-1.0 with an opaque release history — the v0.1.3 changelog contains no described changes, so there is no way to assess what moved between v0.1.2 and v0.1.3. Treat every bump as a potential silent behavior change and pin the version.
• You need encrypted search, range queries, or uniqueness on sensitive fields — you need blind-index or deterministic-encryption support, which this does not advertise.
• You require separate keys per tenant, envelope encryption, HSM/KMS integration, or audited key rotation — that is an infrastructure concern, not a trait.
• You have high-volume or bulk-processing workloads, where per-attribute decrypt calls become a measurable performance cost, or large text/blob columns where ciphertext expansion matters.
• You have many models and many columns — the per-attribute opt-in becomes maintenance overhead that a schema-level or database-level approach handles better.
• Your security review requires maintained dependencies with SLAs, disclosure policy, and a versioning contract that a v0.x package cannot provide.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost library that lets us encrypt specific sensitive customer fields in the database without a major platform project. It accelerates a compliance checkbox — "PII is encrypted at rest" — for a defined set of columns, and it is reversible: it's a trait on models, not a schema or vendor commitment. The trade-off to fund is that encrypted fields can no longer be searched or filtered directly, so any admin or reporting flow that looks up those fields needs application-side work, and key management becomes a real operational responsibility (losing the key means losing the data). Recommendation: adopt narrowly for a pilot set of fields, pin the version, and treat it as an interim layer.

To engineering: It's a trait that transparently encrypts/decrypts model attributes using Laravel's encrypter. Two constraints drive the design: encrypted columns are unqueryable, so decide per attribute whether you're willing to give up WHERE/LIKE/ORDER BY/unique indexes on it; and key rotation plus historical re-encryption must be designed up front, not retrofit. It's at v0.1.3 with an empty published changelog, so pin the exact version, vendor or fork if it's load-bearing, and add tests around serialization, toArray(), and casts so a silent patch release surfaces immediately. Do not present it as access control — it's encryption at rest only.