Start Free
Independent guide ยท Updated 2026-07-25

The LaunchDarkly CLI

ldcli is LaunchDarkly’s official command line interface. It wraps the REST API, so anything it does you could do with curl, and it adds two things curl cannot: a guided setup flow and a local dev server that serves flag values to your app while you work offline.

Worth knowing who wrote this: we're ShipSilently, a feature flag service that competes with LaunchDarkly. We've kept this page to things you can verify, with sources at the bottom, because a page that shades the facts is worth less to us than one you'd send to a colleague. Found something wrong or out of date? Tell us and we'll correct it.

Not affiliated with or endorsed by LaunchDarkly. LaunchDarkly is a trademark of its owner, used here to refer to their product. For official documentation see launchdarkly.com/docs.

Installing

Four routes, pick whichever fits how you manage tools:

# macOS, Homebrew
brew tap launchdarkly/homebrew-tap
brew install ldcli

# npm, anywhere Node runs
npm install -g @launchdarkly/ldcli

# Docker, handy for CI
docker pull launchdarkly/ldcli

Windows and Linux executables are published on the releases page if you'd rather drop a binary somewhere than take a package manager dependency.

Authenticating

The CLI needs an access token with write-level access. Two ways to give it one: 

# Option 1: environment variable (good for CI)
export LD_ACCESS_TOKEN=api-00000000-0000-0000-0000-000000000000

# Option 2: persist it in your config file
ldcli config --set access-token api-00000000-0000-0000-0000-000000000000

Option 2 writes to $XDG_CONFIG_HOME/ldcli/config.yml. Two things follow from that which are easy to miss: the token sits in plaintext on your disk, and it will not be in the environment of a container or a CI runner, so pipelines want option 1 sourced from a secret store.

Use a service token for anything automated. Personal access tokens carry your permissions and stop working when your account does. That's fine for a laptop and a genuine problem for a deploy pipeline. The API page covers the difference.

The commands

Most of the surface is generated from the REST API, so commands follow a predictable ldcli <resource> <action> shape and the resource list tracks whatever the API exposes. Rather than memorise it: 

ldcli --help              # every resource the CLI knows about
ldcli flags --help        # actions available on flags
ldcli flags create --help # arguments for one action

Creating a flag, as an example of the shape:

ldcli flags create \
  --access-token "$LD_ACCESS_TOKEN" \
  --project default \
  --data '{"name": "My Test Flag", "key": "my-test-flag"}'

Note the --data argument taking raw API JSON. The CLI is a transport more than an abstraction, which is good news when you're porting something from curl and less good when you were hoping for friendlier ergonomics.

Three commands sit outside that pattern:

  • ldcli setup walks you through creating a first flag, installing an SDK and toggling it. Aimed at first-day onboarding.
  • ldcli config manages your stored settings, including the access token above.
  • ldcli dev-server is the interesting one. Next section.

The dev server

dev-server runs a local server that pulls flag values from a real source environment and then serves them to your application. You point your SDK at localhost, and from there you can override any value without touching a shared environment.

This solves a problem every flag user eventually hits: testing the off-state of a flag that is on in staging, without turning it off for the six other people using staging. The old workaround was a personal environment per developer, which works and quietly multiplies your environment count.

There's a billing angle too. Local development pointed at a local server isn't holding a service connection to LaunchDarkly, and service connections are one of the two things they meter. On a team of any size that's a real line item, not a rounding error.

Where a CLI actually earns its place

Worth being clear-eyed about which of these are genuinely better at a terminal, because "we have a CLI" is not by itself a reason to use one.

Bulk operations are the strong case. Renaming forty flags, auditing which ones haven't been evaluated in six months, creating the same flag across twelve projects: all miserable in a web UI and a short loop in a shell. Local development is the other one, thanks to the dev server.

Deploy pipelines are more debatable. A CLI in CI is a subprocess, an exit code and a parsing problem, where an HTTP call from the language you're already in gives you structured errors. Plenty of teams reach for ldcli in a pipeline step and would be better served by five lines against the REST API.

And single toggles are just faster in the dashboard, which is fine. Not every job needs a terminal.

FAQ

How do I install the LaunchDarkly CLI?

Homebrew on macOS: brew tap launchdarkly/homebrew-tap then brew install ldcli. With npm: npm install -g @launchdarkly/ldcli. There is also a Docker image (docker pull launchdarkly/ldcli), and prebuilt Windows and Linux executables on the GitHub releases page.

How do I authenticate ldcli?

Either set the LD_ACCESS_TOKEN environment variable, or store it with ldcli config --set access-token <token>, which writes to $XDG_CONFIG_HOME/ldcli/config.yml. The token needs write-level access. For anything running in CI, use a service token rather than a personal one so it does not break when the person who made it leaves.

What can the LaunchDarkly CLI do?

Its resource commands mirror the REST API, so you get CRUD on flags, projects, environments, segments and the rest, in the form ldcli <resource> <action>. On top of that there is setup (a guided first-flag walkthrough), config (manage your settings) and dev-server (run flags locally). Run ldcli --help for the full resource list, or ldcli <resource> --help for one of them.

What is the ldcli dev server?

A local server that pulls flag values from a real LaunchDarkly source environment and then serves them to your application while you develop. You point your SDK at localhost instead of LaunchDarkly, which means you can override values freely and keep working without touching a shared environment or burning a service connection.

Can I use ldcli in CI?

Yes, and the Docker image exists partly for this. Authenticate with a service token from your secret store rather than a personal access token. Bear in mind CLI calls draw on the same account-wide API rate limits as everything else, so a matrix build that fans out flag updates across many jobs can rate-limit itself.

Does ShipSilently have a CLI?

Not today. We ship a REST API with a downloadable OpenAPI 3.0 spec, which is enough to generate a client or script against directly, but there is no first-party command line tool and we would rather say so than imply parity. If a CLI is what stands between you and switching, email hello@shipsilently.com, that feedback genuinely moves our roadmap.

More on LaunchDarkly

We don't have a CLI. Here's what we do have.

ShipSilently is flat $49/month with a REST API and a downloadable OpenAPI 3.0 spec you can generate a client from. No command line tool yet. If that is the deciding factor for you, tell us, we build against what people actually ask for, and it is a short list.

$49/month is the 2026 price. List goes to $89/month on January 1, 2027, and subscriptions started before December 31, 2026 stay at $49.

Try ShipSilently Free Talk to a Human

Sources

Checked against the linked sources on 2026-07-25. LaunchDarkly changes its docs and pricing without notice, so treat their pages as authoritative over ours and email us when we drift.