Deployment Guide

Learn how to deploy applications on Launchverse. Every deploy is built by

Forge, our own build engine — for the full pipeline (detection, installs,

monorepos, environment) see How Builds Work (Forge).

Auto-Deploy from GitHub

Connect your GitHub repository and every push to your production branch

triggers an automatic deployment. The Launchverse GitHub App sends webhook

events that we use to kick off builds.

Workflow:

1. Push code to your connected repository.
2. Launchverse receives the push event and starts a build on Forge.
3. Framework detection determines the build recipe.
4. Dependencies are installed with a lockfile-aware, package-manager-aware step.
5. The application is built and started in an isolated container.
6. HTTPS certificates are issued and DNS is configured.
7. Your app goes live at its URL.

Branch behavior

1. Pushes to your production branch deploy to production.
2. Pushes to a branch with an open pull request deploy to a

preview environment.

1. Pushes to other branches do not deploy.

Each push is built fresh from that commit — code changes, dependency/lockfile

changes, and configuration changes are all reflected on every build.

Manual Deployments

You can also trigger deployments manually:

1. From the dashboard, redeploy the latest commit at any time.
2. Via the deploy hook URL found in your project settings — a unique,

secret URL you can call from CI or a cron job to trigger a build.

Build Configuration

Override any part of the auto-detected build recipe (the build contract)

from Project → Settings:

1. Build Command — override the auto-detected build command.
2. Install Command — override dependency installation. Leave it blank to

let Forge pick the correct lockfile-aware install (npm, pnpm, Yarn, Bun)

with a safe fallback. An explicit command always wins — so only set this if

you really want to pin the exact install behavior.

1. Output Directory — where built assets are served from.
2. Root Directory — if your app lives in a subdirectory of the repository

(subdirectory monorepos are supported on every plan).

Environment Variables

Set build-time and runtime environment variables in your project settings.

Variables you add while creating a project reach your very first build and

the running app — no extra redeploy needed. See

Environment Variables & Secrets for

build-time vs. runtime scoping and secret masking.

After a deploy

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

back a bad release. You can also roll back manually or promote a preview to

production — see Rollback & Promote.

1. Inspect or debug the running container any time with the

Web Shell.