Updates & Versionen

Aktualisiert werden zwei Dinge: Envoryx selbst und die Runtime-Images, auf denen deine Projekte laufen. Beides ist voneinander unabhängig, und beides lässt sich zurückdrehen.

Envoryx aktualisieren

Einmal am Tag fragt Envoryx bei GitHub nach, ob es ein neueres Release gibt, und sagt es dir auf dem Dashboard und unter Einstellungen → Allgemein (ENVORYX_UPDATE_CHECK=false schaltet das ab). Das Update selbst geht schnell:

# Docker Compose, im Ordner der compose.yml
docker compose pull && docker compose up -d

# docker run: neues Image, dann derselbe docker-run-Befehl wie vorher
docker pull ghcr.io/envoryx/envoryx:latest && docker rm -f envoryx

Unter Unraid nimmst du auf der Docker-Seite Check for updates / Apply update.

Nervös musst du dabei nicht sein. Alles, was Envoryx weiß, liegt in /config, /projects und /backups - ein Image-Tausch rührt deine Projekte also nicht an, ihre Container laufen während des Updates sogar weiter. Baut eine neue Version ihre Datenbank um, passiert das automatisch und nur vorwärts, und direkt vor der ersten Änderung schreibt Envoryx ein Instanz-Backup (pre-migrate-…). Was neu ist, steht im Changelog.

Manchmal richtet eine neue Version Container etwas anders ein, etwa mit einer zusätzlichen Variable oder einem Mount. Laufende Container baut Envoryx deshalb nicht von selbst neu. Stattdessen zeigen Dashboard und Projekt „Der php-Container läuft noch mit einer älteren Einrichtung; starte das Projekt neu, um ihn zu aktualisieren“, und ein Neustart bringt den Container auf den neuen Stand, wann es dir passt. Nach dem Update auf 0.17.0 siehst du das einmal für jeden laufenden Container, weil jetzt auch die Umgebungsvariablen zählen. Nach 0.18.0 sind es noch einmal die Ruby-Container, die zwei neue Datenbankvariablen bekommen (CACHE_DATABASE_URL und CABLE_DATABASE_URL). Das neue Instanz-Label dagegen macht keinen Container zu einem veralteten. 0.18.1 und 0.19.0 ändern die PostgreSQL-URL jeder Runtime außer PHP, die Webserver-Konfiguration und die php.ini von PHP-Projekten und die Umgebung des Node.js-Containers. Starte deine laufenden Projekte nach dem Update auf diese Versionen also einmal neu.

Verwaltet ein Hoster deine Instanz, kann auch sein Fleet Manager sie aktualisieren; wie das geht und was passiert, wenn eine neue Version nicht hochkommt, steht unter Verwaltete Instanzen.

Image-Tags

Tag	Was
`:latest`	das neueste Release
`:<version>`, z. B. `:0.12.0`	ein festes Release
`:main`	der Entwicklungszweig - jeder Push, kann kaputt sein

Zurückgehen

Die neue Version gefällt dir nicht? Hat sie das Datenbankschema nicht geändert, startest du einfach wieder das alte Image. Hat sie es geändert, verweigert das alte Image den Start, und seine Fehlermeldung nennt das pre-migrate-Backup von direkt vor der Migration. Das spielst du bei gestopptem Container von Hand ein und startest dann das alte Image. Über die Oberfläche der neuen Version klappt das nicht, weil der nächste Start das Backup wieder migrieren würde.

Runtime-Images

Deine Projekte laufen nicht direkt auf den offiziellen Images, sondern auf den Runtime-Images von Envoryx - envoryx-php, envoryx-node, envoryx-python, envoryx-go, envoryx-ruby, envoryx-java und envoryx-dotnet -, die aus den offiziellen gebaut werden.

Patch-Releases (etwa 8.5.3 → 8.5.4) kommen über den wöchentlichen Neubau dieser Images. Hinter deinem Rücken ändert sich trotzdem nichts: Ein Projekt übernimmt ein neu gebautes Image erst, wenn du es mit Neustart neu startest. Der Neustart zieht den Tag erneut und erstellt den Container nur neu, wenn sich das Image wirklich geändert hat; bis dahin läuft das Projekt auf dem Build, den es hat. Starten übernimmt einen neueren Build, der schon auf dem Host liegt, fragt aber nicht die Registry, und andere Änderungen (ein Worker, eine Variable) tauschen nie Images aus. Sie starten deine Datenbank also nicht nebenbei neu.

Die Ausnahme sind neue Dinge: Ein neues Projekt, eine neue Runtime-Version oder ein neu hinzugefügter Dienst holen sofort das aktuelle Image, damit du nie etwas Neues auf einem veralteten Build startest. Offline tut es das lokale Image.

Macht ein neu gebautes Image Ärger, gehst du zurück. Nach einem Neustart, der ein Image ausgetauscht hat, zeigt die Übersicht des Projekts Image aktualisiert mit einem Knopf Zurücksetzen. Der erstellt die Container aus dem Image, auf dem sie vorher liefen - bei MariaDB, Caddy und jedem anderen Image genauso. Ein zurückgerolltes Projekt bleibt auf diesem Image, bis du Aktuelles Image verwenden wählst.

Neue Versionen (PHP 8.6, Ruby 4.1 …) findet eine wöchentliche Prüfung gegen endoflife.date und Docker Hub, und das nächste Envoryx-Release bietet sie im Assistenten an. Vorabversionen sind als preview markiert, Versionen nach Supportende als EOL. Die Runtime-Version eines Projekts änderst du in seinem Bereich Laufzeit.