Deployments

A deployment is one build-and-release of a service. Services run as Kubernetes pods. A successful build does not by itself prove that the application started or can serve requests.

How a deploy happens

These actions start a deployment:

• 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 both preDeployCommand and startCommand are set, the container runs sh -c "<pre> && exec <start>". The pre-deploy command runs at the start of every container (each replica, each restart), so make it safe to run many times and at the same time. Without startCommand it is skipped.
3. Start: Lizard starts the new pod next to the old one. Workers and services with an attached volume stop the old pod first, so they are down for a short time on every deploy and restart.
4. Health check: a TCP probe checks the app’s port every 2 seconds, and traffic moves only to a ready pod. Lizard waits about 30 seconds for it; if the new pod is not ready by then, the deploy is marked failed. Workers skip the probe.
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 lizard up --json, you get one JSON event per line:

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

The final event is deployed, failed, or deploying. lizard redeploy --json prints no log lines: it returns one object at once (status: "deploying"), or, with --wait, one object at the end with ok and the final status. 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, each service’s Overview tab lists its deploys. Open one to see its status, source, build logs and restarts.

Restarts vs. redeploys

See lizard restart and lizard redeploy. Use restart to restart 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 of a running service: see the rebuild triggers table and build-time variables.

Failed releases and recovery

A failed build and a failed application start are different cases. A failed build changes nothing: the running version keeps serving. When a new pod never becomes ready, an HTTP service keeps serving its previous version, and the new pod gets no traffic. Workers and services with an attached volume stop the old pod before the new one starts, so a release that never becomes ready leaves them down. 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 October 21, 2026