Volet Laravel Package

Product Decisions This Supports

• Feature delivery without redeploys. A Laravel-native feature flag package (Volet) lets PM decide when a capability reaches users, decoupled from the engineering release train — the core lever for staged rollouts, beta cohorts, and kill switches.
• Release risk management. Flags give you a rollback path that doesn't require a revert-and-hotfix cycle. This directly informs how aggressively you can commit to launch dates in a roadmap.
• Build vs. buy for flag infrastructure. The realistic alternative is LaunchDarkly/Flagsmith (paid SaaS, per-seat/MAU pricing, external dependency, data residency questions) or an in-house flags table (cheap to start, expensive to make safe — targeting rules, audit trail, caching, admin UI all get rebuilt badly). This package is the "buy the cheap version" option: open source, self-hosted, no vendor contract.
• Roadmap sequencing for experimentation. Self-hosted flags unlock A/B and progressive delivery without procurement. That changes whether an experimentation practice is a Q1 initiative or a Q4 one.
• Scope decisions on admin/tooling. Evaluate whether the package's built-in management surface covers what your internal users (PM, support, ops) need, or whether you're signing up to build a UI on top of it — a real, often-underestimated line item.

Assessment of this release (v2.2.3): maintenance-only. Twenty-four of twenty-five changes are Dependabot dependency bumps; the single functional change fixes a jQuery/terser bundling conflict in the package's front-end assets. There are no new features, no API changes, no deprecations, and no breaking changes. Nothing here alters the product-level evaluation above. Two signals are worth logging for planning purposes:

• laravel/framework moved from 13.11.2 → 13.16.1, indicating the package tracks current Laravel majors. Good for your framework upgrade path; confirm the package's composer.json constraint matches your app's floor before committing.
• The asset bundling fix implies the package ships its own compiled front-end. If you plan to embed its management UI, the terser/jQuery class of bug is the kind of thing that lands in your defect queue, not the maintainer's, once you customise the build. Budget a small amount of front-end ownership.

When to Consider This Package

Adopt when most of these hold:

• Your stack is Laravel and you want flags resolved in-process (no network hop per evaluation) rather than via an external SDK.
• You need the basics done properly: boolean flags, targeting rules, percentage rollouts, scheduling, and a persisted audit trail.
• Self-hosting is acceptable or preferred — no procurement, no vendor security review, no MAU-based cost curve as you grow.
• You have engineering capacity to own a small dependency and, if you customise the UI, its asset pipeline.
• Flag volume and team size are modest — tens of flags, a handful of PMs/engineers flipping them.

Look elsewhere when:

• You need statistically rigorous experimentation (sequential testing, CUPED, sample-size calculators, guardrail metrics) — this is a flag tool, not an experimentation platform. Pair with a warehouse-based analysis layer or buy a dedicated product.
• You require enterprise governance out of the box: SSO/SCIM, granular RBAC, SOC 2 evidence, approval workflows on flag changes.
• You're not on Laravel, or you're polyglot and need one flag system across services — a vendor with multi-SDK support wins on consistency.
• You need edge/CDN-level flag evaluation or sub-10ms decisions at very high request volume without app-level caching work.

Decision on this release: no action. Treat v2.2.3 as a routine patch; schedule it in your normal dependency cadence. Note that a patch that only bumps dependencies still deserves a smoke test of the flag admin UI if you've customised it.

How to Pitch It (Stakeholders)

For executives (one paragraph): We're evaluating Volet, an open-source feature flag package for our Laravel stack. It lets us ship code dark and turn features on for specific customers, cohorts, or percentages of traffic — which means faster launches with a built-in off switch, and fewer late-night rollbacks. It's self-hosted with no licence fee, so the cost is engineering time rather than a recurring contract; the trade-off versus a commercial vendor is that we own the operational and compliance surface ourselves. The v2.2.3 release we just reviewed is purely maintenance — dependency updates and one bundling fix — with no functional or breaking changes, so it doesn't move the evaluation.

For engineering (short): Laravel-native flags, in-process evaluation, self-hosted, actively maintained (this release shows a working Dependabot + CI pipeline and current Laravel 13 / Pest 4 tracking). Cost is ownership: we maintain the dependency, the database table, and any custom admin UI. One caveat surfaced by this release — the package ships compiled front-end assets and recently needed a terser/jQuery bundling fix, so if we fork or extend the UI, we inherit that build.

Recommendation: proceed to a time-boxed spike (one engineer, ~1 week) to validate the flag model against our top three use cases — staged rollout, customer-specific entitlements, and kill switch — before committing it to a roadmap dependency. Re-assess on the next minor release (2.3.x) or any change to the public API, whichever comes first.