feature-flags: a Laravel package that puts flags into routes, schedules and queries

A flag is a switch around a block of code, and the package is the switchboard

A feature flag is at times referred to as a feature toggle or feature switch. Ultimately it is a coding strategy to be used along with source control to make it easier to continuously integrate and deploy. The idea of the flags works by essentially safeguarding sections of code from executing if a feature flag isn't in a switched on state.

That is the whole concept, and it is worth being precise about it because the package is often described in terms of the features rather than the mechanism. A flag is on or off. Code guarded by an off flag does not run.

The basic call in the package is one line:

Features::accessible('my-feature') // returns true or false

The package aims to make implementing such flags across your application a great deal easier by providing solutions that work with not only your code but your routes, blade files, task scheduling and validations.

That list is the substance of the project. A feature flag used only inside a controller is a partial solution, because the route still exists, the scheduled job still runs, the Blade template still renders, and the validation still applies. The feature is nominally off but its side effects are not. This package's approach is to put the flag in front of each of those entry points.

The package is published on Packagist as ylsideas/feature-flags, MIT licensed, with the documentation at feature-flags.docs.ylsideas.co. The author is Peter Fox, and the topic tags name Laravel 11, 12 and 13 and PHP 8, and the dark launch vocabulary appears in the tags, which tells you the intended use case is releasing a feature to a subset of users before the general rollout.

The Laravel integration is the feature, not the accessor

The README names one unique feature of the package, and it is not the accessor method. It is the integration into Laravel by allowing you to configure different things such as access to route, schedule tasks or modifying the query builder.

Each of those three is a distinct mechanism with a distinct failure mode it prevents.

Route access is the one most people mean by a feature flag. A route behind a disabled flag should not be reachable, and it should not appear in a route list either, since a route you can list but not reach is a route that will fail in a test rather than in production.

Schedule tasks matter for a different reason. If a scheduled job keeps running while the feature it maintains is off, the job may write records, send notifications or update state that the disabled feature is supposed to own. A scheduler that honours flags prevents the background side of a feature from running ahead of the front end.

The query builder is the most interesting of the three, because it is not about a single request. Modifying the query builder means the flag can be pushed down into the data access layer, so a query can return only the rows that belong to the enabled feature rather than filtering in PHP after the query has already returned everything. For a large table, the difference between the two is the difference between a cheap request and a slow one.

Blade files are in the same family. A view can be gated so that a partial is not rendered at all, rather than rendered empty, which matters when the partial itself queries for data.

And validations, which is the one people forget. If a form field belongs to a feature, the validation rule should not apply when the feature is off, otherwise a payload from a client that has the old form fails validation on a field the user never saw.

Installing, publishing the config, and the version story

Installation is a Composer require:

composer require ylsideas/feature-flags:^3.0

Once installed you should publish the config with the following command:

php artisan vendor:publish --provider="YlsIdeas\FeatureFlags\FeatureFlagsServiceProvider" --tag=config

And then you can customise the features.php config in a number of ways. That last sentence is doing more work than it looks. The entire behaviour of the package is in a published config file, which means the flags themselves are configuration rather than code, and a deployment can change which features are on without a code change.

The upgrade guidance is unusually clear, which matters for a package with a two year history of major versions. Version 3 and 2 are mostly the same, with some additional type hinting added, and no major upgrade work should be required. Version 2 is somewhat different from version 1: if you are using Laravel 9 and PHP 8 you should aim to use version 2, and version 1 is no longer supported. There is an upgrade guide for moving from version 1 to version 2 in UPGRADE.md.

The version table in the release history matches that guidance. Version 3.0.1 was published on 2025-03-01, 3.0.2 on 2025-05-11 and 3.1.0 on 2026-05-11, and the last push to the repository was on 2026-05-12. The 3.1.0 release is a minor bump on top of a stable major line, which tells you the package is in maintenance mode rather than churning.

The documentation site is the recommended way to understand the package, and the README says to read it rather than trying to infer the config options from the source.

The paid dashboard that sits on top of the free package

The README carries a section on the feature flagging dashboard for Laravel, and it is worth separating from the package itself because the two have different licences and different maturity.

In late 2022 the author decided to start work on a dashboard that works on top of the feature flags for Laravel package. The project is called flagfox, and at the time of writing there is a waiting list to join rather than an open product, with a link to flagfox.dev for that purpose.

The division of labour is the sensible one. The package is the mechanism, the dashboard is the control surface. A dashboard implies flags that can be turned on and off by someone who is not a developer, which is a different requirement from the package's own premise, and it is a different project with its own lifecycle. The README presents it as a project that will work on top of the package rather than as a replacement for it, so the package remains usable on its own, which is what the free tier of the rest of this repository depends on.

The name plays on the author's other work, since the sponsor badge points at peterfox on GitHub Sponsors, and the feature-flags package itself is by Peter Fox.

For a team evaluating this, the practical point is that adopting the package does not commit you to the dashboard, and the dashboard is not yet something you can install today. If your process requires a non-technical approver to switch a feature on, the waiting list is the current state of that option.

The development workflow, and the security reporting route

The package development section covers three commands, and they tell you what the maintainer expects of a contributor.

To run the tests:

composer test

To make sure the code is linted as well:

composer lint

And to check the code does not introduce errors with PHPStan:

composer analyse

The repository layout backs that up. There is a phpstan.neon.dist alongside a phpstan-baseline.neon, which is the standard way to run static analysis on an existing codebase, the baseline holding the known findings so that new code is held to the current standard. There is a pint.json, which is Laravel Pint's configuration for code style, and a rector.php, which is the configuration for Rector, the automated refactoring tool. The presence of both means the project automates its own modernisation, which is why the 3.x line can be a small diff from the 2.x line.

There are also stubs/ and migrations/ directories. The migrations directory tells you the package ships database migrations, which is the natural consequence of flags being persisted rather than being hardcoded constants, and the stubs directory is for the publishable templates, which is where the features.php file lives before you publish it.

On security, the guidance is to email [email protected] instead of using the issue tracker. For a package that gates access to routes, that is the right convention, since a report about route access should not sit in a public thread.

Contributions are asked to follow the Pull Request template, and the README is blunt that ignoring it will mean the PR will be ignored. The changelog is in CHANGELOG.md and the contributing details in CONTRIBUTING.md.

Editorial conclusion

feature-flags suits a Laravel team that wants to gate a feature across the whole stack rather than only in a service class, because the package covers routes, scheduling, views, validation and queries, which is where half-deployed features usually leak. It does not suit you if you want percentage rollouts or per-user targeting, because the documentation describes flags as on or off states with no mention of cohort logic. Before you adopt it, publish and read the features.php config, since the whole behaviour is configured there, and check the version floor, because version 1 is no longer supported and version 3 is what you want for Laravel 11 and later.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. ylsideas/feature-flags on GitHub