Skip to content
LyftData Docs (Beta)

Configuration Basics

LyftData can be configured in three ways. Most deployments use all three: CLI flags for ad-hoc runs, environment variables for services, and UI settings for day-two operations.

Configuration surfaces

  • CLI flags: Use lyftdata run server --help and lyftdata run worker --help to discover flags and defaults. Flags are ideal for local evaluation because they are explicit and easy to copy/paste.
  • Environment variables: Service managers typically set LYFTDATA_* variables so the service starts consistently on boot. Use the patterns shown in the OS install guides (Linux /etc/default/*, macOS launchd plist EnvironmentVariables, Windows machine-scoped env vars).
  • UI settings: Some runtime settings (for example per-worker metrics) are managed from the web UI after the worker is registered. Start with Next steps for the common post-install toggles.

Where LyftData stores state

Plan your data directories early, especially for production:

  • Server staging directory: --staging-dir / LYFTDATA_STAGING_DIR is the server’s primary data directory. It stores job definitions and operational data needed to run the control plane.
  • Worker jobs directory: LYFTDATA_JOBS_DIR is the worker’s local directory for cached job definitions and worker state.
  • Service user home directory: Some platforms may also write small runtime files under the service user’s home directory. Ensure the service user home is writable and managed like application state.

For host preparation patterns (service accounts, directory ownership, permissions), see Prerequisites.

For a trial eval on a single host:

  • Keep the server bound to localhost (127.0.0.1:3000).
  • Set LYFTDATA_LICENSE_EULA_ACCEPT=yes for the server process so automation does not stall on the one-time prompt.
  • Set an explicit admin password (for example via --admin-init-password) and change it after first login.

Where to go next