Deploy Hugo

How nesly detects, builds and serves a Hugo project — and the two commands that put it on a live URL.

Deploy Hugo on nesly

A Hugo project is built once and served as static files — no server process to keep alive.

cd your-project
nesly deploy --yes

The first deploy creates the project and prints the live URL; after that, nesly deploy is enough.

How detection sees it

A hugo.toml (or hugo.yaml / hugo.json) is detected as Hugo; so is a config.toml next to a content/, themes/ or archetypes/ directory. A bare config.toml alone is not enough — too many tools use that filename.
The site is built with hugo --minify in a pinned Hugo extended image and public/ is served as static files.

When detection is not what you want, say it yourself: build and start commands, root directory and output directory live in nesly.toml committed next to the code — see builds.

Worth knowing

A theme added as a git submodule is not fetched on git deploys (the platform clones without submodules). Vendor the theme into themes/, use a Hugo module, or deploy from the CLI with the theme present on disk.
When a deploy fails, nesly diagnose reads the logs for you and names the fix.

Full walkthrough: get started. Custom domains, backups, GitHub deploys and the rest of the reference: nesly CLI.