Product Decisions This Supports
- Build vs. buy vs. abstract: This package answers none of the "what do we encrypt with" question — it ships only contracts (interfaces), no cipher implementation, no key management, no config. It is the seam, not the engine. The PM decision it actually informs is "should our encryption layer be interface-driven and swappable, or hardcoded to one library?" — and by existing at all, Marko has already answered "swappable" for its own ecosystem.
- Feature feasibility for encryption-at-rest work: If your roadmap includes PII column encryption, encrypted queue payloads, signed/encrypted cookies, or secret-at-rest storage, the contract surface here (encrypt/decrypt-style methods behind an interface) maps directly onto the work breakdown. It tells you the shape of the integration point before you commit engineering time.
- Testability as a first-class requirement: A contract-first design means test fakes and no-op drivers are trivial. This supports a roadmap decision to make crypto a mockable dependency in test suites rather than a global static — a real velocity and safety win on any team with CI.
- Vendor and exit-risk assessment: With 0 stars, 0 dependents, and a
[READ-ONLY] subtree-split description, this is not a product with a market — it is an internal monorepo artifact published for Composer resolution. The decision it supports is dependency policy: do we allow single-maintainer, zero-adoption framework internals into our supply chain, and under what conditions?
- Framework adoption gating: Anyone considering Marko should read this package as a signal about framework maturity. Contracts exist; the ecosystem around them does not. That is a roadmap input for whether Marko is viable for your next service, independent of the encryption feature itself.
- Use cases it unlocks (once you supply a driver): encrypted database columns, encryption of serialized job payloads, at-rest secrets for multi-tenant config, envelope encryption with per-tenant data keys, and deterministic-hash lookups over encrypted fields.
When to Consider This Package
Consider it when all of the following hold:
- You are already committed to the Marko framework. This is a Marko-specific contract package; it is not Laravel, Symfony, or framework-agnostic PSR. There is no bridge, and none is implied.
- You intend to write your own encryption driver — you want the interface to program against and a clean seam for swapping drivers (OpenSSL, Sodium, a KMS-backed implementation) later.
- You need interchangeable crypto backends across environments (real driver in prod, deterministic fake in tests, no-op in local).
- Your team accepts interface-only dependencies and understands that security review, key rotation, nonce/IV handling, and error semantics are your responsibility, not the package's.
- You are comfortable with near-zero external adoption (0 dependents) and treat upgrades as "read the diff in the parent monorepo," not "trust semver."
Look elsewhere when:
- You are on Laravel. Use the framework's
Illuminate\Encryption\Encrypter / Crypt facade, encrypted and encrypted:array casts, and APP_KEY rotation tooling. Mature, documented, tested. This package adds nothing.
- You need a working implementation today. Nothing here encrypts anything. For standalone PHP, look at
defuse/php-encryption, paragonie/halite, or spatie/crypto rather than assembling a driver from scratch.
- You need KMS/HSM integration (AWS KMS, GCP KMS, Vault). That work is entirely unbudgeted here.
- Your dependency policy flags single-maintainer, zero-adoption, read-only-split packages — which is most regulated or security-sensitive orgs.
- You need guarantees. Contracts ship no test vectors, no documented threat model, and no compatibility promise. For crypto, that silence is a cost.
How to Pitch It (Stakeholders)
To executives (one paragraph): We evaluated marko/encryption as a candidate for our encryption work. It is an MIT-licensed set of interfaces only — it defines how encryption plugs into the Marko PHP framework but provides no encryption itself, no key management, and no production adoption (0 stars, 0 dependent projects; published read-only from the Marko monorepo). Cost to adopt is effectively zero, but so is value delivered out of the box: everything that actually protects data still has to be built and security-reviewed by us, and it only works if we standardize on Marko. My recommendation is no standalone investment; treat it as a design reference for interface-driven crypto and a maturity indicator for Marko, not as a procurement decision. If we do not adopt Marko, this package is out of scope entirely.
To engineering: The surface is small and the intent is good — depend on an interface, not a cipher. That gives us driver swaps, a clean test fake, and no vendor lock at the call site. Two caveats before you write code against it: (1) the interface is Marko-flavored, so porting it to Laravel or a framework-agnostic service means rewriting the contract and losing the point of using it; (2) with zero dependents and no release history, treat every upgrade as a manual diff review. If we proceed, the real work item is not integration — it's the driver, key lifecycle, rotation, and the security review, none of which this package covers. Pitch: "Adopt the pattern — dependency-inverted crypto with a swappable driver — even if we don't adopt the package." That framing is defensible regardless of which framework wins.
Ask: approve the pattern (interface + injectable driver + test fake) for the upcoming encryption-at-rest work; defer any decision on Marko until the framework itself clears an adoption review.