Pennant Laravel Package

Product Decisions This Supports

• Decouple deploy from release. Ship code dark, then flip flags per user, team, or globally. This is the core decision Pennant enables: teams can merge to trunk continuously while product controls exposure.
• Progressive rollout and ring deployment. Decisions like "5% of accounts → 25% → everyone," or "internal staff → design partners → GA" become a flag configuration change rather than a release event. Scope support (user scope and a global scope, added in v1.25–1.26) maps cleanly to per-account betas and org-wide kill switches.
• Kill switches on risky surfaces. New billing path, new search backend, new onboarding flow: wrap with a flag, and incident response becomes "turn it off" in seconds instead of a hotfix and redeploy. This is a direct lever on mean-time-to-recovery.
• Beta/early-access programs and entitlement gating. Flags scoped to a user or team let you run paid-tier gating or design-partner access without building a bespoke entitlements service. Pennant supports lazy and eager resolution, a before hook, and nameMap/alias decorating, so a small number of flags can back several product surfaces.
• Trunk-based development policy. Adopting Pennant is often an organizational decision to ban long-lived release branches. It gives engineers a sanctioned, testable pattern (@feature / @featureany Blade directives, EnsureFeaturesAreActive middleware, events on feature updates) instead of ad-hoc if (config(...)) checks that rot.
• Build vs. buy for flag infrastructure. The decision framework is: LaunchDarkly/Unleash/Flagsmith give you a UI, targeting rules, audit trails, and cross-language SDKs — at per-seat or per-MAU cost and with your evaluation traffic leaving your infrastructure. Pennant gives you code-defined flags, database or in-memory drivers, caching, and a purge command at zero license cost, with evaluation staying in-process. For a Laravel-only product with a small-to-mid engineering team, that trade is usually favorable.
• What Pennant explicitly does not decide for you. There is no experimentation statistics engine, no flag-management UI, no approval workflow, and no flag-change audit log. If the roadmap requires PM/marketing self-serve targeting or A/B significance testing, that decision needs either a vendor or a supplementary build — decide this before promising "experimentation" to stakeholders.

When to Consider This Package

Good fit when most of these hold:

• The product is a Laravel application (Pennant tracks Laravel 11/12/13 and PHP 8.4/8.5 compatibility in recent releases) and flags are evaluated server-side only.
• Your team is comfortable with flags defined in code (feature classes, config-as-code, reviewed via PR) rather than a point-and-click console.
• Your scoping model is bounded: individual users, teams/accounts, and global. Pennant's scope abstraction is deliberately simple.
• You have a relational database available for the database driver, or can accept the in-memory/array driver for tests and ephemeral flags. The DB driver has had explicit hardening for high-traffic inserts (v1.8.0) and unique-constraint behavior, but you should still size for write volume on bulk flag assignment.
• A single deployable monolith or a small number of Laravel services need consistent flag decisions.

Look elsewhere (or build) when:

• Multiple non-PHP services (mobile clients, Go/Node services, edge workers) need the same flag state. Pennant is PHP/Laravel-only; there is no cross-language SDK.
• Non-engineers must own flag targeting. No UI, no role-based approvals, no audit trail. Regulated environments or SOC 2 scopes that require change history on release controls will need a vendor or a wrapper.
• You need statistically valid experiment analysis, holdouts, or exposure logging tied to metrics. Pennant tells you if a feature is active; it does not tell you whether it worked.
• You need sub-millisecond edge evaluation at very high request volume with instant global propagation. Caching helps (drivers can opt into cache flushing since v1.15.0), but propagation is still bounded by your cache layer and DB.
• Adoption risk checks fail. Treat the headline signals cautiously: the 599 stars badly understates real usage because this is a first-party Laravel package documented on laravel.com rather than in-repo; the "0 dependents" figure and the future-dated release (2026-08-13) should both be verified against Packagist download counts and the actual tag history before you cite them in a business case. Documentation living off-repo also means your internal onboarding docs carry more weight.

How to Pitch It (Stakeholders)

To executives — the business case in one paragraph: Laravel Pennant is a free, MIT-licensed, first-party Laravel package for feature flags. It lets us separate deploying code from releasing it, which means we can ship smaller changes more often, launch new features to a subset of customers, run paid-tier or design-partner betas without custom entitlement code, and turn off a broken feature in seconds instead of shipping a hotfix. The cost is near zero in license fees and measured in days of engineering, not weeks. The ongoing cost is process: we need a flag lifecycle policy so flags get retired. It is not an experimentation platform or a marketing-controlled console — if we later need those, that's a separate buy decision, and adopting Pennant now doesn't block it.

To engineering — the technical case: First-party, MIT, small and stable API surface. Flags are classes resolved through a manager, with lazy/eager resolution, a before hook for named features, a decorator for name mapping and aliasing, and PHP enum support. Two drivers out of the box (database, array) with a documented path for external drivers, plus opt-in cache flushing. First-class Laravel integration: @feature/@featureany Blade directives, EnsureFeaturesAreActive middleware (including an "all" mode), an artisan purge command with feature-level exclusions, and events on feature updates. It's testable — swap in the array driver for deterministic tests — and it's already tracking Laravel 13 and PHP 8.5, so it won't pin our upgrade path.

Risks to state up front, plainly: Pennant is intentionally not a platform. No UI, no audit log, no experiment analytics, no cross-language SDK. Flag sprawl is the most likely failure mode — we should agree on an owner, a naming convention, and a retirement SLA before the first flag ships. And we should validate the package's real-world adoption (Packagist downloads rather than star count) as part of the adoption checklist.