Deployments

A deployment is one build-and-release of a service. The release path depends on the service runtime. A successful build does not by itself prove that the application started or can serve requests.

How a deploy happens

A deployment is triggered by any of:

• A git push to the tracked branch (for github-source services).
• lizard redeploy — rebuild from the latest commit (git) or last upload, with current variables.
• lizard up — upload the current directory and deploy it.
• A service set that changes a build-affecting field.

lizard redeploy --service api      # rebuild + redeploy from current source
lizard up                          # upload cwd and deploy

Lifecycle

1. Build — the platform runs your build (see Build Pipeline).
2. Pre-deploy — if preDeployCommand is set, it runs once (e.g. migrations).
3. Start — Lizard starts the application for its configured runtime.
4. Health check — the platform verifies the app’s port is reachable (skipped for workers).
5. Verify — inspect the release status and call the application URL. Port reachability is not a full application health check.

Streaming output

When you run a non-detached lizard up (or redeploy), build logs stream live. With --json, you get one JSON event per line:

{ "event": "log", "line": "..." }
{ "event": "deployed", "status": "...", "url": "https://..." }

terminating in deployed, failed, or deploying. Use --detach to start the deploy and return immediately without streaming.

Inspecting history

lizard events                  # deploy history + per-replica status
lizard events --limit 25       # show more
lizard ps                      # current services, status, and URLs

In the dashboard, the Deployments view shows the full timeline, per-deploy build logs, and a detail drawer for each release.

Restarts vs. redeploys

Use restart to recycle replicas (e.g. to pick up a runtime secret that didn’t hot-reload); use redeploy when you need a new build.

Recovering from a crash

Inspect the most recent crash or restart’s logs:

lizard logs --restart latest       # log tail around the latest restart
lizard logs --restart <id>         # a specific restart
lizard events                      # see replica status

Config changes (no rebuild)

Most environment variable and secret changes apply without a rebuild: Lizard updates the service’s config and restarts it, which takes a few seconds. Build-time values (VITE_*, NEXT_PUBLIC_*) and build-field changes do force a rebuild — see the rebuild triggers table.

Failed releases and recovery

A failed build and a failed application start are different cases. Do not assume an old release continues serving in every runtime. Inspect the active service, build logs, and runtime logs. lizard redeploy builds the selected source again; it is not a command for restoring a previous build. Revert the source commit when needed, deploy it, and check the result. See known issues.

Updated September 7, 2026