Static generators
Deploy Node-based generators, Hugo, Jekyll, and MkDocs with managed presets.
Nitroship publishes generated HTML and assets to the CDN. Node-based generators use the Node build toolchain; Hugo, Jekyll, and MkDocs use a generated container build. None of these static presets needs a compute region.
Node generators
| Preset slug | Project marker | Default output |
|---|---|---|
gatsby | gatsby in package.json | public |
docusaurus | @docusaurus/core in package.json | build |
vitepress | vitepress in package.json | <buildRoot>/.vitepress/dist |
eleventy | @11ty/eleventy in package.json | _site |
Keep the generator’s build script in package.json, such as gatsby build, docusaurus build, vitepress build docs, or eleventy. For VitePress, buildRoot is the directory passed to the build command (docs in that example); with no directory argument the default is .vitepress/dist. The VitePress configuration’s srcDir changes where content is read, not this output location.
For Node generators, if you customize the output, set build.outputDirectory to the resulting folder. Select the appropriate slug below; static-generators is the documentation group, not a preset slug.
Hugo, Jekyll, and MkDocs
| Preset slug | Project marker | Managed build |
|---|---|---|
hugo | hugo.toml, hugo.yaml, hugo.yml, or hugo.json; alternatively config.toml with content/ and either layouts/ or themes/ | hugo --destination /site |
jekyll | _config.yml and a Gemfile declaring jekyll | bundle install then bundle exec jekyll build --destination /site |
mkdocs | mkdocs.yml | Install MkDocs and requirements.txt if present, then mkdocs build --site-dir /site |
These presets redirect the usual public, _site, or site output into /site in a generated final scratch image. Only that directory’s contents become CDN files; no server or source code is deployed. There is no automatic SPA fallback.
The builder pins the toolchain/base image, selecting the nearest supported declared version or a stable default:
- Hugo:
.tool-versions; supported Hugo lines are0.145,0.147, and0.167, with a current default of0.167.0. - Jekyll:
.ruby-version, then the Gemfile’srubydeclaration, then.tool-versions; supported Ruby lines are3.2,3.3,3.4, and4.0, with a current default of4.0.7. - MkDocs:
.python-version, then.tool-versions; supported Python lines are3.12,3.13, and3.14, with a current default of3.14.8. Project requirements supply additional plugins.
These static-only presets have no runtime filesystem or writable upload directory.
Deploy
Install the CLI
curl -fsSL https://nitroship.co/install.sh | bash
ntro loginAlready installed? Skip ahead. Full options, PATH setup, and updates: Install the CLI.
{
"build": {"framework": "gatsby"}
}Setting build.framework skips detection and uses this preset, even if your project root has a Dockerfile. It can't be combined with build.dockerfile. Without it, Nitroship detects the build as described in How Nitroship chooses a build.
ntro apps create my-static-generators-app
ntro deploy . --prodNode generators support ntro deploy . --prod --local after installing dependencies. Hugo, Jekyll, and MkDocs require the hosted builder: drop --local. To select one, change build.framework to hugo, jekyll, or mkdocs. After deployment, open static assets and several page URLs directly.
Static-only contract
The preset publishes generated files, not Gatsby SSR/DSG servers or other request-time rendering. Generate the required routes at build time, and check several pages by opening their URLs directly. For a runtime-dependent setup, use a managed server framework or your own Dockerfile.
Limits and custom setups
Static deployments need no compute region and do not run SSR, server APIs, or server middleware. Never put secrets in browser-visible configuration. See Environment variables for build-time settings and Static sites for routing.
For adapters or output layouts outside this contract, use your own Dockerfile. Remove build.framework and define installation, build, and startup in the Dockerfile.