# Hugo: four editions, two build tags, and one feature already on its way out > gohugoio/hugo is a static site generator written in Go, and almost everything interesting about it is decided at build time. Four editions differ by exactly two capabilities, the extended ones need a C compiler because CGO is on, and the feature that separates them from the standard build is already deprecated. **gohugoio/hugo** — Hugo builds static websites from content files and templates, with taxonomies, multilingual output, and asset processing. - Repository: https://github.com/gohugoio/hugo - Website: https://gohugo.io - Stars: 89,988 · Forks: 8,389 - Language: Go - License: Apache-2.0 - Published: 2026-08-08 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/gohugoio-hugo ## Four editions that differ by two checkboxes The editions table is the most useful page in this README, and it is short. There are four builds: standard, deploy, extended, and extended/deploy. Core features are marked present in all four. Direct cloud deployment, meaning you push the site straight to a Google Cloud Storage bucket, an AWS S3 bucket or an Azure Storage container, is present only in deploy and extended/deploy. LibSass support is present only in extended and extended/deploy. Consequence for the reader: the edition you choose decides two things and nothing else. Templating, asset pipelines, modules, taxonomies and multilingual output are identical across all four, so an argument for the extended edition that rests on flexibility or on image processing is arguing about capabilities every edition already has. The honest question is only whether you need the binary to deploy, and whether you need LibSass specifically. ## The reason to pick extended is the reason not to pick it The footnote on the LibSass row is the sentence that matters. Embedded LibSass was deprecated in v0.153.0 and will be removed in a future release, and the note directs you to the Dart Sass transpiler instead, which the note says is compatible with any edition. So the capability that splits extended from standard has a replacement that does not need the split at all. Consequence for the reader: a team that chose extended in order to compile Sass now has a build that is harder to build and carries a feature on a removal path. Migrating means swapping the transpiler rather than editing configuration, and the README gives you no reason to delay it. The practical trap is that the table still shows a green mark, so a decision made from the table alone looks safe when the footnote says otherwise. Read the footnote before the table. ## CGO is what turns a build tag into a toolchain requirement Building from source needs Git and Go 1.27.0 or later, and then the edition is chosen by a build tag, with CGO either off or on: ```sh CGO_ENABLED=0 go install github.com/gohugoio/hugo@latest CGO_ENABLED=0 go install -tags withdeploy github.com/gohugoio/hugo@latest CGO_ENABLED=1 go install -tags extended github.com/gohugoio/hugo@latest CGO_ENABLED=1 go install -tags extended,withdeploy github.com/gohugoio/hugo@latest ``` The two extended variants ask you to install a C compiler such as GCC or Clang first. Consequence for the reader: the extended builds are not portable binaries, so a build that succeeds on a laptop with a compiler installed fails on a minimal continuous integration image, and it fails at build time rather than reporting a missing feature later. Standard and deploy set CGO_ENABLED=0 and need nothing beyond Go. If your build environment is a bare container, that decision is made for you before you read anything else. ## The container defaults to extended, not to the edition the README suggests The Dockerfile sets `ARG HUGO_BUILD_TAGS="extended"` under a comment saying the extended version is built by default, and sets `ENV CGO_ENABLED=1` to match. It cross-compiles with helpers copied from a separate xx image, then builds and immediately runs the result: ```dockerfile ARG HUGO_BUILD_TAGS="extended" ENV CGO_ENABLED=1 ``` The build step passes `-ldflags "-s -w -X github.com/gohugoio/hugo/common/hugo.vendorInfo=docker"`, so the binary records that it came from a container, and a verification step runs the produced binary for the target platform. Consequence for the reader: taking the container gives you extended whether you wanted it or not, so the deprecated Sass transpiler is inside the image and a C toolchain is part of the build. A container build and a source build of the same release are not the same artifact, and the verify step means a binary that will not run on its target fails the image build instead of your site build. ## Dart Sass is pinned in the image and left to the host elsewhere A separate stage in the Dockerfile exists to fetch the Dart Sass runtime, with `ARG DART_SASS_VERSION="1.79.3"` and a comment noting that dart-sass downloads the runtime dependency. The architecture is derived with `ARG DART_ARCH=${TARGETARCH/amd64/x64}`. Consequence for the reader: the transpiler version is fixed by an argument inside the image, while a standard binary installed from a package manager takes whatever the host provides, and the README only says to use the Dart Sass transpiler without naming a version. Two people on the same Hugo release can therefore be compiling Sass with different transpilers and get different results from the same source. This matters more than it did a year ago, because Dart Sass is now the supported path for every edition and the version is the most likely thing to differ between two installations that are both correct. ## Two test files at the root are named after the build tag The repository root carries main.go, main_test.go, main_withdeploy_test.go and main_withdeploy_off_test.go, and there is a deploy/ directory in the tree. That pairing is how the deploy edition gets covered: the suite is compiled and run with the tag and again without it. Consequence for the reader: the edition split costs a second full test run, which is the price of shipping four binaries from one tree. It also means the standard build genuinely excludes the deploy code rather than hiding it behind a runtime check, so a capability the table marks unavailable in the standard edition is absent from the binary rather than failing when you reach for it. The related caveat is that a test passing in one configuration says nothing about the other, so a change touching shared code has to be verified in both. ## Questions go to a forum, documentation goes to another repository Support is routed with instructions rather than a link dump. The README asks you not to use the issue queue for questions or troubleshooting and to use the forum unless you are certain the issue is a software defect, notes that a search of over 20,000 topics will often answer a question, and asks you to read about requesting help before your first post. Documentation issues and pull requests go to a separate documentation repository, and contributing is listed as answering forum questions, improving the documentation, monitoring the issue queue, and creating or improving something in the list the page cuts off. Consequence for the reader: there are three destinations, and the most likely mistake is filing documentation in the issue queue, where it is explicitly not wanted. The repository also has a docs/ directory of its own, sitting beside a documentation repository elsewhere, so a documentation change can be filed in the wrong place and quietly go stale. For a first-time user the rule means the first contact is a forum post, and the ask is that you read how to ask before you make it. ## Conclusion Use the standard edition unless you have a concrete reason not to, because the two capabilities the other editions add are narrow and one of them is scheduled for removal. Do not reach for extended out of habit after a Sass migration, since Dart Sass works in every edition and LibSass is the thing being removed. Before you pick, check three things: whether you actually need to push to a Google Cloud Storage bucket, an AWS S3 bucket or an Azure Storage container from the binary itself, since that is the only other difference; whether your build machine has a C compiler, since the extended builds set CGO_ENABLED=1 and fail without GCC or Clang rather than degrading; and which edition the container you were handed is, because the Dockerfile defaults to extended and stamps vendorInfo=docker into the binary, so a container build and a source build of the same release are not the same artifact. ## FAQ ### What is GoHugo? It is a static site generator written in Go, described as fast and flexible, with an advanced templating system and fast asset pipelines. It ships in four editions: standard, deploy, extended, and extended/deploy, built from the same source with different build tags. ### What is Hugo used for? The README lists corporate, government, nonprofit, education, news, event and project sites, documentation sites, image portfolios, landing pages, business and personal blogs, and resumes and CVs. It also names a use of its own for developers: the embedded web server, so content, structure, behaviour and presentation changes appear immediately during development. ### Is Hugo better than WordPress? The README does not compare Hugo to WordPress or to any other tool. It places Hugo in the static site generator category, names the site types it is used for, and points to a features page for a fuller summary. Any comparison has to be made outside this repository. ### Which Hugo themes are most popular? The README links a themes site but ranks nothing and names no theme. The only theme-related capability it describes is sharing themes with other projects through Hugo Modules, over public or private Git repositories. Popularity is not something this repository records. ## Sources - [Official documentation](https://gohugo.io) - [Official README](https://github.com/gohugoio/hugo#readme) - [Project repository](https://github.com/gohugoio/hugo) - [Release notes](https://github.com/gohugoio/hugo/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gohugoio-hugo