Feature Flags in PHP: Toggle Features Without Deployment and Prayers
\n\nImagine: you rolled out a new feature — and everything broke. The site went down, clients are panicking, devops are scratching their heads. Sound familiar? Now imagine you can enable this feature for only 5% of users, check the metrics, and if something goes wrong — just flip a switch and roll it back. Without deployment, without commits, without pain. This isn't magic, this is feature flags in PHP.
\n\nFeature flags (also known as feature toggles) are a technique that allows you to enable and disable application functionality without changing code or redeploying. Sounds like a superpower? That's because it is. In this article, we'll explore how to implement PHP functionality management in real projects: from a simple config to integration with Symfony and Laravel. Let's go!
\n\nWhy Do You Need Feature Flags in PHP Projects?
\n\nLet's say you're building an online store in PHP. The client asks you to add a new payment gateway. You write the code, test it locally, but in production — surprise: the gateway is unstable. Usually this means: an urgent fix, a nightly deployment, a stressed team lead. With feature flags, it's different. You simply turn off the flag, and the old payment gateway keeps working while you calmly fix the bug.
\n\nWhen feature flags are especially useful:
\n- \n
- Canary releases — enable the feature for 1% of users, then 10%, then everyone. \n
- A/B testing — show different functionality to different groups and compare conversion rates. \n
- Disabling broken functionality — bug in production? Turn off the flag without rolling back the entire release. \n
- Gradual rollout — roll out a feature gradually to avoid overloading servers. \n
And most importantly: feature flags in PHP reduce deployment risk. You stop being afraid to commit on Friday evening (well, almost).
\n\nSimplest Implementation: Config File
\n\nLet's start with the basics. The simplest way is to store flags in a configuration file. For example, in a PHP array or JSON format.
\n\n// config/features.php\nreturn [\n 'new_checkout' => false,\n 'dark_mode' => true,\n 'ai_recommendations' => false,\n];\n\n\nUse it in code:
\n\n// src/CheckoutService.php\n$features = require __DIR__ . '/config/features.php';\n\nif ($features['new_checkout']) {\n // New checkout logic\n $this->processWithNewGateway();\n} else {\n // Old logic\n $this->processWithOldGateway();\n}\n\n\nThe downside is obvious: to change a flag, you need to edit the file on the server. This is inconvenient and unsafe. But for small projects, it'll do. The main thing is you understand the principle: feature flags PHP are just conditional statements tied to an external storage.
\n\nAdvanced Level: Storing in a Database
\n\nWhen the project grows, the config file becomes a bottleneck. You want to manage flags through an admin panel. This is where the database comes to the rescue.
\n\nCreate a simple table:
\n\nCREATE TABLE feature_flags (\n id INT AUTO_INCREMENT PRIMARY KEY,\n name VARCHAR(100) UNIQUE NOT NULL,\n enabled TINYINT(1) DEFAULT 0,\n created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP\n);\n\n\nAnd write a simple service to work with flags:
\n\nclass FeatureFlagService\n{\n private PDO $pdo;\n private array $cache = [];\n\n public function __construct(PDO $pdo)\n {\n $this->pdo = $pdo;\n }\n\n public function isEnabled(string $flagName): bool\n {\n if (!isset($this->cache[$flagName])) {\n $stmt = $this->pdo->prepare(\n 'SELECT enabled FROM feature_flags WHERE name = ?'\n );\n $stmt->execute([$flagName]);\n $row = $stmt->fetch(PDO::FETCH_ASSOC);\n $this->cache[$flagName]