Product Decisions This Supports
- Multi-tenant / per-user data isolation: The headline feature in v3.0.0-alpha1 ("per user encryption," PR #41) changes the package from app-wide crypto helpers into a mechanism for encrypting data against an individual user or tenant key. That directly supports decisions like: can we safely host multiple customers in one database, and can we promise tenant-scoped key separation to enterprise buyers?
- Data-subject and deletion workflows: Per-user encryption unlocks crypto-shredding — deleting or rotating a user's key renders their encrypted payload unrecoverable without a row-by-row hard delete. This affects how we design "right to be forgotten," account deletion, and tenant offboarding.
- Regulatory / compliance posture: Enables roadmap commitments around PII at rest (GDPR/CCPA-style subject controls, HIPAA-adjacent workloads, SOC 2 evidence). The decision it informs is whether we can claim per-customer key isolation in security questionnaires and RFPs.
- Build vs. buy: Gives a credible "adopt" option for envelope/per-user encryption so the team does not hand-roll key derivation, rotation, and serialization. The counterfactual (in-house crypto) is high-risk and slow — this package shortens the path.
- Enterprise tiering: Per-user keys can underpin a paid "customer-managed / isolated encryption" tier, making this a monetization-relevant capability rather than pure infrastructure.
- Migration planning: The major-version jump (v2 → v3) is itself a decision point: schedule an upgrade, freeze on v2, or defer adoption until v3 stabilizes.
When to Consider This Package
Consider it when:
- You store user- or tenant-scoped sensitive data (PII, credentials, health/financial records) in a Laravel app and need isolation stronger than a single app-wide key.
- You need per-user key lifecycle (rotation, revocation, crypto-shredding) without building a KMS integration from scratch.
- You want a Laravel-native implementation that fits existing Eloquent casts, queues, and config conventions rather than a bespoke crypto layer.
- Your compliance or sales motion requires demonstrable per-customer key separation.
Look elsewhere or wait when:
- Production stability is required now. v3.0.0-alpha1 is a pre-release on a new major version; the API can change before GA. Do not ship it behind a compliance claim without pinning and testing.
- You need certified key management — FIPS 140-2/3, HSM-backed keys, cloud KMS/Secrets Manager as the root of trust. App-level per-user encryption complements but does not replace a managed KMS.
- Your threat model includes host compromise or DB+app-server compromise; application-layer keys held by the app offer limited protection there.
- You have no PII / low regulatory exposure, where a single framework key and standard Laravel encryption is sufficient and this adds operational overhead.
- You require audited, externally reviewed cryptography; treat any small-team package as needing internal security review before sensitive use.
Adoption gate for this release: pin to the alpha only in a non-production branch, validate the per-user key model against existing encrypted data (v2 → v3 migration/re-encryption path is not described in the notes), confirm rotation/revocation and backup semantics, and get a security review sign-off before any customer-facing claim.
How to Pitch It (Stakeholders)
For executives: This release adds per-user encryption, which lets us isolate each customer's data with its own key. Practically, that means we can answer enterprise security reviews more convincingly, support "delete my data" in a way that is provably irreversible, and potentially sell an isolated-encryption tier — without a multi-quarter in-house crypto build. It is an alpha of a new major version, so the near-term recommendation is to evaluate it, not to bet a compliance commitment on it; budget a security review and a migration spike before GA.
For engineering: The package is Laravel-idiomatic and removes the need to hand-roll key derivation and per-user key handling. The v3 line is a breaking change from v2, and the changelog for this alpha only surfaces the per-user encryption feature, so treat the upgrade path, key storage, rotation, and re-encryption of existing data as unknowns to be verified. Recommended next steps: spike on a branch, audit the key lifecycle and failure modes, confirm it composes with queues and existing casts, and pin the version until GA.