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 --helpandlyftdata run worker --help(orlyftdata-worker --helpon 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 plistEnvironmentVariables, 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 this | Recommended path | Notes |
|---|---|---|
| Local interactive run on a laptop, workstation, or VM | Use the setup URL flow | Omit --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 into | Use LYFTDATA_ADMIN_INIT_PASSWORD or lyftdata server create-admin | This is the most predictable path for systemd, launchd, and Windows services because logs do not include the token. |
| Container / Compose deployment | Use LYFTDATA_ADMIN_INIT_PASSWORD or pre-create the admin with lyftdata server create-admin against the mounted staging volume | Published 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-urlrefreshes the setup token and rewrites the localinitial-admin.urlfile.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_DIRis the server’s primary data directory. It stores job definitions and operational data needed to run the control plane. - Worker jobs directory:
LYFTDATA_JOBS_DIRis 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.
Recommended defaults (evaluation)
For a trial eval on a single host:
- Keep the server bound to localhost (
127.0.0.1:3000). - Set
LYFTDATA_LICENSE_EULA_ACCEPT=yesfor 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
- Complete configuration reference: Configuration
- Connectivity and certificates: Networking & TLS
- Common failures: Troubleshooting