Environments
Last updated on September 29, 2026
Every Deployment carries one of three environment labels, and the label is fixed at build time. The environment determines where the build can run, how long it lives, and who can promote it.
The three environments
The table below summarizes how each environment is triggered, how long it sticks around, and which stations it can run on.
| Environment | Triggered by | Lifetime | Runs on |
|---|---|---|---|
| Production | Push to the production branch, manual deploy of a production-branch commit from the dashboard, or promotion of a preview deployment. | Permanent. | Every linked station with auto-push. A manual deploy reaches no station until you push it. |
| Preview | Push to a non-production branch, manual deploy of a commit from the dashboard, or tofupilot deploy without --prod. | Permanent. | No station until you push it manually. |
| Development | Local CLI build. | Session-bound. | Local CLI session only. |
Production
You create a production deployment in one of two ways:
- A commit lands on the Procedure's production branch. When auto-push is on, the build worker compiles the artifact and rolls it out to every linked Station. The push must also meet the build conditions listed for previews.
- A Developer, Admin or Owner promotes a preview deployment to production.
Production deployments are permanent. Replaced builds stay in the registry, so you can use Instant rollback to pin a station to any previous version.
Disable auto-push on a procedure when you want to decide yourself what gets built and rolled out. Pushes are still recorded, but nothing is built. Deploy a commit from the dashboard to build it, then push it to your stations.
Preview
Preview deployments build the same way production deployments do and use the same artifact format. A preview never rolls out to a station on its own, even when auto-push is on.
You can create a preview deployment in three ways:
- Git push: a push to a branch other than the production branch builds a preview when the branch is not excluded, auto-push is on, the commit author is a member allowed to deploy, at least one station is linked to the procedure, and production is not rolled back. Otherwise the push is recorded as skipped and nothing is built. A push to an excluded branch leaves no record at all.
- Dashboard: deploy a commit from a non-production branch by hand. Use this to build a push that was skipped.
- CLI:
tofupilot deploywithout--prodbuilds a preview from your local files.
To test a preview on a station, open the deployment in the dashboard and push it to the station. A station runs one deployment per Procedure, so the preview replaces the version that station was running until the next production rollout or manual push.
Stations are not yet split into development and production stations. Pushing a preview to a station on your production line changes the code that line runs.
Development
Development builds are session-bound and never leave the developer's laptop. CLI builds locally, runs against the Operator UI, and uploads the resulting Run, but the artifact itself is not uploaded.
When you want to share work-in-progress, push the branch and TofuPilot builds a preview deployment.
Environment-specific variables
TofuPilot does not inject environment-specific variables at build time. Configure MES endpoints and calibration data in the procedure YAML, then override per station in the station configuration.
How is this guide?