Builds

How nesly decides what to build, and how to tell it something different.

Most projects need nothing on this page. On every deploy the platform looks at your source, recognises the framework, installs with the package manager your lockfile names, runs your build and serves the result — as static files when that is what the build produced, as a container when your project is a server.

The rest of this page is for when that is not what you want.

What is detected

Framework	Build	Output	Served as
Vite (React, Vue, Svelte, Solid…)	npm run build	dist	static site
Create React App	npm run build	build	static site
Astro	npm run build	dist	static site (a server adapter makes it a container)
SvelteKit	npm run build	build	static site with adapter-static, container otherwise
Next.js	npm run build	out	static site with output: 'export', container otherwise
Nuxt	npm run build	—	container
Remix	npm run build	—	container
Angular	npm run build	from angular.json	static site
Gatsby	npm run build	public	static site
Docusaurus	npm run build	build	static site
VitePress	npm run build	docs/.vitepress/dist	static site
Eleventy	npm run build	_site	static site
Plain HTML/CSS/JS	—	—	served as it is

The package manager comes from the lockfile: pnpm-lock.yaml, yarn.lock, bun.lock or package-lock.json. The Node version comes from engines.node or .nvmrc. Anything not in this table — Go, .NET, Python, Ruby, a Dockerfile — is built as a container, as before.

nesly.toml

Put the file in the repository root and commit it. It travels with the code, it is reviewed with the code, and it wins over anything set in the console.

[project]
name = "shop"                             # project this repository deploys into

[build]
root = "apps/web"                          # directory the build runs in
install = "pnpm install --frozen-lockfile" # install dependencies
command = "pnpm run build"                 # build the project
output = "dist"                            # directory to publish as a static site

Generate it from what is already there:

nesly init

Every field is optional. A field you leave out is decided by the console settings, and then by detection — in that order. nesly build show prints the result, and the build log names the source of every value it used.

The settings

root	Directory the build runs in — the one setting a monorepo always needs.	apps/web
install	Command that installs dependencies. Detected from the lockfile.	pnpm install --frozen-lockfile
command	Command that builds the project.	pnpm run build
output	Directory to publish as a static site. Setting it means “this is a site, not a server”.	dist
start	Command that runs the server. Setting it means the opposite, and wins over output.	node server.js

The same five fields live in the console (project → Settings → Build settings) and in the CLI:

nesly build show
nesly build set --root apps/web --output dist
nesly build clear output

Environment variables during the build

Your project's variables are available while it builds, not only while it runs — which is what VITE_* and NEXT_PUBLIC_* need. Set them before you deploy:

nesly env set VITE_API_URL=https://api.example.com
nesly deploy

Remember that anything a frontend build reads ends up in the files you ship. Keep real secrets on the server side.

When a build goes wrong

“the build finished but produced no dist directory” — your build writes somewhere else. Set output to that directory.
“dist is not a static site” — the build produced a server. Remove output, or set start to the command that runs it.
“build root apps/web is not a directory in this repository” — the path is relative to the repository root, and the deploy is refused before anything runs.
“no start command for this Python project” — without one, the fallback is python main.py, which runs your file and exits instead of serving. The deploy is refused up front instead of timing out five minutes later; set start (e.g. uvicorn main:app --host 0.0.0.0 --port $PORT). nesly build show prints the same warning before you deploy.
A build has 20 minutes. The build log is kept with the deployment, so you can read it after the fact: nesly logs.