Deploying Your Project

How push-to-deploy, manual deploys, zero-downtime releases, instant rollback, and build/runtime logs work on Launchpad.

Push-to-deploy

Once a project is imported, every push to its tracked branch (usually main) triggers a build automatically. You'll see build status posted directly to your commit/PR on GitHub as a check, so you know immediately whether a push built successfully.

Manual deploys

You can also trigger a deploy manually from the project's dashboard, or via the launchpad-cli deploy command (see The Launchpad CLI).

Zero-downtime deploys

When a new deploy starts, Launchpad builds the new version and health-checks it before switching any traffic over. Your previous version keeps serving live requests the entire time. Only once the new version responds successfully is traffic moved to it -- if the new build fails its health check, your site keeps running on the last working version and the deploy is marked failed. This means a bad deploy never takes your site offline.

Rollback

Every deployment records the exact image it built. If a deploy causes a problem, you can instantly roll back to any previous deployment from the Deployments tab -- this reuses the already-built image rather than rebuilding from source, so it's fast, and it goes through the same zero-downtime swap as a normal deploy.

Build logs

Each deployment's full build output is available from the Deployments tab, so you can see exactly what happened if a build fails.

Runtime logs

Once a project is running, its live stdout/stderr output (the last 300 lines) is available under the Logs tab -- useful for debugging application errors without needing server access.