How Builds Work (Forge)

Every deploy on Launchverse is built by Forge — our own build engine.

Forge takes a commit from your repository and turns it into a running,

isolated app on our infrastructure. The same engine powers both your

production deploys and your pull-request previews, so **what you preview is

exactly what ships**.

The pipeline, end to end

1. Trigger. A push to your production branch, an open/updated pull

request, a manual deploy, or a deploy-hook call kicks off a build.

1. Fetch. Forge checks out the exact commit that triggered the build.
2. Detect. Forge inspects your repository to determine the framework and

the right build recipe (see Framework detection below).

1. Install. Dependencies are installed with a lockfile-accurate,

package-manager-aware step (see Package managers).

1. Build. Your build command runs and produces the application artifact.
2. Release. The artifact starts in an isolated container, HTTPS

certificates are issued, DNS is wired up, and your app goes live.

1. Verify. A post-deploy health probe watches the live URL and can

auto-roll-back a bad release (see Rollback & Promote).

Each build is a clean build from the triggering commit — code, dependency,

and configuration changes are all reflected every time. Builds run in

isolation, and your environment values are never written into build logs.

Framework detection

Forge recognizes your stack from the files in your repository and applies a

purpose-built recipe for it, including:

1. Next.js and other Node.js web frameworks
2. Static sites (any build that emits a folder of static assets)
3. Bun projects
4. Cloudflare Workers and modern edge targets

You don't have to configure any of this for the common case — detection is

automatic. When you need to override it, use the build contract below.

Package managers

Forge detects your package manager from your lockfile and installs the way

that manager expects:

1. npm (package-lock.json)
2. pnpm (pnpm-lock.yaml)
3. Yarn (yarn.lock)
4. Bun (bun.lockb)

Leave the install command blank and Forge picks the correct

lockfile-aware install automatically, with a safe fallback if the strict

install can't complete. If you type your own install command, it always

wins. This is why you should not hard-code npm install unless you mean

it — an explicit npm command overrides Forge's smarter, manager-aware

install (and would run npm even on a Bun or pnpm project).

Build contract (overrides)

You can override any part of the recipe from Project → Settings:

1. Install command — replace the auto-detected install step.
2. Build command — replace the auto-detected build step.
3. Output directory — where built/static assets are served from.
4. Root directory — build an app that lives in a subdirectory of the

repository (see Monorepos).

Leave a field blank to keep Forge's automatic behavior for that step.

Environment variables

Environment variables you set are available to the build and to the running

app according to their scope. Variables added while you create a project

reach your very first build and the running container — no extra

redeploy or restart needed. See

Environment Variables & Secrets for

build-time vs. runtime scoping and masking.

Monorepos

Forge supports subdirectory monorepos on every plan: point the

Root directory at the app's folder (for example apps/web) and Forge

builds that subdirectory in isolation, as if it were the repository root.

Workspace monorepos — where an app depends on sibling packages and the

install must resolve across the whole workspace from the repository root

(pnpm/Yarn/Turbo/Nx workspaces) — are an Enterprise capability. If you're

on another plan and your build needs cross-package workspace resolution,

upgrade to Enterprise or restructure the app to build in isolation from its

own directory.

Repository names

Forge normalizes repository names that contain unusual characters — trailing

dots, spaces, or special characters — so projects with those names build

cleanly instead of failing with a naming error. No action is needed on your

part.

Build parity for previews

Because previews and production both build on Forge, a pull-request preview

exercises the same engine, recipes, installs, and framework support as the

production deploy. A feature that builds in your preview will build in

production — there is no second, different builder to surprise you at release

time.