Project structure
What the Gigadrive Network build reads in your project, from the root directory and lockfiles to the build script and what never gets uploaded.
The build inspects your project to choose a package manager, a build script, and the files to serve. Use these inputs to understand or change what the build detects.
The project root
The project root is the repository root, unless the application has a root directory set. Root directory, on the General settings page, is a path relative to the repository root, and the CLI takes the same value as --root-directory on gigadrive apps create. It must be relative, must exist as a real directory inside the repository, and cannot climb out with ...
In a monorepo, that split matters:
- Dependencies are installed from the repository root, so
pnpm-workspace.yamland other workspace configs are picked up and workspace links resolve. - The build script runs in the project root, so
apps/web/package.jsonsupplies thebuildscript when the root directory isapps/web. gigadrive.yamlis read from the project root. In a monorepo it belongs next to the application's ownpackage.json, not at the repository root. It can also be agigadrive.ts, which TypeScript configuration covers.
Package manager
Detection runs against the repository root, in this order. The first hit wins.
| Signal | Result |
|---|---|
packageManager in package.json | that manager, at that version |
devEngines.packageManager in package.json | that manager |
pnpm-lock.yaml | pnpm |
yarn.lock | yarn |
bun.lock or bun.lockb | bun |
package-lock.json or npm-shrinkwrap.json | npm |
a package.json and no lockfile | npm |
| no supported signal | install is skipped |
Installs are strict by default: pnpm install --frozen-lockfile, yarn install --immutable on Yarn 2 and later, bun install --frozen-lockfile, npm ci. When the strict command fails, the build retries it in its relaxed form, so an out-of-date lockfile does not fail the build on its own. Declaring a version, as in "packageManager": "pnpm@10.28.1", is what pins the tool; with no declaration, pnpm builds run pnpm 10.
A composer.lock (or a composer.json) additionally runs composer install --no-interaction for PHP projects.
The build script
If the project root has a package.json with a string scripts.build, the build runs it with the detected package manager. If it does not, the build logs that it is skipping the build step and moves on to packaging, which is what a plain static site wants. There is no console field for a custom build or install command.
What happens to the output depends on the framework. The build detects one from your dependencies and applies its defaults, including the entrypoint and the assets directory, so a Next.js or Laravel project needs no configuration at all. Frameworks lists what each one brings, and Configuration covers overriding it in gigadrive.yaml.
A project with neither a recognised framework nor a config file has one more path: if it looks like a static site, the platform writes an assets-only gigadrive.yaml for it and publishes the project root. If it does not look like one, the build stops with No config file found and no framework detected.
What gets uploaded
Only the Git route deploys exactly what is committed. The other two package your working directory, and each filters it differently.
| Route | What is left out |
|---|---|
| Git push or a console deploy | Anything not committed. The build fetches the commit itself, so .gitignore already decided. |
gigadrive deploy | Paths matched by .gitignore, .dockerignore, .nowignore, .vercelignore, and .gigadriveignore, at the project root and in subdirectories, plus .git/, node_modules/, .DS_Store, and Thumbs.db. Symlinks are not followed. |
| Drop | Any path with a segment named .git, node_modules, .next, dist, build, .turbo, .vercel, or .DS_Store. |
A detected framework contributes its own exclusions to the CLI archive. Which files end up inside a Function is a separate decision, made by that Function's includeFiles and excludeFiles in Configuration.
Files the platform writes
Two names belong to the platform. Do not commit either one. .gigadrive/ in your working directory holds the CLI's project link, so add it to .gitignore. .gigadrive/ inside a build holds adapter runtime files that are generated per deployment.