Create an app
Create an app with the eight-step wizard — placement, runtime, networking, compute plan, scaling, deployment source and environment variables.
Requires: apps/write
Creating an app needs apps/write in the resource group; the Owner, Contributor and Apps
Operator roles have it. To build from a repository you also need a deployment source in the
boundary — see Deployment sources.
Open the wizard
In the portal at https://portal.example.com, open App Service in the sidebar and choose Create Apps. The wizard has eight steps. Next checks the fields of the step you are on; a name that is already taken, and KEDA scaling without a trigger, are refused only when you create the app.
Basic Configuration
- App Service Name — 3 to 50 characters: lowercase letters, digits and hyphens, starting with a letter and not ending with a hyphen. It must be unique in the resource group and cannot be changed later.
- Boundary, Cluster and Resource group — where the app lives. The boundary is the one you are in; the cluster and the resource group are filled in for you when there is only one choice.
Instance Details
- Runtime stack and Version — what the image is built with; see How an app is built. Versions near or past their end of life are marked.
- Port — the port your app listens on, 3000 unless you change it. The platform only sends traffic to an instance once this port accepts connections.
- Startup Project Path — optional. For .NET, the project file to publish, for example
src/MyApp/MyApp.csproj; the image runs the assembly named after it, and without a path it runsapp.dll.
For Node, the step recommends a packageManager field in package.json (for example
"packageManager": "pnpm@10.33.2"), so the build caches that exact version of pnpm or Yarn in the
image.
For a Container source (chosen in step 6) the runtime stack and version are not used, but the wizard still asks for them.
Networking
- Custom Domain Name — optional. A domain of your own to use instead of the generated hostname,
such as
app.example.com. You create its DNS record yourself — see Custom domains and HTTPS. - HTTP Only — serve the app over plain HTTP, without a certificate. Turning it on turns Let's Encrypt SSL off.
- Let's Encrypt SSL — on by default: the platform requests a certificate for the app's hostnames and renews it. Off, HTTPS is answered with a self-signed certificate that browsers warn about, and depending on the platform the app also answers plain HTTP without sending visitors to HTTPS — see HTTPS.
A domain that another resource in the cluster already uses is refused when you create the app — see Hostnames already in use.
Compute Plan
Pick a plan. Each card shows its CPU, memory and disk size and a short description; standard is selected to begin with. Plans that a policy on the boundary does not allow are disabled — see What an app runs on.
The disk is only used if you later turn on persistent storage; the wizard does not offer it. See Runtime and compute.
Scaling
- Manual — a fixed Number of Replicas, 1 to 20 (default 1).
- Horizontal Pod Autoscaler — Minimum Replicas and Maximum Replicas and a CPU Target (%); defaults 1 to 5 at 70 %.
- KEDA (Event-driven) — minimum (0 allows scale to zero) and maximum replicas, defaults 1 to 10, and at least one trigger.
What each option does is on Scaling.
Deployment Source
Choose the Deployment Source Type:
GitHub, GitLab or Azure DevOps — pick the installation (GitHub Installation and so on: a deployment source connected to the boundary), then the Repository and the Branch. Connect Deployment Source adds a source without leaving the wizard; connecting GitLab or Azure DevOps with an OAuth application leaves the page, so connect those from the boundary first — see Add a source.
Once a branch is chosen, the wizard reads
package.jsonat the root of that branch and says what the first build will do: run thestartscript, or serve the build output as a static site. It warns when there is nopackage.json, or when there is neither astartnor abuildscript.Container — the full image reference,
registry/name:tagorregistry/name@sha256:…, for exampleghcr.io/your-org/your-app:v1.2.3. The cluster pulls it without credentials from you — see Where the code comes from.
Pushes to the branch deploy the app again automatically — see Automatic deployments. You can change the source later — see Deployment source.
App Settings
Add environment variables as keys and values, one at a time or with Bulk Edit, or upload a
.env file with Upload .env (it replaces what you have entered). A key is 2 to 100
characters, starts with a letter or underscore and contains only letters, digits and underscores;
a value is at most 500 characters.
Turn on Build variable for a setting that the build needs as well, such as VITE_API_URL. When
the wizard has detected the framework from package.json, settings with that framework's public
prefix (for example VITE_ or NEXT_PUBLIC_) are marked for you. At most 32 settings can be build
variables. See Build variables.
Secrets are not added here: add them after the app is created, under Configuration → Secrets — see Secrets.
Review & Create
Check the summary and create the app. You return to the app list while the first deployment runs; for an app built from a repository that starts with a build, which can take several minutes. The app shows Creating until its first instance is ready and then Running — see Statuses.
An app gets a managed identity when it is created. It starts with no access; to let the app read secrets from a vault, give the identity Secrets Reader on the vault — see Give a workload access.
With the CLI
stsh apps create sends the app as JSON — the same body the API takes. An app that runs a public
container image:
{
"computePlan": "small",
"properties": {
"port": 8080,
"letsEncrypt": true,
"scm": { "type": "Container", "image": "ghcr.io/your-org/your-app:v1.2.3" }
}
}stsh apps create my-app -g my-resource-group -c my-cluster --file my-app.json-c names the cluster the app runs on, which the platform requires. The command waits for the
app's create operation to finish; --no-wait returns at once. An app
built from GitHub, GitLab or Azure DevOps also needs the installation and repository IDs of its
deployment source, which the portal wizard looks up for you.