Manage a static web app

Open Static Web Apps in the sidebar and choose the site. The header shows its status and the actions Browse (while the site is Running or Degraded), Deploy, and Stop or Start. The Configuration tab is shown to people who may change the site.

Deploy

Deploy packages the site again from its source — the commit of the last push the platform received for the branch, or the head of the branch when it has received none — and rolls it out. It needs staticwebapp/deploy. Deploying a stopped site packages it; the new deployment serves once you start the site.

You rarely need the button: a push to the site's branch deploys it — see Automatic deployments.

Follow deployments

The Deployments tab lists the site's deployments, newest first, with their Phase, Message, Source (repository, branch and commit, linked to the commit) and when they Started. Current marks the deployment the site last packaged successfully. After Serve this deployment it stays on that row; Serving on the Overview tab names the image the site actually serves. You can search the list and filter it by phase; the phases are explained in Statuses.

Choose a row to open its Deploy logs: the output of packaging the site, streamed while it runs and kept after it finishes, together with the deployment's Image and source. When a deployment fails, this is where the reason is — for example a directory to serve without index.html. Reading deploy logs needs staticwebapp/readLogs.

Serve an earlier deployment

To go back to what the site served before without building anything:

1. On the Deployments tab, choose Serve this deployment on a completed deployment, or open its deploy logs and choose the button there.
2. Confirm with Serve deployment.

The site switches to that deployment's image within moments. While it does, Serving on the Overview tab names the image instead of saying Latest deploy from branch. The site keeps serving it until you choose Deploy, change the source or the directory to serve, or a push to the branch arrives — each of these deploys the source again.

Only images this site built are accepted, and not the one it already serves. The platform's registry cleanup does not remove static web app images, so earlier deployments stay available to serve. This needs staticwebapp/deploy.

Change the source

Configuration → Deployment Source holds the Source type, the installation, the Repository and the Branch. Saving deploys the site from the new source, and ends serving an earlier deployment. Changing the repository needs access to the boundary's deployment sources; without it you can still change the branch.

Warning

Once the site has received a push, it keeps that push's commit when you change the branch or the repository here. The next deployment packages that commit rather than the new branch, or fails when the new repository does not have it. Push a commit to the new branch to deploy it.

Change the directory to serve

Configuration → Content → Directory to serve names the folder that holds index.html. Saving packages the site again from that directory, and ends serving an earlier deployment.

Change routing

Configuration → Routing holds Single-page app fallback (the file to serve for paths that match no file, such as /index.html; empty returns 404 instead), 404 page and Caching. Changes apply within seconds; the site is not packaged again. The settings are described in Routing and caching.

A fallback or 404 page that names a file the deployed site does not have does not take effect: the site keeps serving with its previous routing and shows Degraded until you correct the path or deploy a site that has the file.

Use a custom domain

1. Create a DNS record that points the domain at the platform. For a name such as www.example.com, a CNAME record to the site's platform address does this.
2. On Configuration → Networking & Security, enter the domain as Custom domain and save.
3. Watch Certificate next to it. It shows Being issued until the domain resolves to the platform and Let's Encrypt has issued the certificate, then Issued.

The platform address keeps working the whole time, and the site keeps answering on it. A site has one custom domain: saving a different one stops serving the previous one at once. Clear the field to serve the site on its platform address only.

A domain that another resource already serves is refused with a message saying so. Your installation can also be set up to refuse domains outside its own.

Stop and start

Stop takes the site offline on every address it serves, after you confirm; it sets the site's replicas to 0 and remembers how many there were. Start brings back that number. Both need staticwebapp/write.

Creating a site with Replicas set to 0 is the same as creating it stopped; Start then runs it with one replica. To change the number of replicas of a running site, use the CLI — stsh swa scale needs staticwebapp/scale, and stsh swa update with --set replicas=3 needs staticwebapp/write:

stsh swa scale my-site -g my-resource-group --replicas 3

Read the web server's logs

The Logs tab streams the web server's log from the site's serving pods, starting with the last 500 lines; Pod narrows it to one pod. It needs staticwebapp/readLogs.

Delete the site

On the Danger Zone tab, choose Delete and type the site's name to confirm. This needs staticwebapp/delete. The site stops answering on all its addresses.

With the CLI

stsh swa get my-site -g my-resource-group
stsh swa deploy my-site -g my-resource-group
stsh swa rollback my-site -g my-resource-group --image <image>
stsh swa stop my-site -g my-resource-group
stsh swa start my-site -g my-resource-group

stsh swa rollback is Serve this deployment: take the image from a deployment's deploy logs, or from currentDeployment.image and lastDeployment.image in stsh swa get my-site -o json. stsh swa update changes settings with --set field=value, including the redirects and response headers the portal does not edit — see Redirects and response headers.