Laravel Feature Flags Laravel Package

Product Decisions This Supports

• Separating "shipped" from "live." The core PM value is that code merged to main no longer implies behavior exposed to customers. Engineering lands the work behind a database row; product chooses the moment of exposure. That turns a launch date into a deliberate business decision rather than a side effect of a merge, and it is the single biggest schedule-risk reduction this package offers.
• Risk-tiered release policy. For anything touching checkout, pricing, auth, permissions, or schema migration, a flag lets you ship dark, enable for internal users, then widen. It makes "do we hold the release another week for monitoring?" a much cheaper question, because exposure is separately reversible from deployment.
• Staged and scheduled rollouts without a vendor. Boolean, global on/off flips are enough for the majority of internal launches and redesigns. The package covers that with Artisan commands for creating, enabling, and disabling flags — no SaaS contract, no procurement cycle, no new sub-processor in the request path.
• Build vs. buy, with a real third option. The comparison is three-way: build it yourself (flag table, admin surface, cache invalidation, authorization — multi-week build plus permanent ownership), buy a SaaS flag platform (contract, privacy review, per-seat pricing, external dependency on the hot path), or adopt this — MIT-licensed, in-process, in your own database. For a Laravel monolith with a modest flag inventory, this is the credible default.
• Parallelizing launch work. Docs, support macros, pricing-page copy, sales enablement, and CS runbooks can be produced while the final build lands, because the feature can sit staged off. This compresses a release cycle without adding headcount — a concrete justification for the adoption cost when you are asked to defend it.
• Cheaper kill decisions. Retiring a feature becomes a toggle rather than a coordinated rollback or a hotfix. Lowering the cost to try and the cost to unwind changes the calculus on speculative bets — that is a product-strategy benefit, not just an ops convenience.
• Scoping honesty on "early access." Sales and CS will ask for access for specific named accounts. This package is a global store: it answers "is this on for everyone right now?" not "is this on for this account?" A PM must decide up front whether a "cohort" means a real segment or merely a scheduled, staged flip — because this package only delivers the latter. Getting that wrong creates a sales commitment you cannot honor with this tool.
• The Laravel 11 gate is now closed. Release 1.4.0 (2024-03-13) added Laravel 11 compatibility. If this was previously ruled out on framework version, that objection no longer applies — which is why the decision is live now rather than later.

When to Consider This Package

Consider it when:

• The stack is a Laravel 10/11 monolith and every flag consumer is PHP — controllers, jobs, Blade, middleware. Resolution happens in-process, which is the cheapest possible architecture and exactly what this package is built for.
• You want flag state in your own database. No vendor contract, no procurement, no data leaving your infrastructure, no per-MAU billing. For regulated or procurement-constrained organizations this can be decisive on its own.
• You need a kill switch more than an experimentation platform. These are different purchases and conflating them is common and expensive. If the job is "turn it off fast," this is the right size of tool.
• The flag inventory is modest and disciplined — tens of flags, boolean semantics, staged or scheduled rollouts. A small surface area is a feature at that scale: easier to reason about, audit, and eventually delete.
• You want a dependency your team can read end-to-end and fork. MIT, small, single maintainer. For something in the request path, auditability is a legitimate selection criterion.
• You are on or moving to Laravel 11, making 1.4.0 the compatibility signal that reopens the option.

Look elsewhere when:

• You need experimentation-grade statistics — significance testing, exposure logging, guardrail metrics, holdouts. Application flags are not an analysis platform; that belongs in a warehouse-side experiment tool.
• Flags must be read outside PHP — mobile clients, edge workers, other services. A database-in-Laravel store cannot serve those consumers.
• You need enterprise governance — per-flag audit history, approval workflows, RBAC on who can flip what, SOC 2 evidence. The package provides storage and lookup, not governance. Audit columns can be added via the bindable model, but that is a build, not a buy.
• You need true per-user or per-segment targeting at scale. Use Laravel Pennant or a dedicated service rather than bending this one.
• Supply-chain review cannot absorb a single-maintainer dependency in the request path. One compatibility release is a positive signal, not evidence of a maintenance trend; 177 stars and zero dependents is a thin adoption base.
• You need operational guarantees this package does not document. Caching behavior under config caching, PHP version requirements, and maintainer responsiveness on the issue tracker should be confirmed by engineering before standardization, not assumed from the release notes.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed, Laravel-native dependency that lets us turn features on and off without redeploying. In practice it converts launch risk into a configuration change and a rollback into a toggle: smaller blast radius during incidents, faster release cadence, and less schedule pressure to hold releases for a monitoring window. It replaces either a build-it-ourselves workstream — flag table, admin UI, cache invalidation, authorization, several weeks of engineering plus permanent maintenance — or an annual SaaS contract with procurement and privacy overhead plus an external dependency in the request path. Laravel 11 support landed in 1.4.0, which aligns with our upgrade roadmap, so the timing is right to standardize. Licensing cost is effectively zero; the real cost is the operational discipline of naming, owning, and retiring flags, which we should own as an explicit process rather than let accrue as debt.

To engineering: Laravel 11 support is in 1.4.0, so this is no longer a blocker for current-LTS services and adoption is a dependency-only change: publish config and migration (in that order), migrate, create flags via Artisan, then branch on the facade, helper, Blade directive, or route middleware. Architecturally it is a lightweight in-process store — no sidecar, no external calls on the hot path, flag rows in our database plus cache. Three asks before we standardize. First, validate evaluation and caching behavior against our traffic profile and our queue-worker/Octane setup, specifically the config-cache interaction — stale flag state after a toggle is the known sharp edge. Second, wire an idempotent seeder (firstOrCreate) into the deploy, because a fresh environment or CI pipeline starts with every flag off and an unknown flag name silently resolves to inactive — meaning a missing seed turns staging into a no-op rather than an error. Third, adopt conventions from day one: a naming scheme, a named owner per flag, an expiry date, and a defined removal phase. Treat flag flips as deploys — authorize them like production changes, and sequence destructive launches as migrate schema, then toggle, then remove the flag.

Recommendation: Adopt for internal and staged releases on Laravel 10/11 services as the default option against both build-it-ourselves and a SaaS flag vendor. Revisit with a formal spike if we later need cross-platform flag consumption, real per-user targeting at scale, or experiment statistics — at which point a dedicated flag service is the correct buy rather than an over-extension of this one.