CLI

LyftData includes a native CLI for running components, administering the control plane, and collecting diagnostics in headless or restricted environments.

The examples below follow the current source command shape. Run the installed binary’s recursive help before scripting them; planning-only command hierarchies are not part of this reference.

Connect to a server

The CLI targets an HTTPS server by default. Pass a URL explicitly:

lyftdata --url https://server-host:3000/ server health --json

Or set it once per shell:

Linux/macOS: export LYFTDATA_URL=https://server-host:3000/
Windows PowerShell: $env:LYFTDATA_URL = "https://server-host:3000/"

Then authenticate:

lyftdata login admin

For non-interactive password delivery, use stdin or a protected file:

lyftdata login automation-user --password-stdin
lyftdata login automation-user --password-file /run/secrets/lyftdata-password

Do not place a password directly in process arguments. Install a trusted server certificate for production automation; see Networking and TLS.

Use profiles

--profile <name> selects a saved CLI profile. Profiles keep authentication and server selection separate when one workstation manages several installations:

lyftdata --profile production workers list --json
lyftdata --profile staging deployments list --json

Keep profile caches and their operating-system account private. A profile is not a substitute for least-privilege server roles.

Common commands

Always discover the installed surface from recursive help:

lyftdata --help
lyftdata workers --help
lyftdata workers list --help

Useful read-only commands include:

lyftdata --version
lyftdata server health --json
lyftdata workers list --json
lyftdata deployments list --json
lyftdata credentials list --json
lyftdata contexts list --json

--json writes machine-readable output on commands that support it. Do not assume every older command supports JSON; check its help before scripting.

For diagnostics:

lyftdata doctor --json
lyftdata doctor --offline --bundle ./lyftdata-support.zip

doctor combines remote checks with local inventory unless --offline is used. Review bundles for sensitive logs before sharing them.

Work with credentials

The shipped credentials group can inspect credentials, allowed workers, job bindings, activation sessions, and runtime metadata:

lyftdata credentials list --tenant default --json
lyftdata credentials get <credential-id> --json
lyftdata credentials allowed-workers-list <credential-id> --json
lyftdata credentials bindings-list <credential-id> --json
lyftdata credentials job-runtime <job-id> <credential-id> --json
lyftdata credentials activation-get <activation-id> --json

Some activation-completion commands accept token material. Use stdin or protected-file flags when the installed help provides them; never pass tokens in command-line arguments. The UI remains the preferred path for interactive OAuth consent. See OAuth credentials.

Mutations and automation

Read the exact command help before any mutation. Confirmation support differs between command families in current releases. If a command offers --yes, use it only after a separate inspection or change-approval step.

For scripts:

pin the LyftData release used by the automation;
pass --url or --profile explicitly;
prefer --json for supported read operations;
keep stdout for command results and redirect diagnostic stderr separately;
stop on a non-zero exit status; and
test role, tenant, edition, and failure cases against the candidate release.

The CLI uses the product API; it does not turn runtime HTTP inputs or outputs into control-plane commands. See Product API for that boundary.

External worker hosts

For dedicated worker hosts, use the worker-only binary:

lyftdata-worker --help
Windows service management: lyftdata-worker service install --help

See Workers and your OS-specific worker guide for full setup steps.