Laravel Credentials Laravel Package

Product Decisions This Supports

• Treat it as a spec, not a dependency. The package is a complete, working reference implementation of "editable encrypted credentials in a Laravel app": a published config file, a migration creating a credentials table, encrypted casting via Laravel's Crypt, a credentials() helper plus facade, and a Blade admin UI guarded by configurable middleware. Rebuilding that shape in-house is roughly one to two engineering days. The decision on the table is "do we want this pattern?", not "do we adopt this code?"
• Feature validation for non-engineer secret rotation. It proves out a workflow where ops or support can rotate a third-party API key (Stripe, SMTP, analytics, OAuth client secrets) through an admin screen rather than filing an engineering ticket or waiting on a deploy. If "let non-engineers manage integration secrets" is a roadmap candidate, this is a cheap way to pressure-test demand before funding a real secrets platform.
• Per-tenant integration credentials. If your product stores customer-supplied keys — a tenant's Stripe key, a customer's SMTP password — the table shape here (one encrypted row per dotted key, namespaced by tenant and environment) is a reasonable starting sketch for a first-party module.
• An honest forcing function on scope. There is no rotation, no versioning, no audit trail, no per-secret access control, and no envelope encryption. Choosing this pattern explicitly defers all of that, which is a useful prompt: are rotation and audit v1 requirements or post-PMF concerns? Retrofitting them onto a single APP_KEY-encrypted table is materially harder than designing them in from the start.
• Compliance scoping. Storing secrets in the primary database, encrypted with the same APP_KEY that protects sessions, means the secret store's blast radius equals the application's blast radius. That is a SOC 2 / PCI / HIPAA-relevant decision and should be made deliberately, not inherited by pulling in a package.
• Sunset / migration decision. Archived, last release 2020-10-19 (1.5.0 added only Laravel 8 support), zero dependents, 578 stars, capped at Laravel 8 — itself past security end-of-life. If it is already in your codebase, scope a migration to Laravel's native encrypted cast or a managed secret store rather than building a roadmap around an upgrade path.

Net read: an opportunity score of ~5.8 against a composite of ~2.5 is the classic signature of a good idea shipped once and abandoned. The need is real; this implementation is not the vehicle.

When to Consider This Package

Consider it when:

• You are on a legacy Laravel 6–8 app and need a fast, internal-only way to make a handful of secrets editable without deploys.
• The secrets are low blast radius — read-only third-party tokens, sandbox keys, internal tooling credentials — where an hour of downtime is an inconvenience, not an incident.
• You accept that "adoption" means vendoring or forking, pinning the version, and naming an owner, because upstream will not track Laravel 9/10/11 changes to encryption, casting, or service providers.
• You want a concrete artefact to hand engineering as the spec for a first-party settings/credentials module.
• You run a single-region, single-database deployment with no near-term requirement for audit logs, key rotation, or least-privilege access.

Look elsewhere when:

• The secrets are production-critical or customer-facing (payment keys, signing keys, PII-adjacent credentials). Losing APP_KEY means permanent, unrecoverable loss of every stored credential — there is no re-encryption command — and APP_KEY compromise means total exposure.
• You need rotation, versioning, audit trails, or break-glass procedures; none exist out of the box, and the custom-model hook is your only path to an audit column.
• You are on Laravel 9+ and expect maintained compatibility — you become the maintainer, and security review will rightly balk at an archived dependency holding secrets.
• Better-fit options exist: Laravel's native encrypted cast on a first-party model, config fed by a proper injection pipeline (Vault, AWS/GCP Secrets Manager, Doppler, 1Password CLI), or a managed product if rotation and audit are table stakes.
• The real need is configuration management rather than secret management — this would add encryption ceremony without solving the actual problem.

Gotchas to carry into the decision: guard all bootstrap-time reads (migrations, seeders, early service providers) behind Schema::hasTable('credentials') or a console check, or fresh installs break; and clear the package cache after every credentials:set, because a terminal write may not be visible to running PHP-FPM workers. Every uncached lookup is a DB query, so resolve once per request or job — never inside a loop, and never in a queued job's constructor, where the value may have rotated and the secret gets serialized into the payload. Missing keys return null silently and keys are case-sensitive, so wrap lookups in an explicit exception. And verify the admin UI's middleware actually requires auth before exposing it — an unauthenticated credentials CRUD screen is a total compromise.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small open-source Laravel package that stores API keys encrypted in our existing database and lets authorized staff edit them without a deployment — rotating a credential becomes a two-minute admin task instead of an engineering ticket. It is a genuinely useful design pattern, but the project has been unmaintained since October 2020, supports only Laravel 8, and has no dependents. My recommendation is to treat it as a reference design, not a dependency: budget one to two engineering days to build the equivalent in-house on Laravel's native encryption, and separately decide whether production secrets belong in our application database at all.

To engineering (summary): The pattern is worth copying; the code is not worth taking. A thin model with an encrypted cast, a migration, a credentials() helper, and a small guarded admin UI is a day or two of work — and then we own Laravel 9+ compatibility, APP_KEY rotation policy, cache invalidation on write, and an audit trail. If we do build it: namespace keys by environment and tenant, hydrate config at boot behind a console/test guard so the app's call sites stay on config(), resolve credentials inside handle() for queued jobs, and add rotated_at / updated_by before the table is populated rather than after. If someone wants to trial the original in a legacy internal app for low-value sandbox keys only, fine — pin it, vendor it, name an owner, and put a migration ticket next to it on day one.