// Rolling back a Golem deployment to a previous revision or version. Use when reverting a deployment, restoring a prior environment state, or recovering from a bad deploy.
Adding a new component or agent templates to an existing Golem application. Use when adding a second component, adding agent templates like human-in-the-loop or snapshotting to an existing component, or converting a single-component app to multi-component.
Defining environment variables for Golem agents in `golem.yaml` (`env`, `envDefaults`, `secretDefaults`) or via CLI. Use when adding, setting, or overriding env vars on a component, agent, template, preset, or environment, or when wiring template substitution and merge modes.
Adding initial files to Golem agent filesystems via the `files:` section in `golem.yaml`. Use when provisioning local or remote files into an agent's virtual filesystem, setting read-only / read-write permissions, or configuring file mounts at the component, agent, template, or preset level.
Building a Golem application. Use when asked to build a Golem project, compile components to WASM, or troubleshoot build errors.
Managing Golem plugins — listing available plugins, installing and configuring plugins via golem.yaml or CLI, and understanding built-in plugins like the OTLP exporter.
Understanding Golem CLI profiles, application environments, and component presets. Use when configuring deployment targets, switching between local and cloud servers, managing CLI profiles, defining environment-specific presets, or understanding how environments, presets, and profiles interact.
| name | golem-rollback |
| description | Rolling back a Golem deployment to a previous revision or version. Use when reverting a deployment, restoring a prior environment state, or recovering from a bad deploy. |
Both golem and golem-cli can be used — all commands below work with either binary.
Every golem deploy creates a new deployment revision — an immutable snapshot of the environment's components and HTTP API deployments. Rollback lets you revert the environment to a previous revision, restoring the exact component versions and API configuration that were active at that point.
Rollback does not rebuild or re-upload components — it re-activates a previously deployed revision on the server side.
golem deploy --revision <REVISION_NUMBER> --yes
Reverts the environment to the exact state captured at the given deployment revision number. The revision must exist in the environment's deployment history.
If the specified revision is not found, the CLI prints an error and lists all available deployments with their revision numbers and versions.
golem deploy --version <VERSION_STRING> --yes
Looks up the deployment whose version label matches <VERSION_STRING> and rolls back to that revision. If multiple deployments share the same version string, the CLI reports an error and asks you to use --revision instead.
--yes is passed, the CLI prompts for confirmation before proceeding.DeploymentRollback request to the server containing the current revision and the target revision. The server atomically switches the environment to the target state.If the target revision is identical to the current deployment (same deployment hash), the CLI reports "up to date" and takes no action.
Rollback supports the same post-deploy flags as a normal deploy:
| Flag | Description |
|---|---|
--update-agents <MODE> | Update existing agents to the rolled-back component version (auto or manual) |
--redeploy-agents | Delete and recreate existing agents using the rolled-back version |
--reset | Delete agents and the environment, then deploy |
Roll back and update all running agents automatically:
golem deploy --revision 3 --update-agents auto --yes
Roll back by version and redeploy agents:
golem deploy --version "v1.2.0" --redeploy-agents --yes
golem deploy --yes --revision 3 --plan
Shows the diff of what would change without applying anything. Useful for inspecting the impact before committing.
If you do not know which revision to target, deploy with a non-existent revision number — the CLI will print all available deployments. Alternatively, use the environment API or the Golem dashboard to browse deployment history.
--revision and --version conflict with each other — use one or the other.--revision and --version conflict with --force-build, --stage, and --approve-staging-steps — rollback does not trigger a build.