---
title: "Environments and previews"
description: "Add a deploy target, create environments, deploy a CI artifact, and get a preview per branch, on Workers or through the Vercel, Netlify, Fly, AWS Lambda and container connectors."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.overlane.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Environments and previews

A deploy takes the artifact a passed CI run built and puts it on a target. A **target** is a place (a Cloudflare Worker, a Vercel project, a Netlify site, a Fly app, an AWS Lambda function or a container image on Fly); an **environment** such as `staging` or `production` is a named deployment on a target.

## Add a target

```sh
overlane deploy target add site --kind workers --set scriptName=site --set accountId=abc123 --credential-env CF_API_TOKEN
overlane deploy target add web --kind netlify --set siteId=my-site --credential-env NETLIFY_TOKEN
overlane deploy target add fn --kind aws --set region=ap-southeast-2 --set functionName=site --credential-env AWS_KEYS
overlane deploy target add shop --kind container --set app=shop --set image=registry.fly.io/shop --set channel.production=stable --set database=postgres --set migrationCommand='npm run migrate' --credential-env FLY_API_TOKEN
overlane deploy targets
```

| Kind | Settings | The artifact is |
|---|---|---|
| `workers` | `scriptName`, `accountId` | A module file that exports a `fetch` handler |
| `vercel` | `projectRef`, optionally `teamId` | One file, deployed as the project's content |
| `netlify` | `siteId` | A zip of the site |
| `fly` | `app`, optionally `machineId` | The text of an image reference pinned by digest (`name@sha256:...`) |
| `aws` | `region`, `functionName` | The function's zip. Each deploy publishes a version; the `live` alias moves on promote and back on rollback |
| `container` | `app`, `image`, optionally `machineId`, `port`, `channel.<environment>=<tag>`, and `database=postgres` with `databaseVersion`, `migrationCommand` and `migrationPath` | The text of an image reference pinned by digest, from the target's image repository |

The provider token comes from an environment variable or standard input and goes to the encrypted vault. For AWS it is `ACCESS_KEY_ID:SECRET_ACCESS_KEY`, with `:SESSION_TOKEN` after it for temporary keys; Overlane signs each request and never sends the secret. For a container it is a Fly access token. The target record keeps only the vault name, and no call returns the token. Adding a target stores a credential, so it is a safety class: it needs an approval from an independent agent (evidence and a reason) or a person.

A container target runs the migration command before the new image takes traffic: Overlane starts a one-off machine from the new image with the environment's secrets (put the database URL in `DATABASE_URL` with `overlane deploy env secret set`), and a migration that exits with an error stops the deploy, so the serving machine keeps the previous image. Previews are not available for AWS Lambda or container targets.

## Environments

```sh
overlane deploy env create staging --target site
overlane deploy env create production --target site
overlane deploy env secret set staging API_KEY --from-env STAGING_API_KEY
overlane deploy env secret delete staging API_KEY --force
```

`production` and `prod` are protected by default, and `--protected` protects another; see [Rollback and approvals](/git-ci-deploy/rollback-and-approvals/). On a Workers target a permanent environment other than `production` is its own script named `<script>-<environment>`, as wrangler environments are. Environment secrets go to the vault and only their names are recorded on the environment. `overlane deploy env secret delete` removes the value from the vault and the name from the environment, so later deploys no longer carry it.

## Deploy

```sh
overlane deploy run --env staging --commit 0123456789abcdef0123456789abcdef01234567 --run run_abc123
overlane deploy releases --env staging
```

The service checks the run passed and built that commit, re-hashes the stored artifact against the digest recorded at build, and asks the guardrail rules. The provider then builds a candidate, and only a candidate that built is promoted. A failed provider deploy exits 1 and the environment keeps serving its previous release. Every deploy records the commit, the artifact digest, the evidence (the run, its job logs and the artifact digest), the person or agent that deployed it and the result.

## A preview per branch

```sh
overlane deploy preview --branch feature/login --target site --commit 0123456789abcdef0123456789abcdef01234567 --run run_abc123
```

A preview makes an environment named after the branch, deploys a passed run from that branch to its own URL and never promotes it to the live one. On Workers the preview is a version uploaded with an alias, served at `<alias>-<script>.<subdomain>.workers.dev`. A newer commit on the branch replaces the preview, and the older release is marked superseded. A run from another branch cannot be deployed to the branch's preview. Previews need no approval.

Command reference: [deploy target add](/cli/deploy-target-add/), [deploy env create](/cli/deploy-env-create/), [deploy run](/cli/deploy-run/), [deploy preview](/cli/deploy-preview/) and [deploy releases](/cli/deploy-releases/).

Source: https://docs.overlane.app/git-ci-deploy/environments-and-previews/index.mdx