# 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.

```bash
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](https://lizard.build/docs/concepts/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](https://lizard.build/docs/deploy/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:

```json
{ "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

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

In the [dashboard](https://lizard.build/docs/dashboard), the **Deployments** view shows the full timeline, per-deploy build logs, and a detail drawer for each release.

## Restarts vs. redeploys

| Command | What it does |
|---------|--------------|
| `lizard restart --service <svc>` | Restart of the **current** build — no rebuild |
| `lizard redeploy --service <svc>` | Fresh **build** from latest commit/upload, then release |

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:

```bash
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](https://lizard.build/docs/concepts/build-pipeline#what-triggers-a-rebuild).

## 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](https://lizard.build/docs/platform/known-issues).