aYOUne

Upgrades

aYOUne folgt Calendar-Versioning (2026.x.y) und liefert wöchentlich Patches. Self-Hosted-Instanzen bleiben am besten aktuell — Upgrades sind in der Regel zero-downtime, gelegentlich gibt es eine Schema-Migration.

Versions-Strategie

Bestandteil Tempo Beispiel
Patches (2026.x.y) wöchentlich 2026.50.1 → 2026.50.2
Iterationen (2026.x) monatlich 2026.50 → 2026.51
Major-Bumps selten (sehr selten — Plattform ist stabil)

Vor jedem Upgrade lies die Release Notes für deine Spanne.

Compose-Upgrade

ay self-host-update             # interaktiv
ay self-host-update --to 2026.51.0 --backup-first

Was passiert:

  1. Pre-Check — Plattform-Health, License gültig, Disk-Space?
  2. Backup — MongoDB-Dump + Storage-Snapshot
  3. Pull — neue Images (docker compose pull)
  4. Migrate — Schema-Migrations laufen via ay-migration-Container
  5. Restart — Rolling-Restart der Services
  6. Verify — Health-Probes grün?

Bei Fehler im Verify-Step rollt das Tool nicht automatisch zurück, sondern lässt dich entscheiden. Für automatischen Rollback nutze K8s + helm --atomic.

Helm-Upgrade

helm repo update tolinax
helm upgrade --install ayoune \
  tolinax/umbrella \
  --version 2026.51.0 \
  --namespace develop \
  --reuse-values \
  --atomic --wait --timeout 10m

Tipp: Bei umfangreichen Setups Module einzeln upgraden, nicht alle gleichzeitig — schneller und sicherer Rollback bei Fehler.

Schema-Migrations

Größere Änderungen (z.B. Atlas-Index, Collection-Rename, Field-Migration) leben in ayoune-migration. Der Container läuft im Vorfeld:

docker run --rm \
  -e MONGO_URL=$MONGO_URL \
  ghcr.io/tolinax/ayoune-migration:2026.51.0 \
  migrate up --to 2026.51.0

Migrations sind idempotent und nutzen Checksum-Caching — eine bereits gelaufene Migration wird übersprungen. Im K8s-Setup ist das ein Init-Container (umbrella Chart hat ihn eingebaut).

Staged Rollout

Empfohlene Reihenfolge:

  1. Staging zuerst (eigener Namespace / kleinerer Compose-Stack)
  2. Smoke-Test: Login, ein paar CRUDs, Mail-Versand
  3. Production mit --atomic

Best Practice: zwischen Staging und Production mind. 24h liegen, damit Audit-Logs einen Tag voll sind.

Zwischen-Versionen überspringen

Pfad Methode
2026.50.x → 2026.51.x direkt — Patches sind kompatibel
2026.45 → 2026.51 direkt — Iterationen sind aufwärtskompatibel
< 2026.30 → 2026.50+ gestuft — siehe Migration Guide

Sehr alte Versionen (vor 2026.30) brauchen einen Zwischen-Stop, weil zwischen interfaces/models/core große Sprünge liegen.

Rollback

ay self-host-update rollback     # nutzt das letzte automatische Backup
ay self-host-update --to 2026.50.0    # explizit

Bei K8s:

helm rollback ayoune <revision>

Achtung: Rollbacks reverten Code, nicht Daten. Wenn die neue Version Schema-Migrations gefahren hat, brauchst du das Backup aus Schritt 2.

Siehe auch: Troubleshooting, Breaking Changes.