Skip to content
Stackship documentation Svenska

App ServiceUsers

App Service

Run web applications and APIs built from your repository or from a container image, each with its own hostname, scaling and deployment history.

App Service runs web applications and APIs. You point an app at a branch of a repository — or at a ready-made container image — and the platform builds the image, runs it, routes a hostname to it and records every deployment. In the portal at https://portal.example.com apps are under App Service in the sidebar.

What an app is

  • An app lives in a resource group of a boundary and runs on one of the boundary's clusters. Its name is unique in the resource group and cannot be changed.
  • It runs one container image as one or more identical instances, behind one hostname.
  • It serves HTTP on one port, the app's Port. An instance counts as ready only once that port accepts connections, so an app that never opens it never becomes Running.
  • It can have slots: copies of the app that run other branches of the same repository, each with its own hostname — see Deployment slots.

Where the code comes from

Source What the platform does
GitHub, GitLab, Azure DevOps Builds the image from a repository and branch that a deployment source connected to the boundary can reach. A push to the branch builds and deploys again — see Automatic deployments.
Container Runs an image, registry/name:tag or registry/name@sha256:…, that the cluster can pull without credentials from you: a public image, or an image the platform built for an app or function of the same boundary. The image is pulled every time an instance starts, so a tag that was pushed again is picked up on the next restart or deploy. An app cannot be given credentials for a registry of your own.

Caution

Anyone who may create or change an app can run, in a resource group where they may, any image the platform built for an app or function of the same boundary — including one from a resource group they cannot see. Such an image holds that app's code, and the values of any build variables built into it.

How an app is built

For an app built from a repository, the platform builds the image inside the cluster from a template for the app's runtime stack. The version you pick is the version of the build's base images.

Runtime The build What the container runs
Node Installs the dependencies with the package manager the lockfile names — pnpm, Yarn, Bun or npm (npm when there is no lockfile) — and runs the build script if there is one The start script. Without one, the build output is served as a static site with SPA fallback: an index.html under dist/, build/, out/, .output/public/ or _site/. With neither, the build fails.
Python pip install -r requirements.txt; without a requirements.txt the build fails python app.py
.NET dotnet publish of the startup project The published assembly named after the startup project file (MyApp.csproj runs MyApp.dll); without a startup project path, app.dll
Java mvn package -DskipTests (Maven) java -jar on the one executable jar — a jar with a Main-Class — that the build produces
PHP composer install --no-dev when there is a composer.json Apache, serving the files of the repository
  • The build runs at the root of the repository, which is where it looks for package.json, requirements.txt, pom.xml and composer.json. A .NET startup project path is relative to the root too.
  • If the repository has .stackship/pre-build.sh or .stackship/post-build.sh, the build runs them before and after its build step; for Python, both run after pip install.
  • Environment variables you mark as build variables are also passed to the build — see Environment variables and secrets.
  • The image tells your code which port to listen on: PORT (Node, Python and PHP), PORT and SERVER_PORT (Java), or ASPNETCORE_HTTP_PORTS (.NET), set to the app's port.

Caution

A PHP app serves every file of the repository at the branch's commit, including .git, .stackship and dot files such as .env: anyone who can reach the app can download them, and the source of its PHP files with them through .git. Keep what must not be public out of a PHP app's repository.

Runtime stacks

A new installation offers Node 18, 20 and 22; Python 3.9 to 3.13; .NET 8.0 and 10.0; Java 8, 11, 17 and 21; and PHP 8.1 to 8.4. Your platform administrator can withdraw versions. The portal marks a version that is past its end of life with (EOL), and one that reaches it within about six months with its end-of-life date. An app keeps running on a version that is no longer offered, and stays editable on it.

What an app runs on

A compute plan is a CPU and memory size — both the guaranteed amount and the ceiling for each instance — plus a disk size that is only used when the app has persistent storage. A new installation has these plans; the portal lists the ones yours offers:

Plan CPU Memory Disk
nano 0.1 128 MiB 500 MiB
small 0.25 256 MiB 1 GiB
medium 0.5 512 MiB 2 GiB
standard 1 1 GiB 3 GiB
large 2 2 GiB 5 GiB
xlarge 4 4 GiB 10 GiB
2xlarge 8 8 GiB 20 GiB

A boundary can have a policy that allows only some plans. The portal shows the others disabled, marked Not permitted by this boundary's compute plan policy, and the platform refuses them.

What every app gets

What apps do not have

An app has no terminal and no view of individual containers. To look inside a running app, use its logs and, when it has persistent storage, its files.

Pages