Hugo

Search for Hugo in the Marketplace, select the SecureAnyCloud publisher, and select Create.

Configure these NSG rules:

• TCP 80 and TCP 443 from the networks that should reach the website. For a public site, which is the normal case for a static site, that is the whole internet.
• TCP 22 for admin SSH from your management network only.

az vm image terms accept --urn sac1647283583153:hugo:default:latest
az vm create \
  --resource-group my-hugo-rg \
  --name my-hugo-vm \
  --image sac1647283583153:hugo:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard
# Open the website to the networks that should see it
az vm open-port --resource-group my-hugo-rg --name my-hugo-vm --port 80 --priority 1010
az vm open-port --resource-group my-hugo-rg --name my-hugo-vm --port 443 --priority 1020

Log in over SSH as azureuser. A few seconds after the VM reports ready, first boot resolves this VM's public address, writes it into the site configuration, generates the TLS certificate and renders the site.

sudo systemctl is-active nginx.service hugo version

Expected output:

active hugo v0.164.0-ce2470e7012b5ab5fc4e10ebe4027e9f8d9e00dc+extended linux/amd64 BuildDate=2026-07-06T16:39:30Z VendorInfo=gohugoio

Check for the +extended suffix. It tells you the embedded SCSS transpiler is present, so SCSS-based themes build.

Confirm that nginx holds both website ports and that the automatic publish watchers are running:

sudo ss -lntp | grep -E ':(80|443)\b' systemctl is-active hugo-publish.timer hugo-publish.path

The image records exactly which upstream artifact it shipped, including the pinned digest:

cat /usr/local/share/hugo/VERSION

Open http://<public-ip>/ in a browser. HTTPS on the same address works too. Your browser warns once about the self-signed certificate. Step 8 replaces it with your own.

The styling on that page is evidence, not decoration. The stylesheet does not exist as a .css file anywhere on disk. Hugo's embedded transpiler compiles it from assets/scss/main.scss every time the site is published. A page that renders styled was built by the extended edition.

The Posts link shows the section index. Every entry is one Markdown file in content/posts/.

An individual post shows what Hugo does with Markdown. Headings, prose, inline code and fenced code blocks all become real HTML.

From the VM itself, confirm that what nginx serves is Hugo's output:

curl -s http://127.0.0.1/ | grep -oE 'content="Hugo [0-9.]+"'

Expected output:

content="Hugo 0.164.0"

Everything is under /var/www/hugo, owned by an unprivileged hugo account.

ls -1 /var/www/hugo find /var/www/hugo/content -name '*.md' | sort

• content/: your Markdown, one file per page
• layouts/: the HTML templates (baseof.html is the page shell)
• assets/scss/main.scss: the stylesheet source, compiled at publish time
• static/: files copied to the site verbatim (images, downloads)
• public/: the generated site, which is nginx's document root
• hugo.toml: site configuration, including baseURL

The site source sits one level above nginx's document root, so your Markdown, templates and configuration are not reachable over HTTP.

First boot writes this VM's own endpoint summary. Only root can read it, and it spells out the paths you will use:

sudo cat /root/hugo-endpoints.txt

Add a page, publish, and it is live. That is the whole loop.

sudo tee /var/www/hugo/content/posts/my-first-post.md >/dev/null <<'EOF' --- title: "My first post" date: 2026-02-01 --- Written in Markdown, rendered by Hugo, served by nginx. EOF
sudo hugo-publish

Expected output:

[...] hugo-publish: change detected: /var/www/hugo/content/posts [...] hugo-publish: published 12 page(s), 104K on disk, into /var/www/hugo/public

Confirm the page is live:

curl -sf http://127.0.0.1/posts/my-first-post/ | grep -oF 'My first post'

In day-to-day use, you edit with an editor rather than a heredoc. sudo -e opens your $EDITOR on a copy and installs it when you save:

sudo -e /var/www/hugo/content/posts/my-first-post.md
sudo hugo-publish

Hugo can also scaffold the front matter for you:

cd /var/www/hugo && sudo -u hugo hugo new content posts/another-post.md

That command writes the file with draft = true set. Delete that line, or publish drafts with hugo --buildDrafts, and the page goes live.

A broken edit will not take your site down. hugo-publish renders to a staging directory and swaps it in only once the render has produced a real site. If you leave a template half-finished, the command fails with the error and the previous site keeps serving. Fix the file and publish again.

You do not have to remember hugo-publish. Two systemd units watch for changes, and both trigger the same hugo-publish.service:

• hugo-publish.path reacts within seconds to a change directly under content/ or to hugo.toml.
• hugo-publish.timer sweeps every minute. This catches edits deeper in the tree, such as content/posts/, assets/scss/ and layouts/.

hugo-publish skips the render entirely when nothing has changed, so an idle VM does no work. A lock serialises concurrent publishes, so a sweep that fires while you run the command by hand is harmless.

To try it, edit a file and run nothing at all:

sudo tee -a /var/www/hugo/content/posts/my-first-post.md >/dev/null <<'EOF' This paragraph was added without running any publish command. EOF for i in $(seq 1 30); do page="$(curl -s http://127.0.0.1/posts/my-first-post/ || true)" case "${page}" in *"without running any publish command"*) break ;; esac sleep 5 done curl -sf http://127.0.0.1/posts/my-first-post/ | grep -oF 'without running any publish command'

Watch the publishes as they happen:

sudo journalctl -u hugo-publish.service -n 20 --no-pager

To publish only on demand, disable the watchers. hugo-publish still works by hand:

sudo systemctl disable --now hugo-publish.path hugo-publish.timer

Two things change when you move from the raw IP to a domain: the baseURL Hugo bakes into absolute links, and the TLS certificate nginx presents.

Ordinary navigation and asset links on this site are relative, so they already work over HTTP, over HTTPS and behind any hostname. Hugo uses baseURL for the canonical tag, the RSS feed and the sitemap, so set it to your real address:

sudo -e /var/www/hugo/hugo.toml
# set: baseURL = "https://<your-domain>/"
sudo hugo-publish

Then install a certificate for that domain. The appliance reads its certificate from a fixed pair of paths, so you only need to replace the files and reload nginx:

# Replace with your own certificate and key for <your-domain>
sudo install -m 0644 -o root -g root fullchain.pem /etc/nginx/tls/sac-hugo.crt
sudo install -m 0600 -o root -g root privkey.pem /etc/nginx/tls/sac-hugo.key
sudo nginx -t && sudo systemctl reload nginx

For an automatically renewed certificate, install certbot and point it at the same paths. Alternatively, terminate TLS at an Azure Application Gateway or Front Door in front of the VM.

The starter content, templates and stylesheet are all yours to change or delete.

• Content: remove everything in content/ and write your own. A directory under content/ becomes a section. For example, content/notes/ serves at /notes/ and gets an index page from layouts/section.html.
• Look: assets/scss/main.scss is real SCSS with variables, nesting and mixins. Change $navy or $accent at the top and publish. The transpiler recompiles it.
• Templates: layouts/baseof.html is the page shell. home.html, page.html and section.html fill in its main block.

To use a third-party theme instead of the bundled templates, clone it into themes/, name it in the configuration, and remove layouts/ so the theme's own templates take over. Because this image is the extended edition, SCSS-based themes build correctly:

cd /var/www/hugo
sudo -u hugo git clone --depth 1 <your-theme-repo> themes/<your-theme>
sudo -e /var/www/hugo/hugo.toml
# add: theme = "<your-theme>"
sudo rm -rf /var/www/hugo/layouts
sudo hugo-publish

Keeping your site in Git is the usual next step. Hold content/ (and layouts/ if you have customised it) in a repository, pull it onto the VM, and let hugo-publish.path publish the result.

The appliance ships the same check the build gate runs. It verifies each of the following:

• The binary is the pinned extended build.
• The site re-renders right now, and the SCSS compiled.
• nginx serves, byte for byte, what was rendered.
• HTTPS presents this VM's own certificate.
• Every asset the page references returns 200 over both HTTP and HTTPS.
• The published baseURL is a routable address.

sudo hugo-selftest

Expected output:

hugo-selftest — sac Hugo appliance ok hugo v0.164.0 extended: hugo v0.164.0-...+extended linux/amd64 ... ok site re-renders and assets/scss/main.scss compiled to CSS (3410 bytes) ok nginx serves the current render byte-for-byte, and it is Hugo-generated ok HTTPS serves the same site with this VM's certificate ok all 8 referenced local assets return 200 over HTTP and HTTPS ok baseURL is routable: http://203.0.113.10/ hugo-selftest: PASS — the appliance builds the site and serves exactly what it built.

The asset check catches a failure that a browser test misses. A page can return 200 while every stylesheet and image underneath it returns 404. Requesting only the page cannot see that, but requesting everything the page references can.