Installation Prerequisites

Before installing the LyftData server or workers, make sure each host meets the baseline requirements below. These checks keep the platform secure, ensure upgrades go smoothly, and reduce duplicated setup steps across operating systems.

Readiness checklist

Task	Primary owner	Typical effort
Confirm host OS, CPU architecture, and service manager support	Infrastructure / IT	5 minutes
Create non-interactive service account and dedicated data directory	Infrastructure / IT	10–15 minutes per host
Open server port `3000` (or desired alternative) and validate DNS reachability	Networking / Security	10 minutes
Collect staging path, admin bootstrap password, and license acceptance decision	Platform team	5 minutes
Download and stage the LyftData binary (see Prepare the binary)	Platform / DevOps	10 minutes

Collect these details before touching the platform-specific guides so the install can proceed without handoffs or rework.

Supported platforms

Linux: 64-bit Linux (GNU) on x86-64 or aarch64 (server and worker).
macOS: Apple Silicon (arm64) on macOS 11.0+.
Windows: Windows 10/11 or Windows Server 2016+ (x86-64).

Check Downloads for the currently published builds. All platforms use the same LyftData binary format (server/CLI or worker-only)—download the matching archive once per host and confirm lyftdata --version prints the expected build.

Accounts and directories

Create a dedicated service account on every host before you register it as a server or worker. The account should:

Run without interactive logins (/usr/bin/false shell on Unix, PasswordNeverExpires on Windows).
Own a writable data directory (for example /var/lib/lyftdata-server, /var/lib/lyftdata-worker, or C:\\ProgramData\\LyftData\\server).
Restrict permissions to the service account (chmod 700 on Unix, explicit ACLs on Windows).

Co-locating multiple services on the same host is supported, but create separate accounts and directories per role to maintain isolation.

Linux service accounts

sudo adduser --system --home /var/lib/lyftdata --disabled-login --group <user>
sudo mkdir -p /var/lib/lyftdata
sudo chown <user>:<user> /var/lib/lyftdata
sudo chmod 700 /var/lib/lyftdata

Replace <user> with the service name (for example lyftdata for the server or lyftdata-worker for external workers) and update the home directory to match your staging path (e.g., /var/lib/lyftdata-server).

macOS service accounts

sudo sysadminctl -addUser <user> -shell /usr/bin/false -home /var/lib/<dir> -password -
sudo mkdir -p /var/lib/<dir>
sudo chown <user>:staff /var/lib/<dir>
sudo chmod 700 /var/lib/<dir>

Substitute <user> and <dir> for the role you are provisioning (for example lyftdata / lyftdata-server for the server).

Windows service accounts

New-LocalUser -Name "<user>" -Description "LyftData service" -PasswordNeverExpires -UserMayNotChangePassword
Add-LocalGroupMember -Group "Users" -Member "<user>"
New-Item -ItemType Directory -Path "C:\ProgramData\LyftData\<dir>" -Force
$acl = Get-Acl "C:\ProgramData\LyftData\<dir>"
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule("<user>","FullControl","ContainerInherit,ObjectInherit","None","Allow")
$acl.SetAccessRule($rule)
Set-Acl "C:\ProgramData\LyftData\<dir>" $acl

Replace <user> / <dir> with values such as lyftdata / server or lyftdata-worker / worker, and keep the data directory permissions scoped to the service principal.

When running as services, it is recommended to set LYFTDATA_STAGING_DIR (server) and LYFTDATA_JOBS_DIR (worker) to these dedicated directories so upgrades, backups, and resets are predictable.

Network and firewall

Component	Default listener	Purpose
Server UI & API	`127.0.0.1:3000`	Web UI, CLI, worker coordination

Adjust firewall rules so the server port is reachable from browsers, the CLI, and any remote workers. For production, document who owns the rule change and track the approval in your rollout plan.

Licensing and secrets

Accept the EULA once per host by setting LYFTDATA_LICENSE_EULA_ACCEPT=yes for both server and worker services.
Community Edition supports the built-in worker only; adding external workers requires a license. See Licensing for options.
Never hard-code API keys in scripts. Store worker API keys in scoped environment files or secret stores and limit access to administrators.

Environment variables (service installs)

LyftData supports configuration via CLI flags or environment variables. Service managers typically use environment variables so services start consistently at boot.

Common server variables:

LYFTDATA_STAGING_DIR (recommended): server data directory. If unset, LyftData uses an OS default.
LYFTDATA_LICENSE_EULA_ACCEPT=yes (recommended): avoids the one-time prompt during automation.
LYFTDATA_ADMIN_INIT_PASSWORD (optional): sets the initial admin password. If unset, LyftData enters initial setup and writes a one-time setup link to <staging-dir>/bootstrap/initial-admin.url.
LYFTDATA_BIND_ADDRESS (optional): defaults to 127.0.0.1:3000.

Common external worker variables:

LYFTDATA_URL (required): base server URL including scheme (https://… by default; use http://… only when the server runs with --disable-tls).
LYFTDATA_WORKER_API_KEY (required for pre-issued enrollment): authenticates the worker against the server.
LYFTDATA_AUTO_ENROLLMENT_KEY (optional alternative): use auto-enrollment instead of a pre-issued API key.
LYFTDATA_JOBS_DIR (recommended): worker data directory. If unset, the worker uses an OS default.
LYFTDATA_WORKER_ID (optional): if unset, the worker can persist identity locally after enrollment.

If you are using a self-signed server certificate during evaluation, you may need --tls-insecure (or LYFTDATA_TLS_INSECURE=true) on CLI/worker clients until you install a trusted certificate.

Configure optional settings—LYFTDATA_BIND_ADDRESS, LYFTDATA_LOG_RETENTION_DAYS, and LYFTDATA_DB_DISK_USE_MAX_PERCENT—only when you need to expose additional interfaces or adjust retention defaults.

Windows service management

Windows deployments can install services natively via lyftdata service ... (recommended) or by using the MSI installer. Use NSSM only for legacy installs when running an older binary that does not include the native service commands.

Next steps

Validate the prerequisites on every host.
Follow Prepare the binary to fetch and verify the executable.
Continue with the platform-specific server or worker guide to wire up the service manager.