Revisies

Elke keer dat het compose-bestand, de variabelen, de instellingen, de toegangslijst of de git-bron van een stack worden opgeslagen, bewaart de server een revisie: een kopie van de definitie met wie de wijziging maakte, via welke weg (portaal, API, assistent, webhook) en wanneer. Het maakt niet uit of u klikt of uw assistent het doet.

Lezen

Op het tabblad Revisions staan de revisies, nieuwste eerst.

• Current is de nieuwste definitie: wat de volgende Deploy zou uitrollen.
• Deployed is de revisie die op dit moment draait. Zijn Current en Deployed niet dezelfde, dan toont het tabblad Overview “Changed since the last deploy”.
• Show changes toont het verschil van een revisie met de vorige, per bestand.

Terugzetten

Restore zet de bestanden van een oudere revisie terug als een nieuwe revisie. Er gaat nooit iets verloren: de versie die u verving, blijft in de lijst staan. De containers blijven ongemoeid tot u op Deploy drukt; Restore and deploy doet beide in één keer.

Een oude revisie die de platformregels van vandaag breekt, kan niet worden teruggezet; het portaal zegt dan welke regel.

Wat niet in een revisie zit

De data van de applicatie (de database, geüploade bestanden in volumes) is geen onderdeel van een revisie. Daarvoor zijn de back-ups. Een revisie terugzetten verandert dus de configuratie, niet de inhoud van de database.

Bewaartermijn

De server bewaart de laatste 50 revisies per stack; de revisie die draait wordt nooit opgeruimd. Een stack die bestond voordat revisies werden bijgehouden, kreeg bij zijn eerste wijziging een revisie “Existing state” als beginpunt.

Via API en assistent

Schrijfacties via de API en de MCP-server sturen het revisienummer mee waarop ze zijn gebaseerd. Is de stack intussen door iemand anders gewijzigd, dan wordt de schrijfactie geweigerd (412) en moet de aanroeper eerst opnieuw lezen. Zo overschrijven twee mensen (of een mens en een assistent) elkaar nooit ongemerkt.