reliant binary contains a copy, and reliant forge … runs it. Anything you would type as forge <command> works as reliant forge <command>. Two differences make reliant forge the better way in: it is already signed in as you, and it is always the exact Forge version your reliant was built with.
This page covers what is particular to running Forge through Reliant. To build and deploy an app, start with Deploy & host with Forge.
Which Forge you are running
reliant changes only when reliant does: each Reliant release carries a newer Forge. reliant version shows the same Forge version on its forge: line. Installing a standalone forge binary does not change what reliant forge runs.
Starting a project
reliant forge project new scaffolds a project and records the running Forge’s version in forge.yaml as forge_version:
reliant forge scaffold, not forge scaffold), so you can copy them as printed. To generate and build, the scaffold also needs Go and buf on your PATH, plus Node if you add a frontend. If one is missing, the project is still created, and Forge warns and prints the command to run once you have installed it (reliant forge generate && reliant forge build).
Signed in as you
Hosted Forge commands such asenv deploy, secret, domain, cloud and release need a credential for Reliant’s control plane. Under reliant forge there is no forge login: Forge asks Reliant for a short-lived token made from your CLI login. The token lasts at most an hour and carries only the deploy, secret and domain permissions your login holds. Shells your agents run on a daemon get the same arrangement through the daemon’s credential. Forge sign-in explains the exchange.
reliant forge cloud status <env> shows where an environment deploys to and which credential a command would use. It never prints the token. On a computer that is not signed in, it says so and names the fix:
reliant auth login, the same commands work without any further step. In CI, set the environment’s token variable (FORGE_CONTROL_PLANE_TOKEN above) to an organization automation token from reliant forge cloud token create. Forge reads that before it asks Reliant.
When the project pins a different Forge
The code a Forge project generates, and the artifacts it builds, depend on the Forge that produced them. So a project records its Forge inforge.yaml, and Forge compares that with itself before doing anything.
Read-only commands warn and continue. audit, lint, env status and other commands that change nothing print one line and carry on:
go install suggestion applies to a standalone forge. It does not change what reliant forge runs. The options below do.
Commands that rewrite the project or produce artifacts refuse. generate, scaffold, build, env build and env deploy stop rather than silently rewrite generated files the pinned Forge would have written differently. The refusal explains how to continue:
- Your
reliantis older than the project (a teammate upgraded first): update Reliant. The desktop app checks for updates under Reliant → Check for Updates. - The project is older than your
reliant: runreliant forge project upgradeto move the pin forward on purpose. It updates the project’s Go modules to the running Forge, refreshes the scaffolded files you have not edited, and shows a diff for the ones you have, without overwriting them. Commit the result like any other change.reliant forge upgrade listshows any one-time migration guides that apply. - You need the old Forge for one command: use the
go run …@<pin>line from the message. It runs the pinned version without installing anything.
--allow-version-skew exists for people working on Forge itself. Avoid it on a real project: generating with the wrong Forge is exactly what the check prevents.
A pin to a released version (such as v0.1.40) is handled a little more leniently than a pin to a specific commit. Commands that rewrite the project only warn, and build and deploy still refuse.