Record Hugo's Build Details with hugo version

A bug report that just says "Hugo is broken" gets ignored, and hugo version is the one command that turns that into something a maintainer can act on. It is read-only: it will not build a site, write to your destination, or alter project files. Examples here were checked with Hugo 0.123.7 extended on Linux amd64, from Ubuntu package version 0.123.7-1ubuntu0.3+esm2.

Allow about five minutes. You need a shell and hugo in your PATH. No elevated privileges required. If you are chasing a failed build, keep the project directory open so you can record the command and its surrounding environment together.

1. Confirm which Hugo executable will actually run

Start with the path lookup. This stops you collecting version details from a different installation than the one your script or service actually uses:

$ command -v hugo
/usr/bin/hugo

The path is host-specific. Empty output means Hugo is not on the current PATH: check the shell environment, or use the absolute path of the installation you deliberately chose. Do not reach for sudo to work around a missing user command; root's PATH can point at a different Hugo binary and hide the real problem.

Checkpoint: on a Debian or Ubuntu system, ask the package manager which package owns the executable:

$ dpkg-query -S /usr/bin/hugo
hugo: /usr/bin/hugo

This ownership check is optional and not part of Hugo itself. If your installation came from a release archive, a language package manager, or a manually chosen directory, use that method's own inventory instead.

2. Print the complete version line

Run the subcommand with no project path or build options:

$ hugo version
hugo v0.123.7+extended linux/amd64 BuildDate=2026-03-17T19:51:14Z VendorInfo=ubuntu:0.123.7-1ubuntu0.3+esm2

Read it as several separate pieces of evidence:

• v0.123.7 is the version.
• +extended identifies the extended build variant.
• linux/amd64 identifies the target platform.
• BuildDate identifies the build timestamp.
• VendorInfo identifies the packaging provenance this binary reports.

Do not compare the whole line as a permanent string in automation: build dates and vendor fields shift when the package is rebuilt. If a script needs a version gate, decide whether it needs the release, the extended variant, or both, then parse only that part with a tested method. For a support ticket, keep the complete unedited line.

3. Capture the package version separately when it matters

Hugo's own output reports the program build. A distribution package can carry its own revision, so record both when a bug might involve downstream patches or packaging:

$ dpkg-query -W -f='${Package} ${Version}
' hugo
hugo 0.123.7-1ubuntu0.3+esm2

On this machine the package revision matches the vendor information embedded in the Hugo line, which is useful evidence but not a rule for every distribution: a binary copied from another host may report one build while the local package database knows nothing about it. If you only need Hugo's own identity, hugo version is enough; do not report the package-manager result as Hugo's upstream version, they serve different purposes.

4. Check the command's own options with help

$ hugo version --help
Print Hugo version and environment info. This is useful in Hugo bug reports.

Usage:
  hugo version [flags] [args]

Flags:
  -h, --help   help for version

The version command has one direct option, --help. It also shows global Hugo flags inherited from the parent command, including configuration, source, destination, environment and logging options. None of those are a reason to point the command at a project or destination for an ordinary version check: keep the simplest invocation for a clean, portable diagnostic.

The installed Hugo 0.123.7 accepts an extra positional argument and still prints the version line, but that is not something to depend on. Treat hugo version as a no-argument diagnostic.

5. Record the result before touching a failed build

Collect the version before changing the installation or switching shells:

$ {
    command -v hugo
    hugo version
    dpkg-query -W -f='${Package} ${Version}\n' hugo 2>/dev/null || true
}

The package query is allowed to fail, since not every Hugo installation is managed by dpkg. command -v identifies the executable, the Hugo line identifies its build, and the package line adds distribution context when it is available. Keep this alongside the Hugo error, project configuration and the command that failed.

Warning: do not include secrets from your project when sharing diagnostics. The version command needs no configuration file, but a later build command may print paths, module names or other environment details, so review a support bundle before sending it outside your team.

Common traps

• Running from inside a project does not make the check project-specific. It reports the Hugo executable and its build; it proves nothing about your current theme, modules, templates or content.
• A matching version line does not make two builds identical. Extended and standard variants provide different capabilities, and the operating system, modules, configuration and dependencies still matter.
• Do not add --destination, --source or --config just because help lists them: they are inherited global options, and the version check itself is read-only and needs none of them.
• Skip --verbose: this installed release prints a deprecation warning for it. Keep the plain command and capture the clean version line instead.

Done means

• command -v hugo identified the executable you meant to inspect.
• hugo version produced a complete build and platform line.
• You recorded the extended or standard build variant instead of assuming it.
• You captured the distribution package revision separately when packaging could affect the diagnosis.
• You used no elevated privileges and changed no project, configuration or service state.