---
title: "Patching"
description: "Approve updates, schedule them into a window your users will tolerate, and prove afterwards that they installed."
url: "https://support.outpostplatform.com/guides/patching/"
product: "depot"
type: "how-to"
status: "stub"
ai_summary: "Guide to patch management in Outpost. Covers what the Agent reports about missing updates, approval and exclusion, maintenance windows and reboot handling, rings and staged rollout, and reporting on patch compliance across an estate."
source: "https://gitlab.com/outpostplatform/docs/-/edit/main/src/content/docs/guides/patching.md"
license: "CC BY 4.0"
---

# Patching

Patching in Outpost is three decisions: what gets approved, when it installs,
and what happens about the reboot. This guide covers making those decisions,
staging them so a bad update does not reach everything at once, and producing
the evidence that they were applied. It is for whoever owns the update policy.

<!-- TODO: write this page against the how-to template.

Sections:

- Before you begin: endpoints reporting update state, and the permissions.
- What the Agent reports, and how a missing update is detected.
- Approving and excluding updates.
- Maintenance windows, and what happens to work that overruns one.
- Reboots: deferring, forcing, and what the person using the machine sees.
- Rings: staging a rollout so a bad update stops at the first group.
- Verify: reading patch state across the estate and for one endpoint.
- If something goes wrong: an update that reports installed and is not, an
  endpoint that never leaves pending, and a window nothing ran in.
- Reporting for an audit.
-->

Follow the [how-to template](https://gitlab.com/outpostplatform/docs/-/blob/main/templates/how-to.md).