Skip to content
LyftData Docs (Beta)

Networking & TLS

LyftData serves HTTPS (TLS) by default. If you do not provide TLS material, the server generates and persists a self-signed certificate (suitable for evaluation, not production).

For local evaluation you can either:

  • Use https://… and accept the browser warning (and use -k with curl), or
  • Start the server with --disable-tls to serve plain HTTP (recommended only when terminating TLS behind a reverse proxy, or for local-only evaluation).

Basic connectivity model

  • Browser / CLI → Server: Users access the UI and API on the server address (default 127.0.0.1:3000, HTTPS by default).
  • Worker → Server: Workers connect back to the server using LYFTDATA_URL (including the scheme, http:// or https://) and authenticate with LYFTDATA_WORKER_API_KEY.

If the server binds only to 127.0.0.1, remote browsers and remote workers cannot reach it.

Bind address and ports

  • Change the server listen address with --bind-address (or LYFTDATA_BIND_ADDRESS when running as a service).
  • Ensure firewalls allow browser/CLI access and worker access to the chosen port (default 3000).
  • Set LYFTDATA_URL on workers to the exact URL they should use to reach the server (include the scheme, such as http:// or https://).

TLS options

LyftData supports two common deployment patterns:

  • Default (self-signed TLS): If you do not configure any TLS flags, LyftData serves HTTPS using a self-signed certificate. This is ideal for evaluation. External workers or CLI clients may need --tls-insecure (or LYFTDATA_TLS_INSECURE=true) until you replace it with a trusted certificate.
  • Built-in TLS: Configure the server with a certificate and key using the lyftdata run server TLS flags (see lyftdata run server --help). This keeps the deployment simple when you do not already run an ingress proxy.
  • Reverse proxy termination: Terminate TLS in a proxy (for example Caddy or Nginx) and forward requests to the server over HTTP (run the server with --disable-tls). When using a proxy, ensure it forwards the correct client IP headers so logs and audits reflect real clients.

For broader hardening guidance, see Security Hardening.

Verify reachability

After changing networking or TLS settings, confirm:

  • The UI loads in a browser on the expected URL.
  • Liveness responds:
    • HTTPS (default, self-signed): curl -k https://<server-host>:3000/api/liveness
    • HTTP (only when --disable-tls is set): curl http://<server-host>:3000/api/liveness
  • Workers show Online in the UI after you deploy them.

Common pitfalls

  • LYFTDATA_URL uses http:// but the server is serving https:// (or vice versa).
  • The server is still bound to 127.0.0.1, so remote clients cannot connect.
  • Certificate hostname mismatches (CN/SAN does not match the URL you use).

If you get stuck, start with Troubleshooting.