Host a hugo website

Hugo builds locally; the host only sees public/

Hugo is a static site generator: Markdown in, HTML out. StaticHost publishes the out. There is no Hugo binary on the server, no hugo server remote, and no theme compilation step in the cloud. Your laptop or CI runs Hugo; the host serves public/.

Configure baseURL

In hugo.toml / config.toml:

baseURL = "https://example.com/"
languageCode = "en-us"
title = "Example"

For first deploys on StaticHost preview, you can temporarily set baseURL to the preview origin or use relative URLs carefully. Wrong baseURL produces wrong canonical links and sometimes wrong asset paths depending on theme. When the custom domain is live, set baseURL to that HTTPS canonical URL and rebuild.

Build commands

hugo version
hugo --minify
ls public

--minify shrinks HTML/CSS/JS output. Useful flags:

hugo --minify --gc
hugo --environment production

Themes and modules must be present locally (git submodule update --init if themes are submodules):

git submodule update --init --recursive
hugo --minify

Output directory defaults to public/. Publish contents of public/:

cd public && zip -r ../hugo-site.zip .

Verify index.html at archive root. Upload to StaticHost or push public contents to a deploy branch. Nested zip mistakes: zip guide.

CI without remote Hugo on StaticHost

Example pattern: GitHub Actions installs Hugo, builds, uploads artifact or commits to gh-pages-style branch that StaticHost reads. StaticHost itself still just receives files—git deploy.

Pretty URLs and strict nginx

Hugo emits directories with index.html for pretty URLs (/posts/my-post/). That maps cleanly to try_files $uri $uri/ =404. You generally will not hit SPA fallback problems unless you embedded a history-mode JS app inside a Hugo layout. If you did, read SPA hosting.

Taxonomies, aliases, and redirects

Hugo aliases generate extra HTML stubs—good for static hosts. Do not expect Apache .htaccess redirect semantics. Prefer alias pages or external DNS/host features you control.

Media and memory

Image processing happens at build time on your machine (hugo image funcs). Upload the processed results. Large photo sites may need Pro (10 GB) or Scale (30 GB) rather than Starter (2 GB). Plans: Starter $9, Pro $30 (also staging + 3 sites), Scale $65 (10 sites), Business $130 (30 sites, teams, 100 GB). Trial ~1 day.

Verify on StaticHost

1. Deploy public/ contents; open HTTPS preview.
2. Check home, a section list, a single post, RSS if you publish it.
3. View source for asset paths matching baseURL expectations.
4. Roll back if a theme upgrade broke layouts.
5. Point DNS; certificate after verification—custom domain.

No cPanel, email, built-in CDN, forever-free, or WordPress runtime.

Worked example: multilingual section with aliases

# hugo.toml excerpt
baseURL = "https://docs.example.com/"
defaultContentLanguage = "en"
[languages.en]
  weight = 1
  languageName = "English"
[languages.es]
  weight = 2
  languageName = "Español"

hugo --minify
find public -type f -name 'index.html' | head
# confirm public/es/... exists before zipping
cd public && zip -r ../hugo-docs.zip .

Deploy, open HTTPS preview, hard-open /es/ and an English post URL. If Spanish pages 404, your language config never emitted files—fix Hugo, not nginx. Add aliases in front matter when renaming posts so old URLs keep HTML stubs that static hosting can serve. Custom domain certificates still wait on DNS verification after preview looks right—static hosting with a custom domain. Pair with static documentation hosting when the Hugo site is primarily docs.

Content editors and Hugo’s boundary

If non-engineers edit Markdown, give them a preview path that runs hugo server locally or in a ephemeral CI preview environment you own—not a fantasy that StaticHost will compile drafts on save. Publish still means hugo --minify and an upload of public/. That boundary keeps the live host stable while editors iterate.

Failure table: Hugo on StaticHost

Extra procedure: Hugo release checklist

1. git submodule update --init --recursive
2. hugo --minify (Extended if theme needs it)
3. Spot-check public/ for home, a post, taxonomy, 404 page if you ship one
4. grep -R "http://" public | head for mixed content before HTTPS custom domains—SSL
5. Zip/push artifacts; deploy; HTTPS preview QA
6. Only then DNS → verify → cert
7. Keep previous deploy for rollback after theme upgrades
8. Remember non-features: no email, no cPanel, no CDN product, no forever-free after trial, no SPA fallback

JAMstack framing without fog: jamstack hosting for beginners. Hugo stays a local/CI compiler; StaticHost stays a file host.

Theme upgrades without surprise outages

Hugo themes move under your feet. A submodule bump that looks harmless on hugo server can change partial names, asset pipelines, or SCSS assumptions that only appear after hugo --minify. Treat theme upgrades like dependency upgrades in any other stack.

1. Branch locally; update the theme submodule intentionally.
2. Build production output; diff public/ sizes and spot-check critical templates (home, single, list, 404).
3. Deploy to StaticHost HTTPS preview—or Pro staging—before production.
4. If layouts collapse, roll back the StaticHost deploy first, then revert the submodule.

Do not combine a theme upgrade, a baseURL change, and a DNS cutover on the same afternoon. Sequence reduces mystery. StaticHost still will not run Hugo for live reload; your CI must install Hugo Extended when the theme requires it. Keep aliases for renamed docs so old inbound links keep serving HTML stubs under try_files $uri $uri/ =404 instead of soft-404 confusion. When editors ask for on-server draft compilation, restate the boundary: drafts with hugo server -D locally, production with a non-draft minify build, files only on the host. That sentence saves more outages than any theme tweak.

FAQ

Can StaticHost run hugo server for live reload?

No. Develop locally with hugo server; publish with hugo --minify.

Where do extended Sass features run?

On your machine with Hugo Extended. Install Extended locally/CI before build.

Should I upload the whole Hugo repo?

No. Upload public/ output only (plus whatever static files Hugo already copied there).

How do I preview drafts?

hugo server -D locally. Do not publish draft-enabled production builds by accident (hugo -D on production is a common mistake).

Is Hugo “JAMstack”?

It can be part of a JAMstack-style flow. StaticHost hosts the markup/assets piece without platform functions—JAMstack beginners.