Explain podman-compose down/up needed after config changes to existing container

Co-authored-by: Junie <junie@jetbrains.com>
This commit is contained in:
2026-07-25 23:00:40 +02:00
co-authored by Junie
parent 11b77a6994
commit 3ec22f4b9e
2 changed files with 30 additions and 0 deletions
@@ -82,6 +82,24 @@ onder een eigen `umami`-user te draaien in plaats van je eigen hoofdaccount:
```
Dit zou een JSON-antwoord met `"ok"` moeten teruggeven.
> **Let op — na een wijziging aan `podman-compose.yml`/`.env` (bv. een andere poort):**
> `podman-compose up -d` update alléén containers waarvan de configuratie is gewijzigd,
> maar een poortmapping (`ports:`) wordt door Podman **niet** live herladen op een
> bestaande, al aangemaakte container. Heb je `podman-compose up -d` al eerder gedraaid
> met een oude versie van `podman-compose.yml` (bv. met poort `3000` in plaats van
> `3001`), werk dan eerst je lokale `~/umami/podman-compose.yml` bij met de nieuwste
> versie uit dit repository, en draai daarna:
> ```bash
> cd ~/umami
> podman-compose down
> podman-compose up -d
> ```
> `podman-compose down` verwijdert de containers (niet de database-data, die staat in
> een persistent volume) en `up -d` maakt ze opnieuw aan met de bijgewerkte poort/config.
> Dit is enkel nodig als de container al bestond met de oude configuratie; bij een
> eerste, nieuwe `up -d` (of als de vorige poging überhaupt nooit is gestart doordat
> Podman de poort niet kon claimen) is dit niet nodig.
## 2. Automatisch starten na reboot (systemd user service)
Podman-compose start niet vanzelf op na een herstart van de Pi, tenzij je dit expliciet
instelt. Omdat rootless Podman hier al gebruikt wordt, is een systemd **user**-service —