Deploy a static site

A dist folder full of files, and no machine to provision. A Storage Account serves a static site on its own, over HTTPS, with nothing to manage.

This is the right scenario if

The question	The answer that puts you here
What are you serving?	Files that are already built: HTML, CSS, JavaScript, images. The build of a React, Vue, Angular or Astro project, or hand-written HTML.
Does any code run server-side?	No. No server rendering, no API routes, no background jobs.
Do you need your own domain name?	No. The URL provided by Azure is enough.
A database?	No, or it lives elsewhere and the site calls it over HTTPS.

A single answer that tips the other way, and you’re in the other scenario: deploy an application and its database.

Prerequisites

A Resource Group created with its tags and a declared lab. If not: create my Azure lab. The Storage Account is created in that Resource Group.

A Storage Account name is unique across all of Azure, not just within our tenant. 3 to 24 characters, lowercase letters and digits only, no hyphens or dots. Use stlab followed by your trigram and the purpose.

The deployment

Azure portal

1. In the Azure portal, create a Storage account resource in your Resource Group and in the lab’s region. Keep Performance: Standard and choose Redundancy: LRS, the cheapest replication and the only one that makes sense for a lab.

2. Fill in the tags before validating: owner, projectName and creationDate, without which creation is refused, then expirationDate, which doesn’t block but is audited.

3. Open Data management then Static website, and switch the setting to Enabled.

4. Set Index document name to index.html. For Error document path, use 404.html if your site has a real error page, or index.html if it’s a single-page application with client-side routing. Save.

5. Azure displays the Primary endpoint and creates a $web container. Copy that URL: it’s your site’s address. Don’t guess it, it contains a region identifier.

6. Open the $web container and upload the contents of your build folder, keeping the folder structure. index.html must sit at the root of the container, not in a subfolder.

7. Open the Primary endpoint in a browser. Your site is live.

Azure CLI

After az login, replacing the four values at the top with your own.

RG="rg-qro"
ACCOUNT="stlabqrodemo01"     # 3 to 24 characters, lowercase and digits, unique in Azure
REGION="switzerlandnorth"
BUILD="./dist"               # the folder produced by your build

# Create the storage account
az storage account create \
  --name "$ACCOUNT" \
  --resource-group "$RG" \
  --location "$REGION" \
  --sku Standard_LRS \
  --kind StorageV2 \
  --tags owner=qro projectName=demo-front creationDate=21.08.2026 expirationDate=21.11.2026

# Udpate storage account to host website
az storage blob service-properties update \
  --account-name "$ACCOUNT" \
  --static-website \
  --index-document index.html \
  --404-document index.html

# Upload `$BUILD` folder documents in storage account
az storage blob upload-batch \
  --account-name "$ACCOUNT" \
  --source "$BUILD" \
  --destination '$web' \
  --overwrite

# Display the storage account website URL
az storage account show \
  --name "$ACCOUNT" \
  --resource-group "$RG" \
  --query "primaryEndpoints.web" \
  --output tsv

The last command prints the site’s URL. The first three can be replayed as is if you start over. The upload command is replayed after every new build.

What catches you out on the first deployment

The symptom	What’s going on
An internal route returns a 404	A single-page application routes in the browser, but the Storage Account looks for an actual file. Set Error document path to index.html.
The site still shows the old version	Browser cache. Do a hard reload, or set a Cache-Control header on the files your build versions.
A blank page and path errors	The build expects to be served from the root. Check that index.html is at the root of $web.
$web is nowhere to be found	It’s only created when the static website is enabled. Go back through Static website.

Everything you put in `$web` is public

The web endpoint serves the $web container to anyone who has the URL, with no authentication. So no .env file, no API key, no token, no data export in the build. A lab URL isn’t secret: it ends up in an e-mail or a browser history.

Auto-shutdown applies only to VMs. A Storage Account bills for as long as it exists. It’s very little for a static site, but it isn’t zero, and it lasts until the Resource Group is deleted.

At the end of the lab

The Resource Group is deleted at the expiry date by the lab administrators, taking the Storage Account and the site with it. If you no longer need it before then, delete it right away: see lifecycle, extension and closure. Keep what matters, build and configuration, since no backup is guaranteed.

With a domain name?

Serving the same site behind a Qim info domain name takes other resources and settings that aren’t self-service. Write to lab@qiminfo.ch describing what you need.