Skip to main content
Part 2 of the onboarding guide. Finish Set up FireWeave first. The change is whatever you want to make to try a FireWeave rollout — a feature, a bug fix, an optimization. FireWeave wraps it in a flag, a manifest, and a rollout, so it ships gradually with an audit trail instead of all at once. This is the moment everything above was setting up. Block 45 minutes and do the first one with us on a call. Pick something real but small.
1

Write the change

Goal: The change ships behind a flag, with a manifest your agent can verify against the code.Three things are produced together: a manifest declaring the flag and its guardrail metrics, the flag itself with an anchor comment wherever it’s checked, and a checklist the agent passes before opening a PR.
  • Manifest written before the code
  • // @fireweave-flag anchor comment at every evaluation site
  • Agent checklist passing
A PR containing the manifest, the flagged code path, and matching anchor comments.
2

Ship the change

Goal: The rollout is registered and your build reaches your environment, where it ramps.Register the rollout (makes no code changes):
Then deploy through your usual process. If CD is enabled on this repo, there’s nothing to do — the merge deploys it.
On boot the app reports its stamps, and the staging rollout begins ramping.
3

Watch the ramp

Go to the dashboard in the project to see the progress of the rollouts.The release agent manages the ramp for you. If you want manual control, the rollout page gives you four options: Pause, Resume, Roll forward, Roll back.
4

Retire the flag

Goal: Dead flags don’t accumulate.Run monthly, not per change:
It only proposes flags that are measurably dead, and removes nothing without your confirmation.
A confirmed list of removed flags, with the manifests and code paths cleaned up alongside them.

After your first rollout

Last modified on August 23, 2026