The LaunchDarkly CLI helps you manage your feature flags from your terminal or your IDE.
With the CLI, you can:
- Create and evaluate your first feature flag with a guided
setupcommand. - Onboard your whole team by inviting new members.
- Interact with the LaunchDarkly API using resource- and CRUD-based commands.
The LaunchDarkly CLI is available for macOS, Windows, and Linux.
The CLI is available on macOS via Homebrew:
brew tap launchdarkly/homebrew-tap
brew install ldcliA Windows executable of ldcli is available on the releases page.
A Linux executable of ldcli is available on the releases page.
You can also install the LaunchDarkly CLI using npm or Docker.
Install with npm:
npm install -g @launchdarkly/ldcliPull from Docker:
docker pull launchdarkly/ldcliInstalling the CLI provides access to the ldcli command.
ldcli [command]
# Run `--help` for detailed information about CLI commands
ldcli --helpThe LaunchDarkly CLI allows you to save preferred settings, either as environment variables or within a config file. Use the config commands to save your settings.
Supported settings:
access-tokenA LaunchDarkly access token with write-level accessanalytics-opt-outOpt out of analytics tracking (default false)base-uriLaunchDarkly base URI (default "https://app.launchdarkly.com")
environment: Default environment keyflag: Default feature flag keyoutput: Output format: json or plaintext (default: plaintext in a terminal, json otherwise)project: Default project key
Available config commands:
config --set {key} {value}config --unset {key}config --list
To save a setting as an environment variable, prepend the variable name with LD. For example:
export LD_ACCESS_TOKEN=api-00000000-0000-0000-0000-000000000000To save a setting in the configuration file:
ldcli config --set access-token api-00000000-0000-0000-0000-000000000000Running this command creates a configuration file located at $XDG_CONFIG_HOME/ldcli/config.yml with the access token. Subsequent commands read from this file, so you do not need to specify the access token each time.
When you do not pass --output or --json, the default format depends on whether standard output is a terminal: plaintext in an interactive terminal, json when stdout is not a TTY (for example when piped, in CI, or in agent environments).
To force the plaintext default even when stdout is not a TTY, set either FORCE_TTY or LD_FORCE_TTY to any non-empty value (similar to tools that use NO_COLOR). That only affects the default; explicit --output, --json, LD_OUTPUT, and the output setting in your config file still apply.
LD_OUTPUT is the same setting as output in the config file, exposed as an environment variable (see the LD_ prefix above). It is not new with TTY detection; the test suite locks in that it overrides the non-TTY JSON default when set to plaintext.
Effective output is resolved in this order: --json (if set, wins over --output when both are present), then --output, then LD_OUTPUT, then the output value from your config file, then the TTY-based default above.
LaunchDarkly CLI commands:
setupguides you through creating your first flag, connecting an SDK, and evaluating your flag in your Test environmentdev-serverlets you start a local server and retrieve flag values from a LaunchDarkly source environment so you can test your code locally. For assistance starting with or running dev-server, refer to the reference docs.aws-devops-agentprovisions the AWS DevOps Agent integration in your own AWS account
ldcli aws-devops-agent creates the AWS resources the AWS DevOps Agent needs to manage your LaunchDarkly flags: the IAM roles it assumes, an agent space, the association with your AWS account, the operator web app, and the LaunchDarkly MCP server connection.
The commands use your existing AWS session rather than any cross-account LaunchDarkly role, so authenticate first. They fail before creating anything if no credentials are available:
aws sso login --profile my-profile
export AWS_PROFILE=my-profile AWS_REGION=us-east-1
ldcli aws-devops-agent setupThe AWS DevOps Agent is available in us-east-1, us-west-2, ca-central-1, sa-east-1, ap-south-1, ap-southeast-1, ap-southeast-2, ap-northeast-1, eu-central-1, eu-west-1 and eu-west-2, and requires AWS CLI 2.36 or later if you also use the AWS CLI directly. setup warns when the aws binary on your PATH is missing or older than that; the command itself uses the AWS SDK, so it still runs.
setup is safe to re-run: it reuses the IAM roles, the agent space matching --agent-space-name, the account and MCP associations on it, and any LaunchDarkly MCP server already registered on the account. Pass --new-agent-space to create an additional agent space instead. The IAM roles are account-wide and trust the agent spaces in every region, so running setup in a second region leaves the first one working; a role named DevOpsAgentRole-AgentSpace or DevOpsAgentRole-WebappAdmin that setup did not create is reused untouched, and it has to trust aidevops.amazonaws.com itself.
--access-token is optional. The first available token — the flag, then LD_ACCESS_TOKEN, then the one already in your ldcli configuration — is registered with AWS as the bearer token the agent uses to call the LaunchDarkly MCP server, so it should be a service token whose permissions match what you want the agent to do. AWS keeps it until the MCP server is re-registered, so a session token written by ldcli login eventually expires and the agent then fails with unauthorized errors. Re-run with --access-token <token> --replace-mcp-token to re-register an MCP server with a different token; the token is checked against LaunchDarkly first, because AWS stores it write-only and the previous registration cannot be restored. The MCP server already registered on the account is the one serving https://mcp.launchdarkly.com/mcp/launchdarkly, whatever it is named: pass --mcp-endpoint to connect a LaunchDarkly MCP server you host yourself, or --mcp-service-id to point at a specific registration. The agent may call list-projects, list-flags and get-flag without asking, and must ask for approval before calling toggle-flag.
With no token configured at all, setup prints the LaunchDarkly page where you create a service token and connects the MCP server with the token you paste there, so you do not need one ready beforehand. Pressing Enter without a token skips the step, as does running without a terminal.
setup ends by printing the operator app URL, https://<agent-space-id>.aidevops.global.app.aws, which is where you use the agent, together with the AWS console page that manages it.
ldcli aws-devops-agent status shows what exists in the account and region.
Resource commands mirror the LaunchDarkly API and make requests for a given resource. To see a full list of resources supported by the CLI, enter ldcli --help into your terminal.
To see the commands available for a given resource:
ldcli <resource> --helpHere is an example command to create a flag:
ldcli flags create --access-token <access-token> --project default --data '{"name": "My Test Flag", "key": "my-test-flag"}'Additional documentation is available at https://docs.launchdarkly.com/home/getting-started/ldcli.
We encourage pull requests and other contributions from the community. Check out our contributing guidelines for instructions on how to contribute to this project.
If you wish to test your changes locally, simply
- Clone this repo to your local machine;
- Run
make buildfrom the repo root; - Run commands as usual with
./ldcli.
LaunchDarkly uses the SLSA framework (Supply-chain Levels for Software Artifacts) to help developers make their supply chain more secure by ensuring the authenticity and build integrity of our published packages. To learn more, see the provenance guide.
- LaunchDarkly is a continuous delivery platform that provides feature flags as a service and allows developers to iterate quickly and safely. We allow you to easily flag your features and manage them from the LaunchDarkly dashboard. With LaunchDarkly, you can:
- Roll out a new feature to a subset of your users (like a group of users who opt-in to a beta tester group), gathering feedback and bug reports from real-world use cases.
- Gradually roll out a feature to an increasing percentage of users, and track the effect that the feature has on key metrics (for instance, how likely is a user to complete a purchase if they have feature A versus feature B?).
- Turn off a feature that you realize is causing performance problems in production, without needing to re-deploy, or even restart the application with a changed configuration file.
- Grant access to certain features based on user attributes, like payment plan (eg: users on the ‘gold’ plan get access to more features than users in the ‘silver’ plan). Disable parts of your application to facilitate maintenance, without taking everything offline.
- LaunchDarkly provides feature flag SDKs for a wide variety of languages and technologies. Read our documentation for a complete list.
- Explore LaunchDarkly
- launchdarkly.com for more information
- docs.launchdarkly.com for our documentation and SDK reference guides
- apidocs.launchdarkly.com for our API documentation
- blog.launchdarkly.com for the latest product updates