Build & runtimes
How Manufact detects your runtime and package manager, selects the pnpm/npm/bun version, and runs dependency build scripts.
When you deploy from GitHub, Manufact analyzes your repository and generates a build for it automatically. This page explains how the runtime and package manager are chosen, and how dependency build scripts (like esbuild, sharp, or protobufjs) are handled, so your deploys behave the same way they do locally.
Manufact honors your project's own configuration rather than imposing its own.
Supported runtimes
| Runtime | Detected from | Package managers |
|---|---|---|
| Node.js | package.json (+ a lockfile) | npm, pnpm, yarn, bun |
| Python | pyproject.toml / requirements.txt | uv, poetry, pipenv, pip |
| Anything else | a committed Dockerfile | your image |
Deno and other runtimes
Deno is not auto-detected. A deno.json on its own will not build, because the generated image has no deno binary and the start command exits with code 127. To deploy Deno (or any unsupported runtime), commit a Dockerfile to your repo, Manufact uses it as-is.
Package manager detection
The package manager is chosen from the lockfile in your repo:
| Lockfile | Package manager |
|---|---|
pnpm-lock.yaml | pnpm |
bun.lock / bun.lockb | bun |
yarn.lock | yarn |
package-lock.json (or none) | npm |
pnpm version selection
Manufact selects the pnpm version as follows:
-
Your
packageManagerfield wins. Ifpackage.jsonpins pnpm (corepack format, e.g."packageManager": "pnpm@11.5.3"), that exact version is used via Corepack, including pnpm 11. -
Otherwise, the lockfile decides.
lockfileVersionmaps to a pnpm major:lockfileVersionpnpm 9 (and unknown) 10 7 9 6 8 5 7
So a project with no packageManager field defaults to pnpm 10.
Dependency build scripts (pnpm 10+)
Since pnpm 10, dependency build/postinstall scripts are blocked by default for supply-chain safety. Manufact does not override this, it runs a plain pnpm install and respects your repo's own policy. This means you control exactly which dependencies are allowed to run scripts.
To allow a dependency to build, add it to onlyBuiltDependencies (run pnpm approve-builds locally, or edit by hand) in either package.json or pnpm-workspace.yaml:
onlyBuiltDependencies:
- esbuild
- "@parcel/watcher"
- protobufjs
- core-jsWhat happens to a dependency with a build script that is not on the allowlist depends on the pnpm version:
| pnpm | Unlisted build script | Effect |
|---|---|---|
| 10 (default) | Skipped with a warning | Build succeeds, but the dependency's native artifacts are not built, this can fail at runtime (e.g. a missing esbuild/sharp binary). |
11 (opt-in via packageManager) | ERR_PNPM_IGNORED_BUILDS | Build fails. pnpm 11 is strict by default. |
If your server uses a dependency that needs a build step
Add it to onlyBuiltDependencies. Servers scaffolded with create-mcp-use-app already include the right allowlist. If you pin pnpm 11, you must approve builds or the deploy fails.
npm, yarn, and bun run dependency build scripts by default (bun gates untrusted postinstall scripts but does not fail the install), so no allowlist is required for those package managers.
Build and start commands
By default Manufact runs your build script (when present) and your start script. You can override both per server, Build command and Start command in Server settings, which is useful for monorepos or when the MCP server is a sub-package (for example npm run mcp:build / npm run mcp:start).