
# Commandes de cycle de vie

Quatre commandes lancent et pilotent un serveur. `stop`, `restart` et `reload` retrouvent tous le processus en cours via un **fichier de verrou** écrit au démarrage, qui enregistre son PID, son port et son chemin de configuration — c'est pourquoi aucune d'elles n'a besoin que vous nommiez à nouveau la configuration.

## `sovrium start`

Démarre le serveur. C'est la commande par défaut : le mot `start` est donc optionnel dès qu'un chemin de configuration est présent.

```bash
sovrium start app.yaml          # explicite
sovrium app.yaml                # implicite — identique
sovrium start app.yaml --watch  # recharge à chaque modification

PORT=8080 sovrium start app.yaml
```

Le port provient de `PORT` et vaut `3000` par défaut. Si ce port est déjà pris, Sovrium n'échoue **pas** : il se lie à un port libre attribué par le système et affiche la vraie URL dans la bannière de démarrage.

```text
[SERVER] Port 3000 in use; using an OS-assigned port (see URL below).
```

Démarrer alors qu'une autre instance détient le verrou est refusé :

```text
Error: Server already running (PID: 12345, port: 3000)
```

Un verrou laissé par un processus planté est détecté (son PID n'existe plus) et supprimé automatiquement : ce message ne vous bloque donc que si une instance tourne réellement.

## `sovrium stop`

Envoie `SIGTERM` au processus nommé dans le fichier de verrou, puis supprime le verrou.

```bash
sovrium stop
```

Affiche `Server stopped successfully`. Sans fichier de verrou, la commande sort en `1` avec `Error: No server is running (lock file not found)`.

## `sovrium restart`

Arrête le serveur en cours, puis le relance détaché en arrière-plan. Le chemin de configuration est optionnel : sans lui, celui enregistré dans le fichier de verrou est réutilisé.

```bash
sovrium restart          # même configuration que l'instance en cours
sovrium restart app.yaml # bascule vers une autre configuration
```

`restart` remplace intégralement le processus : le port est réattribué et les connexions sont coupées. Préférez `reload` lorsque seule la configuration a changé.

## `sovrium reload`

Relit la configuration d'un serveur en cours **sans interruption**. Sovrium valide d'abord le fichier et ne signale le processus qu'une fois le décodage propre : une modification invalide est donc rejetée avant de pouvoir atteindre le serveur en production.

```bash
sovrium reload
sovrium reload --message "Ajout de la table factures"
```

`--message` enregistre une note d'exploitation sur la nouvelle version de configuration, qui apparaît ensuite dans l'historique de migration de l'application.

Comme la configuration existe uniquement sous forme de code, aucun schéma modifié à l'exécution ne peut entrer en conflit avec un rechargement : le fichier sur disque fait toujours foi. Un fichier invalide interrompt le rechargement avec :

```text
Error: Invalid configuration - <le chemin fautif et la raison>
```

:::callout
**`reload` change la configuration, pas le code.** Une nouvelle version de Sovrium exige toujours un `restart` (ou un redéploiement). `reload` relit votre `app.yaml` ; il ne remplace pas le binaire.
:::

## Pages associées

- [Aperçu du CLI](/fr/docs/cli) — résolution de configuration et mode surveillance.
- [Commandes de projet](/fr/docs/cli-project) — `init`, `build`, `schema`, `validate`.
- [Métadonnées de l'application](/fr/docs/app-metadata) — l'historique de migration alimenté par `reload`.
- [Dépannage](/fr/docs/troubleshooting) — conflits de port et erreurs de fichier de verrou.
