Upgrades & Rollbacks

Upgrading LyftData is usually “replace the binary and restart services”, but you should treat it like an application upgrade: take a backup, verify liveness, and have a rollback plan.

Before you upgrade

• Read the release notes: Releases overview
• Take a backup of the server data directory and any external state you rely on: Backup & Recovery
• Pick a maintenance window if you are running production workloads.

Default upgrade procedure (production)

1. Back up the server’s staging directory (LYFTDATA_STAGING_DIR) and record the current lyftdata --version.
2. Stop the server service (and any workers you manage on the same host).
3. Replace the lyftdata binary with the new version (keep file permissions and service paths the same).
4. Start the server service, then start worker services.
5. Verify:
   • Liveness responds on the expected URL:
     • HTTPS (default, self-signed): curl -k https://<server-host>:3000/api/liveness
     • HTTP (only when the server runs with --disable-tls): curl http://<server-host>:3000/api/liveness
   • You can sign in to the UI.
   • Workers show Online and can run a staged job.

Rollback guidance

If the upgrade fails basic checks:

1. Stop the affected service(s).
2. Restore the previous lyftdata binary.
3. Restart and re-check liveness and worker connectivity.

If an upgrade includes a data migration, restoring the previous binary may not be sufficient. In that case, restore the server data directory from your pre-upgrade backup.

Evaluation upgrades

For evaluation environments created with Evaluation Quickstart, the simplest upgrade is to download a fresh binary into your eval directory and restart the process. If you want to keep your jobs/history, keep the staging directory and only replace the binary.