App ServiceAdministratörerMaskinöversatt

Körmiljöversioner och beräkningsplaner

Dra tillbaka eller lägg till de körmiljöversioner som appar kan byggas med, ändra beräkningsplanerna, och hitta inställningarna för lagring och kvarhållning av avbilder.

De körmiljöversioner som appar kan byggas med, och de beräkningsplaner de kan köras på, är rader i Apps-modulens tabeller i plattformsdatabasen, schemat apps. Det finns ingen sida i portalen och inget API för att ändra dem: du ändrar raderna. Apps-modulen ansluter till databasen med anslutningssträngen i Secret stackship-db-credentials (nyckel connection-string) i stackship-system.

Körmiljöversioner

Tabellen apps.app_runtimes har en rad per körmiljöversion:

Kolumn	Innehåller
`name`	Namnet som portalen visar, som `Node`
`runtime`	`node`, `python`, `dotnet`, `java` eller `php`
`version`	Versionen, som `22`
`enabled`	Om versionen erbjuds
`end_of_life_date`	Datumet som portalen räknar ner mot; den märker versionen från ungefär sex månader före

Portalen erbjuder de aktiverade versionerna, och plattformen godtar bara dem för en ny app eller ett versionsbyte. En app som redan har en inaktiverad version behåller den och kan fortfarande redigeras.

Dra tillbaka en version

sql

UPDATE apps.app_runtimes SET enabled = false WHERE runtime = 'node' AND version = '18';

Inaktivera en version i stället för att ta bort dess rad. Varje gång Apps-modulen startar lägger den till, aktiverad, varje version den levereras med som saknar rad — Node 18, 20 och 22; Python 3.9 till 3.13; .NET 8.0 och 10.0; Java 8, 11, 17 och 21; PHP 8.1 till 8.4 — och lämnar befintliga rader som de är.

Lägg till en version

sql

INSERT INTO apps.app_runtimes (id, name, runtime, version, enabled, end_of_life_date, created_utc)
VALUES (gen_random_uuid(), 'Node', 'node', '24', true, '2028-04-30', now());

Versionen används som tagg på byggets basavbilder, så de måste finnas för den:

Körmiljö	Basavbilder
`node`	`node:<version>-alpine`
`python`	`python:<version>-slim`
`dotnet`	`mcr.microsoft.com/dotnet/sdk:<version>` och `mcr.microsoft.com/dotnet/aspnet:<version>-alpine`
`java`	`maven:3-eclipse-temurin-<version>` och `eclipse-temurin:<version>-jre`
`php`	`php:<version>-cli` och `php:<version>-apache`

Beräkningsplaner

Tabellen apps.app_compute_plans innehåller planerna. Apps-modulen fyller den med planerna nano till 2xlarge bara när den är tom, så dina ändringar ligger kvar.

Kolumn	Innehåller
`name`	Planens namn; unikt
`description`	Texten som portalen visar med den
`cpu`	CPU i millikärnor, begäran och gräns för varje instans
`ram`	Minne i MiB, begäran och gräns för varje instans
`storage`	Diskstorleken i MiB, som används när en app slår på beständig lagring
`storage_type`	`0` Standard eller `1` Premium — vilken lagringsklass disken får
`price_per_month`	Ett pris; portalen visar det inte

En app sparar sin plan med namn, och planens CPU och minne kopieras in i appen varje gång appen sparas. En ändrad plan når därför en app nästa gång appen sparas. Byt inte namn på och ta inte bort en plan som appar använder: att spara en sådan app misslyckas med Compute plan '<name>' not found.

Vilka planer en boundary får använda avgörs av dess policyer för beräkningsplaner, inte här.

Lagringsklasser

En apps disk får den lagringsklass som är inställd för planens lagringstyp i Apps-modulens inställningar, Compute__Storage__Classes__Standard och Compute__Storage__Classes__Premium (Standard Storage Class och Premium Storage Class i installationsprogrammet). En disk behåller den klass och storlek den skapades med.

Kvarhållning av avbilder

Hur länge avbilderna som byggs för appar sparas ställs in på modulen Container Registry — se Container Registry. Dess inställningar Registry__Retention__DefaultKeepLast (standard 2) och Registry__Retention__DefaultKeepForDays (standard 90) är de standardvärden som en app utan egen retention får, och städningen körs dagligen klockan 03:00 UTC.

Viktigt

I dag raderar städningen inga appavbilder, oavsett vad de här inställningarna och en apps retention säger. Varje avbild som byggs för en app ligger kvar i registret, så registrets lagring växer med varje bygge; planera dess kapacitet därefter.