Skip to content

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 (or lyftdata-worker --help on worker-only hosts) 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.

Day-zero admin options

LyftData no longer prints a generated admin password on first start. Instead, choose the bootstrap path that matches your deployment style:

You are doing thisRecommended pathNotes
Local interactive run on a laptop, workstation, or VMUse the setup URL flowOmit --admin-init-password, keep the server on 127.0.0.1, then open the setup URL shown in the ready splash or stored in <staging-dir>/bootstrap/initial-admin.url.
Service install on a host you can log intoUse LYFTDATA_ADMIN_INIT_PASSWORD or lyftdata server create-adminThis is the most predictable path for systemd, launchd, and Windows services because logs do not include the token.
Container / Compose deploymentUse LYFTDATA_ADMIN_INIT_PASSWORD or pre-create the admin with lyftdata server create-admin against the mounted staging volumePublished container ports are typically non-loopback. Remote bootstrap is blocked by default until an admin exists.

Useful local commands:

  • lyftdata server bootstrap --staging-dir ... --bind-address ... --print-url refreshes the setup token and rewrites the local initial-admin.url file.
  • lyftdata server create-admin --staging-dir ... creates the first admin directly without using the browser setup link.

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.
  • Use the setup URL flow unless you specifically need a shared/headless password-based bootstrap.

Where to go next