Going Live: Deploying Your Hand-Coded CV to Azure

Part 5 of 6 in the series “Hand-Code Your CV: From Empty Folder to Live on Azure”

In Part 4 we compared the ways of hosting a static site on Azure. Now let’s do it. We’ll deploy the same my-cv folder two ways:

Then we’ll look at getting your own domain name pointed at it.

What you’ll need

Sign in once:

az login

A browser window opens for you to authenticate. Then create a resource group, which is a folder for Azure resources that lets you delete everything together later:

az group create --name cv-rg --location uksouth

Route A: Azure Storage static website

Create the storage account

Storage account names must be 3 to 24 characters, lowercase letters and numbers only, and unique across all of Azure. Pick something with your initials in it:

az storage account create \
  --name yourinitialscv2026 \
  --resource-group cv-rg \
  --location uksouth \
  --sku Standard_LRS \
  --kind StorageV2

Two choices worth understanding here. --location uksouth puts your files in the London data centre region, which is closest if your audience is in the UK. Standard_LRS means locally redundant storage: three copies of your data within one data centre. That’s the cheapest redundancy option and perfectly adequate for a CV you have a copy of on your own machine.

Turn on static website hosting

az storage blob service-properties update \
  --account-name yourinitialscv2026 \
  --static-website \
  --index-document index.html \
  --404-document 404.html

This creates the special $web container. Don’t worry that we haven’t made a 404.html yet; you can add a simple one later, and until then visitors will get a default not-found response.

Upload your files

From the folder that contains my-cv:

az storage blob upload-batch \
  --account-name yourinitialscv2026 \
  --source ./my-cv \
  --destination '$web' \
  --auth-mode key \
  --overwrite

The quotes around $web matter in most shells, because otherwise the shell treats $web as a variable. The command sets each file’s content type from its extension, so the browser knows style.css is a stylesheet.

A note on --auth-mode key: this uses the account access key, which is quick for learning but is effectively a master password for the account. For anything you care about, use Microsoft Entra ID sign-in (--auth-mode login) with the “Storage Blob Data Contributor” role on the account instead.

Find your address and visit it

az storage account show \
  --name yourinitialscv2026 \
  --resource-group cv-rg \
  --query "primaryEndpoints.web" \
  --output tsv

You’ll get a URL like https://yourinitialscv2026.z22.web.core.windows.net/. Open it, and your CV is live on the internet.

Some things to notice: the address already works over HTTPS, because the default Azure endpoint comes with Microsoft’s certificate. You’ll only run into the HTTPS limitation when you want your own domain, which we’ll cover below.

Updating the site is the same upload-batch command again. If a change doesn’t appear, your browser or an intermediate cache may be holding an old copy, so try a hard refresh (Ctrl+Shift+R, or Cmd+Shift+R on a Mac). We’ll cover caching properly in Part 6.

Route B: Azure Static Web Apps

Static Web Apps is designed to deploy from a GitHub repository, and that’s the best long-term setup: every time you push a change, GitHub builds and publishes it. But to keep this walkthrough consistent with what we’ve been doing, we’ll first deploy directly from the folder using the Static Web Apps CLI. I’ll show the GitHub route afterwards.

Create the app

az staticwebapp create \
  --name cv-swa \
  --resource-group cv-rg \
  --location westeurope \
  --sku Free

Static Web Apps is only available in a handful of regions for the management side, and westeurope is the nearest to the UK. That’s just where the service’s control plane lives; your content is served from Azure’s globally distributed network.

Deploy from your folder

Install the Static Web Apps CLI (this needs Node.js installed):

npm install -g @azure/static-web-apps-cli

Fetch the deployment token, then deploy:

TOKEN=$(az staticwebapp secrets list \
  --name cv-swa \
  --resource-group cv-rg \
  --query "properties.apiKey" \
  --output tsv)

swa deploy ./my-cv --deployment-token "$TOKEN" --env production

The deployment token is a secret, so don’t paste it into a public repository. When it finishes, find your address:

az staticwebapp show \
  --name cv-swa \
  --resource-group cv-rg \
  --query "defaultHostname" \
  --output tsv

Open https://<that hostname> and your CV is live.

The GitHub route

The more common setup is:

  1. Put my-cv in a GitHub repository.
  2. In the Azure portal, create a Static Web App, choose GitHub as the deployment source, and select your repository and branch.
  3. Set the app location to / (the root of the repo) and leave the build settings empty, because there’s nothing to build.

Azure then adds a GitHub Actions workflow to your repository. From then on, every push to your main branch republishes the site, and pull requests get their own temporary preview address. It’s a nice illustration of what “CI/CD” means in practice: nothing more than “when the files change, put the new ones on the server, automatically.”

Using your own domain name

Both routes give you a long, ugly Azure address. To use something like www.yourname.com, you’ll first need to own a domain, bought from any registrar, and be able to edit its DNS records.

On Static Web Apps

This is the easy one. In the portal, open your Static Web App, go to Custom domains, and add your domain. Azure tells you which DNS record to create. For a www subdomain, that’s a CNAME record pointing at your app’s default hostname. Once the record propagates (minutes to hours), Azure validates it and automatically issues and renews a free HTTPS certificate. You can also do this from the CLI:

az staticwebapp hostname set \
  --name cv-swa \
  --resource-group cv-rg \
  --hostname www.yourname.com

Create the CNAME record before you run it. Bare “apex” domains such as yourname.com need extra support from your DNS provider (or hosting your DNS in Azure DNS), so most people redirect the apex to www.

On Azure Storage

Here you meet the limitation from Part 4. You can map a custom domain to the storage endpoint, but Storage on its own can’t serve your custom domain over HTTPS. To get HTTPS on your own domain, you have to put Azure Front Door (or a CDN) in front, and as we saw, Front Door Standard carries a base fee of around $35 a month.

That’s why, for a personal site on your own domain, Static Web Apps wins on cost. The exercise of setting up Storage is still worthwhile for learning. Just be aware that “cheapest storage” and “cheapest way to serve HTTPS on your domain” are different questions.

Tidying up

Cloud resources keep costing money until you delete them. When you’ve finished experimenting, remove anything you don’t want:

az group delete --name cv-rg --yes --no-wait

That deletes the resource group and everything in it (the storage account and the Static Web App). It can’t be undone, which is exactly why we put everything in one group.

Checkpoint

You now have your hand-coded CV running on Azure, twice: once on the most basic file-hosting option, and once on a service designed for it. You’ve also seen how the pieces (files, a place to serve them, DNS, HTTPS) fit together, which is the same picture that sits behind every hosting platform, however glossy its dashboard.

In the final part we’ll turn to the numbers: what this actually costs, what makes it fast, and how to keep it both cheap and quick.

Next: Part 6, Cost and Performance: Keeping Your Site Fast and Your Bill Tiny.