launchdarkly/launchdarkly-php
Official LaunchDarkly SDK for PHP
6.8.2
2.2M downloads/mo
#3926 most downloaded on Packagist
launchdarkly/php-server-sdk
What this package is like to depend on
Last release 1 months ago
21 Jul 2026
Release timing varies
gaps range from 2 weeks to 6 months
Most releases are documented
notes for 68 of 84 stable releases
Nothing withdrawn
no release was ever pulled
12 years old
85 releases · first in 2014
6 releases in the last 12 months
see the full history below
Release timeline
81 releases · Dec 2014 to Jul 2026Releases
latest 60 of 85-
6.8.221 Jul 2026Release notes
Open source →Release notes
Open source → -
6.8.108 Jun 2026Release notes
Open source →Release notes
Open source → -
6.8.028 Apr 2026Release notes
Open source → -
6.7.023 Feb 2026Release notes
Open source → -
6.6.220 Nov 2025 -
6.6.120 Oct 2025Release notes
Open source → -
6.6.016 Apr 2025 -
6.5.225 Mar 2025Release notes
Open source →Release notes
Open source → -
6.5.117 Mar 2025Release notes
Open source → -
6.5.013 Mar 2025Release notes
Open source → -
6.4.017 Jan 2025 -
6.3.022 Oct 2024Release notes
Open source → -
6.2.011 Jun 2024 -
6.1.015 Mar 2024Release notes
Open source →[!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.
Features
- Redact anonymous attributes within feature events (#193) (cdad89a)
- Update to event schema v4 (#192) (475727f)
Bug Fixes
-
6.0.223 Jan 2024Release notes
Open source → -
6.0.101 Dec 2023 -
6.0.023 Oct 2023Release notes
Open source →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.
Added:
- A new
Migratortype which provides an out-of-the-box configurable migration framework. - For more advanced use cases, added new
migrationVariationandtrackMigrationOperationmethods onLDClient.
Removed:
- PHP 8.0 support was removed.
- The legacy user format for contexts is no longer supported. To learn more, read the Contexts documentation.
- Methods which originally took an
LDContextor anLDUsernow only accept anLDContext. - Previously deprecated test data flag builder methods
variationForAllUsers,valueForAllUsers, andclearUserTargetshave been removed.
- A new
-
5.2.123 Jan 2024Nothing published for this version
-
5.2.023 Oct 2023 -
5.1.112 Jul 2023 -
5.1.031 Jan 2023Release notes
Open source →Added:
- Introduced support for an
application_infoconfig property which sets application metadata that may be used in LaunchDarkly analytics or other product features. This does not affect feature flag evaluations.
- Introduced support for an
-
5.0.005 Jan 2023Release notes
Open source →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.
Added:
- The type
LDContextdefines 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. - For all SDK methods that took an
LDUserparameter, the parameter type can now be eitherLDUserorLDContext. The SDK still supportsLDUserfor now, butLDContextis the preferred model andLDUsermay be removed in a future version.
Changed (breaking changes from 4.x):
- It was previously allowable to set a user key to an empty string. In the new context model, the key is not allowed to be empty. Trying to use an empty key will cause evaluations to fail and return the default value.
- There is no longer such a thing as a
secondarymeta-attribute that affects percentage rollouts. If you set an attribute with that name inLDContext, it will simply be a custom attribute like any other. - Component interface types like
EventPublisherandFeatureRequesterwhich 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.
Changed (requirements/dependencies/build):
- The minimum PHP version is now 8.0.
Changed (behavioral changes):
- The SDK is now more strictly compliant with the LaunchDarkly specification for date and semantic version values. This means that some values that might have been accepted in the past, which other SDKs would not accept, are now correctly considered invalid. Please review the LaunchDarkly documentation on Using date/time and semantic version operators.
- Analytics event data now uses a new JSON schema due to differences between the context model and the old user model.
Fixed:
- Fixed a bug in the parsing of string values in feature flags and user attributes when they were referenced with date/time operators in a targeting rule. As described in LaunchDarkly documentation, such values must use the RFC3339 date/time format; the SDK was also accepting strings in other formats (for instance, ones that did not have a time or a time zone), which would cause undefined behavior inconsistent with evaluations done by other LaunchDarkly services. This fix ensures that all targeting rules that reference an invalid date/time value are a non-match, and does not affect how the SDK treats values that are in the correct format.
- The SDK was allowing numeric values to be treated as semantic versions in targeting rules. It now correctly only allows strings, as described in LaunchDarkly documentation.
Removed:
- Removed all types, fields, and methods that were deprecated as of the most recent 4.x release.
- Removed the
secondarymeta-attribute inLDUserandLDUserBuilder. - The
aliasmethod no longer exists because alias events are not needed in the new context model. - The
inline_users_in_eventsoption no longer exists because it is not relevant in the new context model.
- The type
-
4.3.031 Jan 2023Release notes
Open source →Added:
- Introduced support for an
application_infoconfig property which sets application metadata that may be used in LaunchDarkly analytics or other product features. This does not affect feature flag evaluations.
- Introduced support for an
-
4.2.407 Oct 2022Release notes
Open source →Changed:
- 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 coverage, and ensures consistent behavior across SDKs.
Fixed:
- Setting a
base_uriorevents_uriwith a non-empty path, such ashttp://my-reverse-proxy-host/launchdarkly-requests, did not work. - The object returned by
allFlagsState(), when converted to JSON, had an incorrect format in the case where no flags exist.
-
4.2.307 Sep 2022 -
4.2.201 Aug 2022Release notes
Open source →Fixed:
- The TestData class was incorrectly generating an error when updating a changed flag. (Thanks, aretenz!)
-
4.2.105 Jul 2022 -
4.2.013 Apr 2022Release notes
Open source →Added:
- Add support for psr/log v2 and v3.
- The LaunchDarkly\Integrations\TestData is a new way to inject feature flag data programmatically into the SDK for testing—either with fixed values for each flag, or with targets and/or rules that can return different values for different users. Unlike LaunchDarkly\Integrations\Files, this mechanism does not use any external resources, only the data that your test code has provided.
-
4.1.016 Feb 2022Release notes
Open source →Added:
- The curl command used for publishing events will now honor the connect_timeout parameter.
- Publishing events on Windows will now use PowerShell and Invoke-WebRequest instead of curl.
Fixed:
- Numeric strings are no longer treated like numbers in equality checks.
- User attributes with values of 0 or false will no longer be filtered out of event payloads.
- When using allFlagsState to produce bootstrap data for the JavaScript SDK, the PHP SDK was not returning the correct metadata for evaluations that involved an experiment. As a result, the analytics events produced by the JavaScript SDK did not correctly reflect experimentation results.
-
4.0.007 Aug 2021Release notes
Open source →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.
Added:
- Added type declarations to all methods. These could result in a
TypeErrorat runtime if you have been passing values of the wrong types to SDK methods (including passing anullvalue 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.
Changed:
- The minimum PHP version is now 7.3.
- Updated many dependencies to newer versions and/or more actively maintained packages.
Removed:
- Removed the bundled Redis, DynamoDB, and Consul integrations. These are now provided as separate packages; see php-server-sdk-redis-predis, php-server-sdk-redis-phpredis, php-server-sdk-dynamodb, and php-server-sdk-consul.
- Removed all types and methods that were deprecated in the last 3.x version.
- Removed implementation types from the
LaunchDarklynamespace that were annotated as@internaland 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 intoLaunchDarklyImpl.
- Added type declarations to all methods. These could result in a
-
3.9.102 Aug 2021Release notes
Open source →Fixed:
- The
phpredisintegration was ignoring thephpredis_clientoption for passing in a preconfigured Redis client. (Thanks, CameronHall!)
- The
-
3.9.021 Jun 2021Release notes
Open source →Added:
- The SDK now supports the ability to control the proportion of traffic allocation to an experiment. This works in conjunction with a new platform feature now available to early access customers.
-
3.8.019 Apr 2021Release notes
Open source →Added:
- Added the
aliasmethod toLDClient. This can be used to associate two user objects for analytics purposes with an alias event.
- Added the
-
3.7.614 Apr 2021Release notes
Open source →Fixed:
- 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 not valid JSON" error. (Thanks, GuiEloiSantos!)
- When using
-
3.7.501 Mar 2021Release notes
Open source →Fixed:
PHPRedis::featureRequesterwas not recognizing thephpredis_clientoption. (Thanks, riekelt!)
-
3.7.407 Jan 2021Release notes
Open source →Fixed:
- Fixed a warning message which erroneously referred to the wrong method.
-
3.7.328 Oct 2020Release notes
Open source →Fixed:
- 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/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)
- When using the DynamoDB data store integration with a prefix string, the prefix was being prepended to keys with a slash separator (example:
-
3.7.224 Apr 2020Release notes
Open source →Fixed:
- The SDK could try to send analytics events even if
send_eventshad been set to false. This bug was introduced in the 3.6.0 release. - A
usestatement with the wrong namespace was causing Composer to print a deprecation warning. (Thanks, bfenton-smugmug!)
- The SDK could try to send analytics events even if
-
3.7.103 Jan 2020Release notes
Open source →Fixed:
- 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 supported PHP versions; the SDK's use of Monolog does not rely on any features that are specific to 1.x. (Thanks, mrtus!)
- In rare circumstances (depending on the exact data in the flag configuration, the flag's salt value, and the user properties), a percentage rollout could fail and return a default value, logging the error "Data inconsistency in feature flag ... variation/rollout object with no variation or rollout". This would happen if the user's hashed value fell exactly at the end of the last "bucket" (the last variation defined in the rollout). This has been fixed so that the user will get the last variation.
-
3.7.013 Dec 2019 -
3.6.001 Oct 2019Release notes
Open source →Added:
- Added support for upcoming LaunchDarkly experimentation features. See
LDClient.track.
- Added support for upcoming LaunchDarkly experimentation features. See
-
3.5.506 Jun 2019Release notes
Open source →Fixed:
- 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, omnicolor!) - Improved unit test coverage for the caching logic.
- The SDK could throw an exception when calling
-
3.5.410 May 2019Release notes
Open source →Changed:
- Changed the package name from
launchdarkly/launchdarkly-phptolaunchdarkly/server-sdk
There are no other changes in this release. Substituting
launchdarkly/launchdarkly-phpversion 3.5.3 withlaunchdarkly/server-sdkversion 3.5.4 will not affect functionality. - Changed the package name from
-
3.5.326 Apr 2019Release notes
Open source →Fixed:
- 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 bucket. (Thanks, m6w6!) - Running the SDK unit tests is now simpler, as the database integrations can be skipped. See
CONTRIBUTING.md.
Note on future releases
The LaunchDarkly SDK repositories are being renamed for consistency. This repository is now
php-server-sdkrather thanphp-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 belaunchdarkly/server-sdk. No further updates to thelaunchdarkly/launchdarkly-phppackage will be published after this release. - Segment rollout calculations did not work correctly if the rollout was based on a user attribute other than
-
3.5.212 Apr 2019Release notes
Open source →Fixed:
- In the 3.5.1 release, the
VERSIONconstant was incorrectly still reporting the version as "3.5.0". The constant is now correct. There are no other changes in this release.
- In the 3.5.1 release, the
-
3.5.103 Apr 2019Release notes
Open source →Fixed:
- 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 attribute values to strings as needed.
- If
trackoridentifyis 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).
-
3.5.031 Jan 2019Release notes
Open source →Added:
- It is now possible to use Consul or DynamoDB as a data store with
ld-relay, similar to the existing Redis integration. SeeLaunchDarkly\Integrations\ConsulandLaunchDarkly\Integrations\DynamoDb, and the reference guide Persistent data stores. - When using the Redis integration, you can specify a Redis connection timeout different from the default of 5 seconds by setting the option
redis_timeoutto the desired number of seconds. (Thanks, jjozefowicz!) - It is now possible to inject feature flags into the client from local JSON files, replacing the normal LaunchDarkly connection. This would typically be for testing purposes. See
LaunchDarkly\Integrations\Files. - The
allFlagsStatemethod 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.
Changed:
- The
feature_requesterandevent_publisherconfiguration 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 thefeature_requester_classoption), or a factory function. Therefore, the_classversions of these options are no longer necessary. However, the old semantics still work, so you can for instance setevent_publisher_classto"LaunchDarkly\GuzzleEventPublisher", even though the new preferred way is to setevent_publishertoLaunchDarkly\Integrations\Guzzle::featureRequester().
Fixed:
- JSON data from
allFlagsStateis 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. - The
$_anonymousproperty of theLDUserclass was showing up as public rather than protected. (Thanks, dstockto!)
- It is now possible to use Consul or DynamoDB as a data store with
-
3.4.126 Sep 2018Release notes
Open source →Fixed:
- Improved the performance of
allFlags/allFlagsStateby 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.
- Improved the performance of
-
3.4.004 Sep 2018Release notes
Open source →Added:
- The new
LDClientmethodvariationDetailallows you to evaluate a feature flag (using the same parameters as you would forvariation) 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.
Fixed:
- When evaluating a prerequisite feature flag, the analytics event for the evaluation did not include the result value if the prerequisite flag was off.
- The new
-
3.3.027 Aug 2018Release notes
Open source →Added:
- The new
LDClientmethodallFlagsState()should be used instead ofallFlags()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 ofallFlagsState()will still work with older versions. - The
allFlagsState()method also allows you to select only client-side-enabled flags to pass to the front end, by using the optionclientSideOnly => true.
Deprecated:
LDClient.allFlags()
- The new
-
3.2.116 Jul 2018Release notes
Open source →Fixed:
- The
LDClient::VERSIONconstant has been fixed to report the current version. In the previous release, it was still set to 3.1.0.
- The
-
3.2.027 Jun 2018Release notes
Open source →Changed:
- 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 of the client instance, which in most PHP applications is just the current request-response cycle). This is because such errors indicate either a configuration problem (invalid SDK key) or a bug, which is not likely to resolve without a restart or an upgrade. This does not apply if the error is 400, 408, 429, or any 5xx error.
Fixed:
- Made various changes to project settings to improve the IDE experience and the build; enforced PSR-2 coding style. (Thanks, localheinz!)
-
3.1.004 May 2018Release notes
Open source →Added
- Analytics events for feature evaluations now have a
variationproperty (the variation index) as well asvalue. This will allow for better performance in future versions ofld-relaywhen it is used with the PHP client.
Fixed
- Fixed a bug that made segment-based rules always fall through when using
LDDFeatureRequester.
- Analytics events for feature evaluations now have a
-
3.0.021 Feb 2018 -
2.5.013 Feb 2018Release notes
Open source →Added
- Adds support for a future LaunchDarkly feature, coming soon: semantic version user attributes.
-
2.4.012 Jan 2018Release notes
Open source →Added
- Support for private user attributes.
Changed
- Stop retrying HTTP requests if the API key has been invalidated.
- User bucketing supports integer attributes. Thanks @mlund01!
- Source code complies with the PSR-2 standard. Thanks @valerianpereira!
Fixed
- The PSR-4 autoloading specification is now correct. Thanks @jenssegers!
-
2.3.006 Oct 2017Release notes
Open source →Added
- New
flushmethod forces events to be published to the LaunchDarkly service. This can be useful ifLDClientis not automatically destroyed at the end of a request. Thanks @foxted!
Fixed
- Documentation comment references the correct namespace for
CacheStorageInterface. Thanks @pmeth!
- New
-
2.2.006 Jun 2017Release notes
Open source →Added
- Support for publishing events via ld-relay
- Allow
EventPublisherto be injected into the client. GuzzleEventPublisheras a synchronous, in-process alternative to publishing events via background processes.- Allow the
curlpath used byCurlEventPublisherto be customized via thecurloption toLDClient. Thanks @abacaphiliac!
-
2.2.0-beta125 May 2017 pre-releaseNothing published for this version
-
2.1.227 Apr 2017Release notes
Open source →Changed
- Relaxed the requirement on
kevinrob/guzzle-cache-middlewarefor the defaultGuzzleFeatureRequester. - Added package suggestions in
composer.json.
Fixed
- Better handling of possibly null variations. Thanks @idirouhab!
- Relaxed the requirement on