> ## Documentation Index
> Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Deploy a policy
> Put a tested policy version on machines in observe mode, enforce it, and confirm every machine picked it up.
A deployment puts published policy versions on a machine, each with one of two effects:
* **Observe** records what the policy would have done, and blocks nothing.
* **Enforce** acts on the decision: a `deny` blocks the call and an `instruct` steers the agent.
## Add a machine
A machine appears under **Admin → enforcement** once it is connected to Cloud. If the one you want is not there yet:
1. Go to **Administration → Keys** and create a key with `policies:pull`, so the machine can receive deployments, and `events:add`, so its decisions reach Cloud.
2. Connect the machine with that key — [Connect a machine to Cloud](/start/setup#connect-a-machine-to-cloud) walks through it.
3. Confirm it shows up under **Admin → enforcement**.
On the machine:
```bash theme={null}
npm install -g failproofai
failproofai config
failproofai config --status
```
In a terminal, `failproofai config` asks whether to connect to Cloud and takes the key at a masked prompt. Then confirm the machine is enrolled, from anywhere, with `fp fleet list`.
## Deploy in observe mode
1. Go to **Admin → enforcement**, find the machine, and expand its row.
2. Select **edit**, add the tested policy version, and choose **observe**.
3. Apply the change, then wait for the machine's next check-in and confirm its deployment and coverage state.
4. Go to **Observe → policy** to inspect live decisions.
```bash theme={null}
fp fleet list
fp fleet show
fp fleet deploy --add no-force-push:observe
```
The `:observe` suffix is what makes it observe: a bare `--add no-force-push` keeps the effect the machine already has for that policy, and otherwise enforces. Switch it to enforce later with `--add no-force-push:enforce`.
`deploy` **replaces the machine's whole policy set** with the result. It prints the plan, then asks before applying — but only on an interactive terminal. With `--yes`, under `fp --json`, or with stdin redirected (a CI step, a script, an agent shelling out) it applies without asking; the plan is still printed, or returned as `plan` under `--json`.
On the machine, `failproofai policies` lists the Cloud-managed policies it is running and `failproofai config --status` shows its connection. Use `fp sessions --env production --since 24h` and `fp events --event-type hook_completed` to confirm its activity reaches Cloud.
Pick the published version and the machines it should run on.
Review matches, reasons, affected tools, and false positives while nothing is blocked.
Switch the effect to enforce once the observed matches separate unsafe actions from valid ones, then confirm every intended machine pulled the change and is reporting decisions.
## Check coverage
Coverage answers whether a policy is running where the risk is.
1. Go to **Admin → enforcement** and review the enforcing and observing totals.
2. Search for a machine by ID or label, or filter for machines missing a policy.
3. Expand a row to compare assigned policies, reported deployment, last check-in, and history.
4. Refresh after the machine's polling interval when an applied deployment is still pending.
Look for machines that never pulled the latest deployment, enrolled machines that stopped reporting, a policy assigned to the wrong environment, and version drift after an interrupted update.
Label machines by workload and environment — hostnames alone rarely survive autoscaling or replacement:
```bash theme={null}
failproofai config --machine-label checkout-runner-03
```
Enforcement management is an administrative Cloud workflow. Do not treat root-only enforcement routes as ordinary customer `/v1` API endpoints.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.