---
title: Operations
description: How UseAgent ships, how it proves a release, and the invariants production runs on.
sidebar:
  label: Overview
  order: 1
---

Operations in UseAgent are built around one principle: a release must prove itself
before it ships, and roll back cleanly if it cannot.

<CardGroup cols={2}>
  <Card title="Deployment lanes" href="/operations/deployment" icon="rocket">
    The guarded release and the provider-connection bootstrap, both ending in
    the atomic frontend swap.
  </Card>
  <Card title="Verification" href="/operations/verification" icon="check-check">
    The test and parity arsenal, from isolated-database unit suites to real
    engine journeys.
  </Card>
  <Card title="Invariants" href="/operations/invariants" icon="lock">
    Single backend per database, write-only secrets, a restricted gateway role,
    and immutable-source releases.
  </Card>
  <Card title="Backups and restore" href="/operations/backups" icon="archive">
    A daily encrypted snapshot with verify and restore lanes, and the off-host
    requirement.
  </Card>
</CardGroup>

## The shape of a safe change

1. **Type-check everything**

    `bun run typecheck` covers the frontend, backend, and shared packages, and
    must pass before a change is done.

2. **Verify in isolation**

    Suites run against a throwaway database so they never disturb a live one.

3. **Certify a candidate**

    The guarded release runs fail-closed gates and per-engine parity canaries
    against a candidate before it can ship.

4. **Roll back on any failure**

    Source, environment, Caddy configuration, and services all restore to the
    prior state if any preflight or parity journey fails.