NewYour coding agent can read the release notes before it upgrades.Set up the MCP server →
Packagist · #1175 most downloaded on Packagist
Official LaunchDarkly SDK for PHP
Last release 27 days ago
11 Sep 2026
Release timing varies
gaps range from 2 weeks to 6 months
Nearly every release is documented
notes for 55 of the last 60 stable releases
Nothing withdrawn
no release was ever pulled
12 years old
87 releases · first in 2014
Add payload_temp_dir option to send large event payloads via a file
Check the deleted marker before decoding items from a persistent store
One column per quarter.
Redact anonymous context attributes in migration op and custom events
Cast X-LaunchDarkly-Event-Schema header to string
expose environmentId on EvaluationSeriesContext
Allow providing PSR-6 cache for feature requesters ( #235 ) ( 2328808 ), closes #234
Handle all exceptions within Guzzle feature requester ( #226 ) ( 361f1fe ), closes #225
Honor timeout configuration for CurlEventPublisher
php 8.4 deprecation for implicitly nullable parameters
Inline context for migration events
### Features * Add support for big segments
Add support for client-side prerequisite events
Add wrapper_name and wrapper_version configuration options
Replace deprecated utf8_encode usage (#201) (2c05c8d), closes #199
[!WARNING] If you are using the Relay Proxy, please make sure to update to v8.4.0 before updating to this version of the SDK. Failure to do so will affect the events sent to LaunchDarkly and any support data export integrations.
Remove noisy log message about missing guzzle cache middleware
build: Leverage .gitattributes to reduce package size
Previously deprecated test data flag builder methods variationForAllUsers, valueForAllUsers, and clearUserTargets have been removed.
The latest version of this SDK supports the ability to manage migrations or modernizations, using migration flags. You might use this functionality if you are optimizing queries, upgrading to new tech stacks, migrating from one database to another, or other similar technology changes. Migration flags are part of LaunchDarkly's Early Access Program. This feature is available to all LaunchDarkly customers but may undergo additional changes before it is finalized.
For detailed information about this version, refer to the list below. For information on how to upgrade from the previous version, read the migration guide.
Migrator type which provides an out-of-the-box configurable migration framework.migrationVariation and trackMigrationOperation methods on LDClient.LDContext or an LDUser now only accept an LDContext.variationForAllUsers, valueForAllUsers, and clearUserTargets have been removed.Nothing published for this version
LDUser is now deprecated in favor of LDContext.
LDUser is now deprecated in favor of LDContext.Invalid context log message now includes the flag key as part of the Psr\Log context. (Thanks, mrtus!)
Introduced support for an application_info config property which sets application metadata that may be used in LaunchDarkly analytics or other product
application_info config property which sets application metadata that may be used in LaunchDarkly analytics or other product features. This does not affect feature flag evaluations.Removed all types, fields, and methods that were deprecated as of the most recent 4.x release.
The latest version of this SDK supports LaunchDarkly's new custom contexts feature. Contexts are an evolution of a previously-existing concept, "users." Contexts let you create targeting rules for feature flags based on a variety of different information, including attributes pertaining to users, organizations, devices, and more. You can even combine contexts to create "multi-contexts."
For detailed information about this version, please refer to the list below. For information on how to upgrade from the previous version, please read the migration guide.
LDContext defines the new "context" model. "Contexts" are a replacement for the earlier concept of "users"; they can be populated with attributes in more or less the same way as before, but they also support new behaviors. To learn more, read the documentation.LDUser parameter, the parameter type can now be either LDUser or LDContext. The SDK still supports LDUser for now, but LDContext is the preferred model and LDUser may be removed in a future version.secondary meta-attribute that affects percentage rollouts. If you set an attribute with that name in LDContext, it will simply be a custom attribute like any other.EventPublisher and FeatureRequester which applications are unlikely to reference directly (except when defining a custom component implementation) have been moved out of the main namespace into a new namespace, LaunchDarkly\Subsystems.secondary meta-attribute in LDUser and LDUserBuilder.alias method no longer exists because alias events are not needed in the new context model.inline_users_in_events option no longer exists because it is not relevant in the new context model.Introduced support for an application_info config property which sets application metadata that may be used in LaunchDarkly analytics or other product
application_info config property which sets application metadata that may be used in LaunchDarkly analytics or other product features. This does not affect feature flag evaluations.CI builds now include a cross-platform test suite implemented in https://github.com/launchdarkly/sdk-test-harness. This is in addition to unit test co
base_uri or events_uri with a non-empty path, such as http://my-reverse-proxy-host/launchdarkly-requests, did not work.allFlagsState(), when converted to JSON, had an incorrect format in the case where no flags exist.Expanded upper version restriction on Monolog.
The TestData class was incorrectly generating an error when updating a changed flag. (Thanks, aretenz!)
Expanded lower version restriction on Guzzle.
Add support for psr/log v2 and v3.
The curl command used for publishing events will now honor the connect_timeout parameter.
…as reducing potential compatibility problems and vulnerabilities.
This major version release is for updating PHP compatibility, simplifying the SDK's dependencies, and removing deprecated names.
Except for the dependency changes described below which may require minor changes in your build, usage of the SDK has not changed in this release. For more details about changes that may be necessary, see the 3.x to 4.0 migration guide.
Dropping support for obsolete PHP versions makes it easier to maintain the SDK and keep its dependencies up to date. See LaunchDarkly's End of Life Policy regarding platform version support.
Simplifying dependencies by moving optional integration features into separate packages reduces the size of the SDK bundle, as well as reducing potential compatibility problems and vulnerabilities.
TypeError at runtime if you have been passing values of the wrong types to SDK methods (including passing a null value for a parameter that should not be null)-- although in most cases, this would have caused an error anyway at some point in the SDK code, just not such a clearly identifiable error. To detect type mistakes before runtime, you can use a static analysis tool such as Psalm.LaunchDarkly namespace that were annotated as @internal and not documented, such as types that are part of the internal feature data model. These are not meant for use by application code, and are always subject to change. They have been moved into LaunchDarklyImpl.The phpredis integration was ignoring the phpredis_client option for passing in a preconfigured Redis client. (Thanks, CameronHall!)
phpredis integration was ignoring the phpredis_client option for passing in a preconfigured Redis client. (Thanks, CameronHall!)The SDK now supports the ability to control the proportion of traffic allocation to an experiment. This works in conjunction with a new platform featu
Added the alias method to LDClient. This can be used to associate two user objects for analytics purposes with an alias event.
alias method to LDClient. This can be used to associate two user objects for analytics purposes with an alias event.When using Files.featureRequester, if a data file did not contain valid JSON, the SDK would throw a PHP syntax error instead of the expected "File is
Files.featureRequester, if a data file did not contain valid JSON, the SDK would throw a PHP syntax error instead of the expected "File is not valid JSON" error. (Thanks, GuiEloiSantos!)PHPRedis::featureRequester was not recognizing the phpredis_client option. (Thanks, riekelt!)
PHPRedis::featureRequester was not recognizing the phpredis_client option. (Thanks, riekelt!)Fixed a warning message which erroneously referred to the wrong method.
When using the DynamoDB data store integration with a prefix string, the prefix was being prepended to keys with a slash separator (example: my-prefix
my-prefix/features:my-flag-key). This was inconsistent with the colon separator that is used in the other server-side SDKs (example: my-prefix:features:my-flag-key), making the PHP SDK unable to read flags that were put into the database by other SDKs or by the Relay Proxy, if a prefix was used. This has been fixed to be consistent with the other SDKs. (#138)A use statement with the wrong namespace was causing Composer to print a deprecation warning. (Thanks, bfenton-smugmug!)
send_events had been set to false. This bug was introduced in the 3.6.0 release.use statement with the wrong namespace was causing Composer to print a deprecation warning. (Thanks, bfenton-smugmug!)Loosened the Monolog dependency constraint so that it will accept either a 1.x or a 2.x version. This should be compatible with all currently supporte
Added integration with the `phpredis` extension, which has similar functionality to the already-supported predis but may have better performance (sinc
Added support for upcoming LaunchDarkly experimentation features. See LDClient.track.
LDClient.track.The SDK could throw an exception when calling allFlagsState() if APC/APCu caching was enabled. This bug was introduced in the 3.5.0 release. (Thanks,
allFlagsState() if APC/APCu caching was enabled. This bug was introduced in the 3.5.0 release. (Thanks, omnicolor!)Changed the package name from launchdarkly/launchdarkly-php to launchdarkly/server-sdk
launchdarkly/launchdarkly-php to launchdarkly/server-sdkThere are no other changes in this release. Substituting launchdarkly/launchdarkly-php version 3.5.3 with launchdarkly/server-sdk version 3.5.4 will not affect functionality.
Segment rollout calculations did not work correctly if the rollout was based on a user attribute other than key; all users would end up in the same bu
key; all users would end up in the same bucket. (Thanks, m6w6!)CONTRIBUTING.md.The LaunchDarkly SDK repositories are being renamed for consistency. This repository is now php-server-sdk rather than php-client.
The package name will also change. In the 3.5.3 release, it is still launchdarkly/launchdarkly-php; in all future releases, it will be launchdarkly/server-sdk. No further updates to the launchdarkly/launchdarkly-php package will be published after this release.
In the 3.5.1 release, the VERSION constant was incorrectly still reporting the version as "3.5.0". The constant is now correct. There are no other cha
VERSION constant was incorrectly still reporting the version as "3.5.0". The constant is now correct. There are no other changes in this release.Setting user attributes to non-string values when a string was expected would cause analytics events not to be processed. The SDK will now convert att
track or identify is called without a user, the SDK now logs a warning, and does not send an analytics event to LaunchDarkly (since it would not be processed without a user).It is now possible to use Consul or DynamoDB as a data store with ld-relay, similar to the existing Redis integration. See LaunchDarkly\Integrations\C
ld-relay, similar to the existing Redis integration. See LaunchDarkly\Integrations\Consul and LaunchDarkly\Integrations\DynamoDb, and the reference guide Persistent data stores.redis_timeout to the desired number of seconds. (Thanks, jjozefowicz!)LaunchDarkly\Integrations\Files.allFlagsState method now accepts a new option, detailsOnlyForTrackedFlags, which reduces the size of the JSON representation of the flag state by omitting some metadata. Specifically, it omits any data that is normally used for generating detailed evaluation events if a flag does not have event tracking or debugging turned on.feature_requester and event_publisher configuration options now work differently: you can still set them to an instance of an implementation object, but you can also set them to a class or a class name (i.e. the same as the feature_requester_class option), or a factory function. Therefore, the _class versions of these options are no longer necessary. However, the old semantics still work, so you can for instance set event_publisher_class to "LaunchDarkly\GuzzleEventPublisher", even though the new preferred way is to set event_publisher to LaunchDarkly\Integrations\Guzzle::featureRequester().allFlagsState is now slightly smaller even if you do not use the new option described above, because it omits the flag property for event tracking unless that property is true.$_anonymous property of the LDUser class was showing up as public rather than protected. (Thanks, dstockto!)Improved the performance of allFlags/allFlagsState by not making redundant individual requests for prerequisite flags, when a flag is being evaluated
allFlags/allFlagsState by not making redundant individual requests for prerequisite flags, when a flag is being evaluated that has prerequisites. Instead it will reuse the same flag data that it already obtained from LaunchDarkly in the "get all the flags" request.The new LDClient method variationDetail allows you to evaluate a feature flag (using the same parameters as you would for variation) and receive more
LDClient method variationDetail allows you to evaluate a feature flag (using the same parameters as you would for variation) and receive more information about how the value was calculated. This information is returned in an object that contains both the result value and a "reason" object which will tell you, for instance, if the user was individually targeted for the flag or was matched by one of the flag's rules, or if the flag returned the default value due to an error.The new LDClient method allFlagsState() should be used instead of allFlags() if you are passing flag data to the front end for use with the JavaScript
LDClient method allFlagsState() should be used instead of allFlags() if you are passing flag data to the front end for use with the JavaScript SDK. It preserves some flag metadata that the front end requires in order to send analytics events correctly. Versions 2.5.0 and above of the JavaScript SDK are able to use this metadata, but the output of allFlagsState() will still work with older versions.allFlagsState() method also allows you to select only client-side-enabled flags to pass to the front end, by using the option clientSideOnly => true.LDClient.allFlags()The LDClient::VERSION constant has been fixed to report the current version. In the previous release, it was still set to 3.1.0.
LDClient::VERSION constant has been fixed to report the current version. In the previous release, it was still set to 3.1.0.The client now treats most HTTP 4xx errors as unrecoverable: that is, after receiving such an error, it will take the client offline (for the lifetime
Analytics events for feature evaluations now have a variation property (the variation index) as well as value. This will allow for better performance
variation property (the variation index) as well as value. This will allow for better performance in future versions of ld-relay when it is used with the PHP client.LDDFeatureRequester.Support for a new LaunchDarkly feature: reusable user segments.
Adds support for a future LaunchDarkly feature, coming soon: semantic version user attributes.
Support for private user attributes.
New flush method forces events to be published to the LaunchDarkly service. This can be useful if LDClient is not automatically destroyed at the end o
flush method forces events to be published to the LaunchDarkly service. This can be useful if LDClient is not automatically destroyed at the end of a request. Thanks @foxted!CacheStorageInterface. Thanks @pmeth!Support for publishing events via ld-relay
EventPublisher to be injected into the client.GuzzleEventPublisher as a synchronous, in-process alternative to publishing events via background processes.curl path used by CurlEventPublisher to be customized via the curl option to LDClient. Thanks @abacaphiliac!Your coding agent can read these notes before it upgrades. Set up the MCP server →