Aufräumen

Ein Deployment entfernen

gooddeploy rm k7m2q9xa
gooddeploy rm https://kunde-website--k7m2q9xa.…   # die Preview-Adresse geht auch

gooddeploy zeigt das Deployment und fragt nach. Danach ist es sofort offline; Route und Container baut die Plattform gleich danach ab, und kurz darauf antwortet die Preview-Adresse nicht mehr. Ohne Rückfrage: --yes bzw. -y.

Was sich entfernen lässt:

Achtung bei früheren Live-Versionen: Sie sind die Ziele von gooddeploy rollback. Entfernst du sie, kannst du nicht mehr auf sie zurückschalten. gooddeploy ls markiert sie als „(Rollback-Ziel)“.

Die aktuelle Live-Version lehnt gooddeploy mit DEPLOYMENT_IS_PRODUCTION ab. Willst du sie loswerden, schalte zuerst eine andere Version live (promote bzw. rollback) oder entferne das ganze Projekt.

Eine Live-Adresse (ohne --<id> im Namen) gehört zu keinem einzelnen Deployment; rm lehnt sie ab und nennt dir die passenden Befehle.

Nach der Bestätigung zeigt gooddeploy sofort, dass es arbeitet, wartet, bis Route und Container abgebaut sind, und zeigt am Ende, wie lange das gedauert hat. Meist sind das wenige Sekunden:

✓ Route und Container abgebaut 8,1 s
✓ entfernt: k7m2q9xa (kunde-website)

Brichst du das Warten mit Strg+C ab oder dauert es länger als 5 Minuten, ist das kein Fehler: Das Deployment ist schon offline, das Entfernen läuft auf dem Server weiter, und du musst nichts weiter tun. Meldet gooddeploy „Der Abbau läuft noch im Hintergrund weiter“, gilt dasselbe. Mit --json steht im Ergebnis "state": "removed" bzw., wenn der Abbau noch läuft, "state": "removing" und "cleanupPending": true.

Ein ganzes Projekt entfernen

gooddeploy projects rm kunde-website

Das nimmt das ganze Projekt offline: die Live-Seite, alle Previews und alles, was dazu läuft. Das ist endgültig, du kannst es nicht rückgängig machen, und auch goodDEV kann ein entferntes Projekt nicht wiederherstellen. Deshalb zeigt gooddeploy die betroffenen Live-Adressen und verlangt, dass du den Projektnamen eintippst. Ein einfaches „j“ reicht hier nicht.

In Skripten geht es nur mit beidem zusammen:

gooddeploy projects rm kunde-website --yes --confirm kunde-website

Nach der Bestätigung nimmt gooddeploy das Projekt sofort offline und baut danach Routen und Container ab. Beides siehst du als Schritte, der Abbau kann bei größeren Projekten eine Minute oder länger dauern:

✓ [1/2] Offline genommen 0,4 s
✓ [2/2] Routen und Container abgebaut 48 s
✓ Projekt kunde-website entfernt (3 Deployments offline)

Brichst du das Warten mit Strg+C ab oder dauert es länger als 5 Minuten, ist das kein Fehler: Das Projekt ist schon offline, der Abbau läuft auf dem Server weiter, und du musst nichts weiter tun. In gooddeploy projects ls steht das Projekt dann schon nicht mehr. Mit --json steht im Ergebnis "state": "removed" bzw., wenn der Abbau noch läuft, "state": "removing".

Danach gilt:

• Der Projektname bleibt 30 Tage gesperrt; gooddeploy nennt dir das genaue Datum. Dann werden auch die Datenbanken gelöscht. Ein Zurückholen des Projekts gibt es nicht; sichere vorher, was du noch brauchst.
• Läuft gerade ein Build oder Start, lehnt gooddeploy ab (DEPLOYMENT_IN_PROGRESS). Warte kurz und versuche es erneut.
• Ist der aktuelle Ordner mit genau diesem Projekt verknüpft (.gooddeploy/), entfernt gooddeploy die Verknüpfung gleich mit und meldet ✓ Verknüpfung .gooddeploy/ entfernt (mit --json: "linkRemoved": true). Zeigt sie auf ein anderes Projekt oder ein anderes Team, bleibt sie, wie sie ist. Klappt das Entfernen nicht, bleibt das Projekt trotzdem entfernt; lösche die Verknüpfung dann selbst mit rm -rf .gooddeploy.
• Für projects rm brauchst du auf dem Projekt das Recht admin. Als owner oder admin im Team bekommst du es mit der Anmeldung per E-Mail (siehe Rechte).
• Hat das Projekt eigene Domains, sag goodDEV Bescheid, damit auch sie sauber abgebaut werden.

Automatisches Aufräumen

gooddeploy räumt alte Deployments nach festen Fristen selbst auf, damit nichts liegen bleibt:

Mit dem Ablaufen bzw. Entfernen löscht gooddeploy auch das gebaute Image und den hochgeladenen Stand. Nach gooddeploy rm passiert das 14 Tage später.

Brauchst du eine abgelaufene Preview noch einmal, deploye denselben Stand erneut mit gooddeploy deploy.

Ungenutzte Previews nach einigen Tagen schlafen zu legen und beim ersten Aufruf wieder zu wecken, kommt später.

Grenzen für Previews

Damit Previews den Server nicht überlasten, gelten feste Grenzen:

Für den gemeinsamen Speicher zählt eine Next.js-Preview mit 576 MB (512 MB plus 64 MB für den vorgeschalteten Webserver der Plattform), eine statische Preview nur mit 64 MB. In die 2 GB deines Teams passen also drei Next.js-Previews oder rund 30 statische.

Startet eine neue Preview und eine Grenze wäre überschritten, legt gooddeploy vorher die älteste bereite Preview schlafen: Sie ist offline, ihre Adresse antwortet nicht mehr, Zustand „abgelaufen“. Deine Live-Version ist davon nie betroffen. Brauchst du die alte Preview wieder, deploye ihren Stand erneut.

Dabei gilt diese Reihenfolge:

1. Zuerst trifft es die älteste bereite Preview deines eigenen Teams.
2. Reicht das nicht, die älteste Preview eines anderen Teams, aber nur, wenn dieses Team mehr als seine 2 GB belegt. Umgekehrt gilt dasselbe: Solange dein Team höchstens 2 GB belegt, verdrängt kein anderes Team deine Previews.

deploy sagt dir, welche Preview deines Teams dafür Platz machen musste und warum, z. B.:

⚠ Preview old00001 wurde entfernt, das Projekt hat die höchste Zahl laufender Previews erreicht; die älteste macht Platz.
⚠ Preview old00002 (shop) wurde entfernt, der Speicher für Previews ist voll; die älteste deines Teams macht Platz.

Trifft es eine Preview eines anderen Projekts deines Teams, steht der Projektname in Klammern dahinter. Mit --json stehen dieselben Angaben im Feld removedPreviews des Deployments (je Eintrag shortId, project, reason). Musste eine Preview deines Teams für ein anderes Team Platz machen, weil dein Team über seinen 2 GB lag, hält gooddeploy das als Grund an ihrem Zustandswechsel fest; eine Benachrichtigung dazu kommt später. Namen anderer Teams oder Projekte siehst du nie, und andere Teams sehen deine nicht. Ein Aufwecken mit einem Befehl kommt später.

Ist der Speicher voll und kann nicht genug Platz frei werden (Previews starten gerade, oder die anderen Teams liegen in ihren 2 GB), scheitert der Start mit PLATFORM_UNAVAILABLE, und keine Preview wird dafür schlafen gelegt. Entferne dann Previews deines Teams, die du nicht mehr brauchst (gooddeploy rm <id>), oder deploye in ein paar Minuten erneut.