I hit this on the very first deploy of this site, so if you’ve just wired a Hugo repo up to Azure Static Web Apps and the GitHub Actions run went red, you’re probably looking at the same thing I was.

The error

The workflow that Azure generates for you fails during the Oryx build step with this:

Detected following platforms:
  hugo: 0.152.2

/opt/hugo/0.152.2/hugo: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /opt/hugo/0.152.2/hugo)
/opt/hugo/0.152.2/hugo: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /opt/hugo/0.152.2/hugo)
/opt/hugo/0.152.2/hugo: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /opt/hugo/0.152.2/hugo)
/opt/hugo/0.152.2/hugo: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /opt/hugo/0.152.2/hugo)

Oryx has failed to build the solution.

Nothing in your repo causes this and nothing in your repo fixes it.

What’s actually wrong

Azure Static Web Apps uses Oryx to build your site inside a Docker container. That container is based on Debian bullseye, which ships an older glibc. Oryx then downloads a recent Hugo binary — 0.152.2 in my case — which was compiled against a newer glibc than bullseye has.

So Azure’s own build engine downloads a Hugo it can’t run. You can’t patch their container and you can’t pin Oryx to an older Hugo in any supported way, so the sensible move is to take the build away from Oryx entirely.

The fix

Build Hugo yourself on the GitHub runner (which is a current Ubuntu image with no glibc problem), then tell the Azure deploy step to skip its own build and just upload the finished output.

Three changes to the workflow file Azure committed to your repo (.github/workflows/azure-static-web-apps-*.yml):

1. Make sure checkout pulls your theme submodule — if you added your theme with git submodule add, the default workflow won’t fetch it and you’d hit a second failure after fixing this one:

      - uses: actions/checkout@v3
        with:
          submodules: true
          lfs: false

2. Add two steps after checkout — install Hugo and build the site:

      - name: Setup Hugo
        uses: peaceiris/actions-hugo@v3
        with:
          hugo-version: '0.152.2'
          extended: true

      - name: Build site
        run: hugo --minify

3. Point the deploy step at the built output and skip Oryx:

      - name: Build And Deploy
        id: builddeploy
        uses: Azure/static-web-apps-deploy@v1
        with:
          azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_YOUR_SECRET_NAME }}
          repo_token: ${{ secrets.GITHUB_TOKEN }}
          action: "upload"
          app_location: "public"
          api_location: ""
          output_location: ""
          skip_app_build: true

Leave the two token lines exactly as Azure generated them — only the location values and skip_app_build change. app_location becomes public because that’s where Hugo puts the finished site, and with skip_app_build: true the Azure action treats it as ready-made content to upload rather than source to build.

Commit, the workflow re-runs, green tick.

Why this is better anyway

Even once Microsoft catches Oryx’s image up, I’d keep this setup:

  • Pinned Hugo version. Oryx grabs whatever Hugo it feels like; a new Hugo release with a breaking change can kill your deploys overnight. With hugo-version pinned in the workflow, upgrades happen when you choose.
  • Same build locally and in CI. What hugo server shows you on localhost is what ships.
  • Faster feedback. The runner build fails or passes before the deploy step even starts, so a broken build never half-deploys.

If you’re standing up a Hugo site on Static Web Apps from scratch, I’d just start with this workflow shape and never give Oryx the chance.