Build commands

Your project decides the commands a build runs, not gigadrive.yaml, and the root directory decides where they run.

Gigadrive Network derives the install and build commands from your project: your packageManager field or lockfile picks the package manager, and the build script in package.json is the build. No key in gigadrive.yaml replaces either one.

build_commands is accepted and not run

The v4 schema still takes a build_commands list, and the deployment pipeline never executes it. The config file is read after the build finishes, so nothing it contains can influence what the build ran. A project that needs a different command must change its build script.

What a build actually runs

Install comes first, from the repository root so that a workspace lockfile resolves. A project carrying a composer.json or a composer.lock gets composer install as well. Then the build script from package.json runs, with the same package manager that did the install, and the step is skipped with No build script found in package.json, skipping build when there is none. Builds has the full sequence, the package-manager detection order, and how environment variables reach both steps.

{
  "scripts": {
    "build": "vite build --mode production"
  }
}

The build environment

Every build gets a fresh sandbox built on the Node.js 24 image, which ships npm. pnpm and yarn are enabled through Corepack, and a packageManager field in your package.json is honoured; without one, pnpm projects get pnpm 10. Bun, PHP with php-cli, Composer, git, curl, and unzip are all installed in the image, so no build step has to fetch them.

The sandbox itself does not survive the deployment. The package-manager stores it downloaded into do, through Build cache, so the second install of the same lockfile fetches almost nothing.

Monorepos

A project that does not sit at the repository root needs the Root directory setting, under Settings, General for the application. It changes three things at once:

gigadrive.yaml is read from that directory, not from the repository root. A monorepo with two deployable applications keeps a config file in each.
Framework detection runs against that directory.
The build script runs there, while install still runs from the repository root so pnpm-workspace.yaml and the lockfile are picked up.

The path is relative, and it has to resolve to a real directory inside the repository rather than to a symlink. A root directory that fails either check fails the build before install runs, with a message naming the directory.