TILLFORGE · DEPLOYMENTS

Preview before production — with a gate where it counts.

A deployment ships a specific commit to a named environment. Previews land freely so you can see a change before it’s real; production environments can require approvals before anything goes out. Every deploy records the exact commit, so a crash later traces straight back to what shipped.

01Environments

Define preview and production

An environment is a named target — preview, staging, production, whatever your flow needs. Mark the ones that matter --production and set --approvals so a deploy to them waits for sign-off. Preview environments stay open, so a branch or a pull request can go live for review with no ceremony.

bash

# Define your environments. A preview env is open; a production env can
# require approvals before anything lands.
tilldev forge env set acme-api --name preview --url https://preview.acme.dev
tilldev forge env set acme-api --name production --production \
  --url https://acme.dev --approvals 1
tilldev forge env ls acme-api

The gate lives on the environment, not the person

Required approvals attach to the environment, so the rule is the same no matter who runs the deploy — the same posture as branch protection, applied to shipping instead of merging.

02Deploy

Deploy a preview, then promote

Deploy a ref — a branch, a tag, or a release — to an environment. The natural path is preview first, then promote the very same commit to production once it’s reviewed. Because a deploy names a commit, a promotion is provably the thing you already saw, not a fresh build that drifted.

bash

# Deploy a ref to an environment. Previews first — a branch or a PR.
tilldev forge deploy create acme-api --env preview --ref feat/checkout \
  --url https://checkout.preview.acme.dev

# Promote to production by deploying the same commit to the gated env.
tilldev forge deploy create acme-api --env production --ref v1.4.0

# Move a deployment through its lifecycle as your pipeline reports back.
tilldev forge deploy status acme-api <id> --state success
tilldev forge deploy ls acme-api --env production

03Lifecycle

Track every deploy

Your pipeline reports a deployment through its states as it runs. The Deploy tab shows the current state of every environment and the full history beneath it.

State	Meaning
`queued`	Accepted, waiting to start (or for approval).
`in_progress`	Rolling out now.
`success`	Live. This is the current deploy for the environment.
`failure`	The rollout failed; the previous deploy stays live.
`error`	The pipeline errored before it could finish.
`inactive`	Superseded by a newer deploy, or torn down.

Each deployment can carry a --url (where the deploy is reachable) and a link to its run. A deployment event fires on every state change, so your own dashboards and chat can follow along.

04Correlation

From deploy to the crash it caused

Because a deployment is pinned to a commit, TillForge can line up commit → deploy → incident. When something breaks after a release, the trail runs from the crash back to the deploy that shipped it and the exact change inside it — the same correlation that powers a pull request’s release view.

Next: Releases & builds for what you promote, or Events & webhooks to wire deploys into your own pipeline. Back to the TillForge overview.