---
title: "CLI de l'image"
description: "L'image est un appareil prêt à l'emploi : l'entrypoint notarium, les commandes start, backup, restore, admin, healthcheck, version et le contrat des flux."
---

# CLI de l'image

L'image sait déjà se lancer toute seule : inutile d'ajouter une commande à `docker run`, par défaut c'est le serveur qui démarre. Un argument ne remplace que la commande, si bien qu'une opération ponctuelle se lit tout naturellement — `docker run … IMAGE restore`.

Dans un conteneur en marche, les commandes d'opérateur s'appellent via `docker exec`, sous des noms courts :

```bash
docker exec notarium backup
docker exec -it notarium admin list
```

## Commandes

| Commande | Ce qu'elle fait | Comment on l'invoque d'ordinaire |
|---|---|---|
| `start` | Lance le serveur HTTP/MCP en tant que PID 1 | La commande par défaut de l'image |
| `backup` | Émet en flux un ZIP à chaud déjà vérifié | `docker exec notarium backup`, plus la séquence de publication sûre du [runbook](/docs/self-hosting/backup/) |
| `backup verify` | Vérifie une archive sans rien modifier | `docker exec -i notarium backup verify < fichier` |
| `restore` | Installe une archive dans une racine des données vide | Un conteneur ponctuel sur un volume neuf |
| `admin` | Récupère l'accès en dehors de l'interface | `docker exec -it notarium admin …` |
| `healthcheck` | Interroge le `/api/health` local | Le `HEALTHCHECK` de Docker |
| `version` | Version, commit, date de compilation et lien vers les sources (`--json` pour les scripts) | Support et vérification de la compatibilité |
| `help` / `--help` | Décrit la CLI ou une commande précise | N'importe quel conteneur |

`start` reste au premier plan, et les signaux du conteneur atteignent donc directement le serveur — `docker stop` l'arrête proprement. Il n'existe volontairement aucune commande d'arrêt ni de redémarrage : c'est l'affaire de l'orchestrateur. Les migrations de schéma s'appliquent au démarrage ; vous n'avez jamais à les lancer par une commande à part.

## Flux et codes de sortie

- En mode flux (sans `--output`), `backup` n'envoie sur stdout **que** les octets du ZIP ; les diagnostics et le récapitulatif final partent sur stderr. Avec `--output FILE`, l'archive est écrite dans ce fichier et un unique récapitulatif JSON part sur stdout — ne le redirigez pas vers un `.zip`, ce qui atterrirait là ne serait pas une archive.
- `backup verify`, `restore` et les commandes `admin` non interactives impriment leur résultat sur stdout.
- Les erreurs partent sur stderr et renvoient un code non nul. Les commandes inconnues, les options inconnues, les options répétées et les options sans valeur **échouent** au lieu d'être ignorées en silence.
- Le transport canonique sous Docker, ce sont **stdin et stdout**. Les options jumelles `--output FILE` de `backup` et `--input FILE` de `verify`/`restore` existent pour les cas où le conteneur voit déjà le répertoire. `--output` a un effet de bord bienvenu : la commande écrit elle-même dans un fichier temporaire, vérifie l'archive et la publie de façon atomique sans rien écraser — il n'y a donc aucune enveloppe shell à écrire.
- Chaque commande dispose de `--help` ; `notarium --version` équivaut à `notarium version`.

## Identité du build

`version` affiche exactement ce que vous faites tourner — c'est le point de départ de toute discussion sur la compatibilité et de toute mise à niveau :

```bash
docker run --rm docouno/notarium:latest version
docker compose exec notarium version --json
```

`version --json` renvoie la même chose en un seul objet — `version`, `commit`, `builtAt` et `source` (un lien vers la révision exacte des sources) —, si bien que le contrôle « qu'est-ce qui est déployé ? » peut aller directement dans votre pipeline de déploiement. Ce que le build n'a honnêtement pas est renvoyé comme `null` : les valeurs ne sont jamais inventées, vous pouvez donc vous appuyer dessus. La même information figure dans l'interface — **Settings → About**.

> [!important] Les tags de version sont immuables
> Un tag de version publié désigne toujours une image bien précise : `:0.1.0` ne migrera jamais vers un autre build. En production, épinglez donc une version plutôt que `:latest`. L'image publiée est compilée pour `linux/amd64` ; sur les autres architectures, construisez depuis les sources.

## Health checks

`healthcheck` ne renvoie un code de sortie nul que lorsque l'endpoint local `/api/health` se déclare en bonne santé. Il est conçu pour la directive `HEALTHCHECK` de Docker et pour les sondes de l'orchestrateur — aucune dépendance externe, et pas besoin de `curl` sur l'hôte.

## Récupérer l'accès

`admin` est la frontière opérateur de l'hôte. Les moyens ordinaires de changer un mot de passe vivent tous dans l'application (le vôtre depuis l'interface, celui d'un autre par un lien à usage unique émis par un administrateur). La CLI, elle, sert à autre chose : **forcer** un mot de passe sans présenter l'actuel, et émettre un administrateur hors bande. Pour ces deux opérations, il n'existe volontairement aucune route HTTP — il n'y a rien à présenter —, et elles reviennent donc à celui qui a accès à l'hôte.

```bash
docker compose exec notarium admin list
docker compose exec notarium admin create-admin <user> --random
```

La liste complète des commandes et le sens de chacune : [Authentification](/docs/self-hosting/authentication/#récupérer-laccès).

## Ensuite

- [Sauvegarde et restauration](/docs/self-hosting/backup/) — le runbook derrière `backup`, `backup verify` et `restore`.
- [Authentification](/docs/self-hosting/authentication/) — ce que sait faire `admin` et quand il devient nécessaire.
- [Installation](/docs/self-hosting/install/) — lancer l'image et le volume de données.