Laravel Feature Flags Laravel Package

Technical Evaluation

Architecture fit. ryangjchandler/laravel-feature-flags is a lightweight, self-contained Laravel package: a service provider, a publishable migration and Eloquent model for flag storage, a facade/helper for checks, and (typically) a Blade directive and middleware for gating routes and views. It follows the conventions of the Laravel ecosystem rather than introducing a new runtime, sidecar, or external control plane. That makes it a strong fit for a single Laravel application or a modular monolith where flag state can live in the primary database. It is explicitly opinionated: it is best understood as a persistent boolean toggle registry with light activation semantics, not a targeting or experimentation engine. If the product roadmap includes percentage rollouts, attribute-based targeting, A/B assignment, or per-tenant evaluation at the edge, this package is the wrong tool and will be replaced within a year.

Integration feasibility. Integration cost is low and entirely within our control: composer require, publish config and migrations, run migrations, wrap calls in the facade. There are no API keys, no network hops, no vendor onboarding, no data-processing agreement, and no egress. The main integration work is not adoption but discipline: establishing a naming convention, an internal wrapper interface, a caching strategy, and a lifecycle policy for flag removal. Those are process costs we would incur with any flag system.

Technical risk. The dominant risk is provenance, not code. The package shows zero stars, zero dependents, and no adoption signal, which means we would be one of the only consumers. Realistic implications: bus factor of one, no deprecation policy, no security response process, and a real chance the package is archived or left behind on a future Laravel major. Secondary technical risks: an uncached flag check is a database round trip, so naive use in hot paths (middleware, Blade partials, per-item loops) will add query volume; the opinionated schema may not model the segmentation we eventually want, forcing a fork or migration; and the package almost certainly ships no admin UI, so flag changes become engineering work unless we build one.

Key questions to resolve before commitment.

• Does it support per-user, per-tenant, or percentage-based activation, or only global on/off? This single answer determines whether it survives our next two quarters.
• What is the supported Laravel/PHP version matrix, and is the maintainer responsive to issues and PRs?
• Are migrations and config fully publishable, and is the schema stable enough to extend without forking?
• Is there any caching, request-level memoization, or cache-invalidation story, or is that entirely ours to build?
• Is there an audit trail of who flipped which flag and when? Compliance and incident review will ask.
• What is the license, and are we comfortable vendoring or hard-forking if maintenance stops?
• What is our failure-mode policy: if the flags table is unreachable, does the app fail open (feature on) or closed (feature off), and can that be configured per flag?

Integration Approach

Stack fit. Appropriate for a Laravel-first backend with a relational database, especially a monolith or a small number of services that can share a database or accept per-service flag tables. Inappropriate for a polyglot or microservice estate where non-PHP services also need flag evaluation — there is no shared evaluation service here, so each language would need its own integration or a homegrown API. In that world, a dedicated platform (Unleash, Flagsmith, LaunchDarkly) is the cheaper long-run choice. Decision rule: one Laravel app, flags are internal release toggles → adopt; multiple runtimes or product-managed targeting → do not.

Migration path. Do not rip out existing config() constants or env-var checks in one pass. Introduce an internal Flags interface (a thin seam with isEnabled(string $flag, $context = null): bool), bind it to the package in a service provider, and migrate call sites feature by feature. This preserves optionality: swapping the package for a commercial provider later becomes one binding change plus a schema/data migration, not a codebase-wide refactor. Backfill existing env-driven toggles into the flags table with a one-time seeder so behavior is identical on cutover.

Compatibility. Verify three things against our actual app before writing code: the package's composer.json constraints against our PHP and Laravel versions; the migration's column types and indexes against our database driver (MySQL vs. Postgres vs. SQLite for test suites); and whether the package registers global middleware or Blade directives that could collide with existing ones. Confirm migrations are publishable so we own schema changes rather than receiving them unexpectedly on composer update.

Sequencing.

1. One-day spike in a throwaway branch: install, migrate, gate one low-risk route, measure query count on a representative page.
2. Define the Flags interface, naming convention (e.g. domain.feature.intent), and a removal policy (every flag has an owner and an expiry date in the ticket).
3. Add caching (per-request memoization minimum; shared cache with explicit invalidation if flags are read on hot paths).
4. Pilot on a single internal or low-blast-radius feature; run it through one full flip-on/flip-off/remove cycle.
5. Build or buy the small admin surface — even a simple authenticated CRUD screen — before asking product or ops to own flag changes.
6. Pin the exact version in composer.lock; treat upgrades as reviewed changes, not automatic.
7. Re-evaluate at the next major Laravel upgrade: adopt upstream, hard-fork, or replace with a platform.

Operational Impact

Maintenance. The realistic posture is "we own this." With a single maintainer and no dependents, plan for the package to become stagnant. Mitigations: pin the version, keep the internal interface seam, vendor or fork if the maintainer steps away, and budget a small annual cost for a Laravel upgrade cycle. The code surface is small enough that a mid-level Laravel engineer can read the whole package in an afternoon — that is the real insurance policy, and it is good.

Support. Community-only, no SLA, no vendor escalation. We need an internal runbook covering: how to add a flag, how to flip it safely in production, how to confirm propagation, and how to remove one. On-call should know that flag changes are database writes and therefore subject to the same review and rollback discipline as deploys — arguably more so, because they bypass CI.

Scaling. Data volume is trivial: flags are a small table. The scaling concern is read amplification. A default of one query per check is fine at low traffic and quietly expensive at high traffic, especially inside loops or shared Blade partials. Per-request memoization should be non-negotiable; a shared cache with explicit invalidation is the next step. Note the trade-off this creates — caching introduces propagation delay, so a flipped flag may take seconds or minutes to take effect. Decide per flag whether that lag is acceptable; for incident kill-switches it usually is not, and those flags should bypass the cache.

Failure modes to design for explicitly.

• Database unavailable: every flag evaluation fails. Choose fail-open or fail-closed per flag and encode it; a broken flags table should not take down checkout.
• Stale cache: flip appears to do nothing, eroding trust in the system. Expose a cache-clear action in the admin surface and document it.
• All-or-nothing blast radius: without percentage rollout, "on" means 100% of users instantly. That converts flags from a risk-reduction tool into a risk-amplification tool for large changes. Compensate with canary deploys and staged exposure at the infrastructure layer.
• Flag debt: permanent flags become untested branches and unowned config. Enforce owner + expiry at creation time or the registry will rot within two quarters.
• Silent drift across environments: staging and production flag state diverge, causing "works in staging" incidents. Treat flag state as configuration with a documented promotion process.

Ramp-up. Engineering ramp-up is genuinely cheap — a Laravel developer is productive in under an hour, and the package's conventions are familiar. The real ramp-up cost is organizational: product managers, support, and QA cannot safely flip flags without a UI and a permission model, and the package does not provide one. If non-engineers are expected to participate in release control, budget for a small admin screen plus an access policy, and count that as part of the total cost of adoption rather than a follow-up nice-to-have.