Ciphersweet Encrypt Laravel Package

Product Decisions This Supports

• Compliance-gated feature work. If the roadmap contains PII-heavy features (patient records, KYC documents, SSN/tax IDs, support transcripts, contact details), this package points at the core pattern that unblocks them: field-level encryption at rest plus the ability to query by exact value via CipherSweet blind indexes. That combination is usually the gating constraint — teams default to "we can't ship search on encrypted data," and this class of tooling removes that excuse.
• Build vs. buy on the encryption layer. The decision this really informs is not "adopt this repo" but "standardize on CipherSweet (maintained, security-focused, by Paragon Initiative) and treat this repo as a reference implementation for the glue." The package itself is ~one DBAL custom type; the intellectual property is upstream.
• Feature scoping: what will not be searchable. Blind indexes support equality lookups only — no LIKE, ranges, ORDER BY, or fuzzy match on encrypted columns. This directly constrains product surface: admin search, sorting by encrypted fields, and reporting must be designed around plaintext-derived aggregates or secondary stores. That is a roadmap decision, not an engineering detail.
• Data-model and migration planning. Encrypting an existing column means backfill, dual-write windows, index rebuilds, and a key-rotation story. Deciding when this lands determines whether it's a cheap greenfield decision or an expensive migration program.
• Roadmap risk register / tech-debt triage. Last release 2020, one star, zero dependents, single maintainer — this is a signal for the dependency-approval policy, not a plan for a specific sprint.

When to Consider This Package

Consider it (as an architectural reference, not a runtime dependency) when:

• You need equality-searchable encryption — "find the user by email" or "match this SSN" — and plaintext-in-DB is off the table for legal or contractual reasons.
• You want per-tenant key separation; CipherSweet's key-provider model maps cleanly to tenant-scoped keys, which is often a hard requirement in B2B/healthcare.
• You need key rotation without a full-table rewrite — blind indexes and ciphertexts are versionable, which is a real operational advantage over naive encrypt() columns.
• You are on Doctrine DBAL (Symfony, Doctrine-based ORM) and want transparent encrypt/decrypt at the type layer.

Look elsewhere — or rather, go directly to CipherSweet or a maintained alternative — when:

• Your app is Eloquent-first. This is a Doctrine DBAL type with no Laravel service provider, config publishing, or Eloquent cast. The integration friction outweighs the ~200 lines it saves, and you'd be shipping a package whose API surface you'd have to fork anyway.
• You need LIKE search, ranges, or sorting on encrypted fields. No CipherSweet integration provides this; you need searchable-index-as-a-service, a tokenized index, or a re-architecture.
• You need a maintained dependency with a CVE/patch path. 2020 release, no recent activity, and pre-modern CipherSweet API versions mean you are effectively adopting unmaintained code in a security-critical path.
• Your compliance posture requires third-party audit evidence for the crypto boundary. CipherSweet has a stronger story; this wrapper does not.
• You're already on Laravel's encrypted cast and only need confidentiality with no lookup requirement — that's cheaper and first-party.

How to Pitch It (Stakeholders)

For executives: We have a recurring blocker where compliance or customer contracts require sensitive fields to be unreadable in the database — but Product also needs to look records up by email, member ID, or SSN. Historically we've picked one or the other. The underlying technology (CipherSweet) lets us do both: values are encrypted, and we keep a separate non-reversible index for exact-match lookups. That unblocks a class of features we've been deferring, and it's an established pattern rather than something we'd invent.

The honest caveat to leadership: the specific package under review is a thin, single-maintainer wrapper — one star, no dependents, last shipped in 2020. I'm not recommending we take a runtime dependency on it. I'm recommending we standardize on CipherSweet directly and budget roughly a sprint of engineering to build and own the ~200 lines of framework glue. That's the same work either way, except we own it and it stays patched. Estimated scope: one sprint for the integration, plus a follow-on migration effort per encrypted column (backfill + key management), and a standing constraint that encrypted fields are exact-match only — no fuzzy search, no sorting.

For engineering: treat this repo as prior art. Read it for the DBAL type pattern, then implement the equivalent on top of current CipherSweet with a KMS-backed key provider, key-version tagging, and a documented rotation runbook. Non-negotiable: the key management story lands before the first encrypted column ships.