---
title: "Operations"
manual: "nr-vault"
version: "1.0"
permalink: "https://docs.typo3.org/permalink/netresearch/nr-vault:operations@1.0"
source: "Operations/Index.rst"
rendered: "2026-09-18T07:37:50+00:00"
---

# Operations {#operations-1}

Running nr-vault in production: deploying the hardened profile, holding key
material, backing it up, rotating it, watching the audit pipeline, responding
to incidents, and shutting the vault down again.

These pages assume the concepts from [Security](https://docs.typo3.org/permalink/netresearch/nr-vault:security@1.0). Per-setting reference is
in [Configuration](https://docs.typo3.org/permalink/netresearch/nr-vault:configuration@1.0); per-command reference in
[CLI commands](https://docs.typo3.org/permalink/netresearch/nr-vault:developer-commands@1.0).

-   [Hardened deployment](https://docs.typo3.org/permalink/netresearch/nr-vault:hardened-deployment@1.0)
-   [Key custody](https://docs.typo3.org/permalink/netresearch/nr-vault:key-custody@1.0)
-   [Backup and restore](https://docs.typo3.org/permalink/netresearch/nr-vault:backup-and-restore@1.0)
-   [Key rotation](https://docs.typo3.org/permalink/netresearch/nr-vault:key-rotation@1.0)
-   [Monitoring and alerting](https://docs.typo3.org/permalink/netresearch/nr-vault:monitoring-and-alerting@1.0)
-   [Incident response](https://docs.typo3.org/permalink/netresearch/nr-vault:incident-response@1.0)
-   [Decommissioning](https://docs.typo3.org/permalink/netresearch/nr-vault:decommissioning@1.0)

## Start here {#start-here}

| If you are … | Read |
| --- | --- |
| deploying a vault that holds production credentials | [Hardened deployment](https://docs.typo3.org/permalink/netresearch/nr-vault:operations-hardened-deployment@1.0), then [Key custody](https://docs.typo3.org/permalink/netresearch/nr-vault:operations-key-custody@1.0) |
| converting an existing standard installation | [Migrating from standard to hardened](https://docs.typo3.org/permalink/netresearch/nr-vault:security-profiles-migration@1.0) — the order matters, because the key has to move before the profile does |
| setting up backups | [Backup and restore](https://docs.typo3.org/permalink/netresearch/nr-vault:operations-backup-and-restore@1.0). The database alone is not a backup, and the database plus the key in one artefact is not a protection |
| wiring monitoring | [Monitoring and alerting](https://docs.typo3.org/permalink/netresearch/nr-vault:operations-monitoring-and-alerting@1.0). Anchoring and verification are two different jobs and you need both |
| handling an incident | [Incident response](https://docs.typo3.org/permalink/netresearch/nr-vault:operations-incident-response@1.0) — read the runbook before executing step 1; several useful actions destroy evidence |
| retiring the installation | [Decommissioning](https://docs.typo3.org/permalink/netresearch/nr-vault:operations-decommissioning@1.0). Note that `vault:delete` is a soft delete |

## The four things that actually matter {#the-four-things-that-actually-matter}

Everything else on these pages is detail around these.

1.  **The master key is not in the database — keep it that way in backups
    too.** A dump taken together with the key material is a single artefact
    containing everything. This is easiest to get wrong with the `typo3`
    provider, where the key lives in `config/system/settings.php`.
1.  **Master key loss is data loss.** There is no escrow and no reset. Back it
    up separately, and verify the backup by restoring it somewhere and
    decrypting something.
1.  **The audit chain needs an external anchor to be worth anything against a
    database writer.** The chain detects row edits; only an anchor published
    outside the database detects a wholesale reset — and only if it is stored
    somewhere the attacker cannot truncate.
1.  **A scheduled check whose failures nobody receives is not a control.**
    Schedule anchoring and verification, then wire the alerts, then break the
    delivery on purpose once to confirm the alert arrives.