Config Secrets Laravel Package

Product Decisions This Supports

• Secrets-management strategy: whether to keep application secrets as encrypted files committed alongside config (this package) versus standing up an external secret store (HashiCorp Vault, AWS/GCP Secrets Manager, Doppler). This is a build-vs-buy-vs-adopt decision with real cost and operational implications.
• Security/compliance roadmap: eliminating plaintext secrets from repositories is a common audit finding (SOC 2, ISO 27001, internal security reviews). This package is a low-lift way to close that gap for Laravel services.
• Deployment and environment parity: teams that struggle with .env drift across environments can standardize on encrypted config committed to the repo, decrypted at boot with a single key.
• Developer onboarding speed: new engineers can clone and run without a secrets handoff ritual, as long as they have the decryption key.
• Prioritizing vs. deferring a "proper" secrets platform: this is the pragmatic interim bet while a centralized secrets platform is scoped and funded.

When to Consider This Package

Adopt when:

• You run one or a few Laravel/PHP services with a modest, slowly-changing secret set.
• Your threat model is "secrets must not sit in plaintext in git" rather than "secrets must never touch the repo or CI."
• You want zero new infrastructure and a Laravel-native developer experience.
• You can manage the decryption key out-of-band (CI secret store, KMS, or environment injection) with discipline.

Look elsewhere when:

• You need audit trails, automatic rotation, dynamic/short-lived credentials, or fine-grained per-service access control — Vault or a cloud secret manager is the right call.
• Compliance requires KMS/HSM-backed envelope encryption or separation of duties on key custody.
• You have many services, many secrets, or frequent rotation; key distribution becomes the bottleneck.
• Your team cannot reliably protect the single decryption key — the package concentrates risk there.

Signal from v7.1.0: the addition of a Trivy security-scanning workflow is a maintainer-hygiene improvement, not a product capability. It supports a "this project takes supply-chain security seriously" narrative but should not drive adoption decisions on its own.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost package that removes plaintext secrets from our Laravel repositories — a common audit finding — without buying or operating new infrastructure. It reduces leak risk and speeds onboarding. The residual risk is key custody, which we address through our existing CI secret store. The recent release adds automated vulnerability scanning to the project's own pipeline, a modest signal of maintainer maturity.

To engineering: It's a Laravel-native way to commit encrypted secrets and decrypt them at runtime, keeping config in the repo and deployments reproducible. The trade-off is that the decryption key becomes a single point of failure and must be handled deliberately in CI and local dev. It is not a replacement for Vault or cloud secret managers if we later need rotation, auditing, or dynamic credentials — treat it as the pragmatic step now, with a clear trigger for revisiting.