App ServiceAdministrators

Runtime versions and compute plans

Withdraw or add the runtime versions apps can be built with, change the compute plans, and find the storage and image-retention settings.

The runtime versions apps can be built with, and the compute plans they can run on, are rows in the Apps module's tables in the platform database, schema apps. There is no page in the portal and no API to change them: you change the rows. The Apps module connects to that database with the connection string in the Secret stackship-db-credentials (key connection-string) in stackship-system.

Runtime versions

The table apps.app_runtimes holds one row per runtime version:

Column	Holds
`name`	The name the portal shows, such as `Node`
`runtime`	`node`, `python`, `dotnet`, `java` or `php`
`version`	The version, such as `22`
`enabled`	Whether the version is offered
`end_of_life_date`	The date the portal counts down to; it marks a version from about six months before it

The portal offers the enabled versions, and the platform accepts only those for a new app or a change of version. An app already on a disabled version keeps it and can still be edited.

Withdraw a version

sql

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

Disable a version rather than delete its row. Every time the Apps module starts, it adds, enabled, each version it ships with that has no row — Node 18, 20 and 22; Python 3.9 to 3.13; .NET 8.0 and 10.0; Java 8, 11, 17 and 21; PHP 8.1 to 8.4 — and leaves existing rows as they are.

Add a 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());

The version is used as the tag of the build's base images, so they must exist for it:

Runtime	Base images
`node`	`node:<version>-alpine`
`python`	`python:<version>-slim`
`dotnet`	`mcr.microsoft.com/dotnet/sdk:<version>` and `mcr.microsoft.com/dotnet/aspnet:<version>-alpine`
`java`	`maven:3-eclipse-temurin-<version>` and `eclipse-temurin:<version>-jre`
`php`	`php:<version>-cli` and `php:<version>-apache`

Compute plans

The table apps.app_compute_plans holds the plans. The Apps module fills it with the plans nano to 2xlarge only when it is empty, so your changes stay.

Column	Holds
`name`	The plan's name; unique
`description`	The text the portal shows with it
`cpu`	CPU in millicores, the request and the limit of each instance
`ram`	Memory in MiB, the request and the limit of each instance
`storage`	The disk size in MiB, used when an app turns on persistent storage
`storage_type`	`0` Standard or `1` Premium — which storage class the disk gets
`price_per_month`	A price; the portal does not show it

An app stores its plan by name, and the plan's CPU and memory are copied into the app whenever the app is saved. A changed plan therefore reaches an app the next time the app is saved. Do not rename or delete a plan that apps use: saving such an app fails with Compute plan '<name>' not found.

Which plans a boundary may use is decided by its compute plan policies, not here.

Storage classes

An app's disk gets the storage class set for its plan's storage type in the Apps module's settings, Compute__Storage__Classes__Standard and Compute__Storage__Classes__Premium (Standard Storage Class and Premium Storage Class in the installer). A disk keeps the class and the size it was created with.

Image retention

How long the images built for apps are kept is set on the Container Registry module — see Container Registry. Its settings Registry__Retention__DefaultKeepLast (default 2) and Registry__Retention__DefaultKeepForDays (default 90) are the defaults an app without its own retention gets, and the clean-up runs daily at 03:00 UTC.

Important

Today the clean-up deletes no app images, whatever these settings and an app's retention say. Every image built for an app stays in the registry, so the registry's storage grows with every build; plan its capacity accordingly.