Laravel Env Keys Checker Laravel Package

Product Decisions This Supports

• Deploy-time configuration safety: reduces the class of production incidents caused by a missing or misspelled environment variable (silent nulls, broken queues, failed payment integrations) — a cheap guardrail against an expensive failure mode.
• CI/CD gate hygiene: adding an env-key parity check to the pipeline is a low-effort, high-signal quality gate that catches drift between .env.example (the documented contract) and the real environment before code ships.
• Onboarding and documentation accuracy: keeps .env.example honest as a living spec, which shortens new-engineer setup time and makes local/staging/prod parity auditable.
• Build vs. buy: this is a "buy" (adopt) decision — the surface area is small, the logic is deterministic, and writing and maintaining this in-house would be a distraction. The real decision is whether to enforce it, not whether to build it.
• Roadmap / upgrade planning: v2.0.0 adds Laravel 13.x compatibility. That makes this the release to align with your framework-upgrade track, and it sets a deadline for teams still on the older majors this major-version bump likely drops.

When to Consider This Package

Adopt when:

• You run a Laravel app with a non-trivial environment surface (multiple environments, CI, containerized deploys, or IaC-managed secrets).
• You have ever had a deploy fail — or worse, partially succeed — because a key was missing from an environment.
• You want a machine-checkable contract for .env.example without pulling in a full config-validation framework.
• You are on, or about to move to, Laravel 13 and want a maintained, framework-tracked dependency.

Look elsewhere or skip when:

• Your stack already enforces env completeness another way (deploy-time schema validation, Vault/SSM parameter checks, container entrypoint assertions). Duplicating the check adds noise without added coverage.
• The project is a small internal app with a single environment and few variables — the maintenance overhead outweighs the risk.
• Confirm the breaking-change scope before adopting. A major bump bundled with a Laravel 13 compatibility PR almost certainly means older Laravel majors are no longer supported. If you are pinned to Laravel 9–11, verify the constraint in composer.json and either stay on 1.x or plan the framework upgrade first.
• You need deep secret-management, rotation, or auditing — this is a key-parity checker, not a secrets platform.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost guardrail that prevents a specific and recurring class of production outage — the missing environment variable. These failures are embarrassing, hard to diagnose quickly, and disproportionately costly relative to their trivial root cause. Adopting it is a one-line dependency and a CI step; the payback is measured in avoided incident time. The v2.0.0 release is a routine maintenance milestone that keeps us current with Laravel 13, so it should be folded into the existing framework-upgrade track rather than treated as a separate initiative.

For engineering: v2.0.0 is a compatibility release, not a feature release — it adds Laravel 13.x support and bumps a CI action, with no new capabilities. Treat it as a major version bump that narrows framework support: check the composer.json constraint before upgrading, and if the application is not yet on Laravel 13, stay on 1.9.1 and schedule the bump alongside the framework upgrade. No new API surface to learn; the integration remains a single artisan command wired into CI and your pre-deploy checklist. Low risk, low effort, with the main value being that the dependency is still actively tracked against current Laravel releases rather than abandoned.