Auto-Deploy from GitHub on Launchverse: Push to Production in Seconds

The "modern" deployment pipeline has converged on a simple promise: you push code, the platform takes it from there. No YAML pipelines, no self-hosted runners, no operators paging Slack at 02:00. Launchverse gives you that out of the box, with a fair amount of nuance hiding under the surface.

This guide walks through the full flow: connecting GitHub, configuring auto-deploy, branch-based environments, preview URLs, and the rollback story when things go wrong.

1. Connect GitHub once, deploy forever

The Launchverse GitHub App handles the connection. Authorise it once for your account or organisation, choose which repositories it can read, and you're done. The app installs a webhook on each connected repo; pushes to a watched branch trigger a build automatically.

You don't need to add a .github/workflows/deploy.yml. You don't need to configure a CD-only token. The connection is owned by Launchverse and scoped to the repos you allow.

2. Pick the trigger branch

Each Launchverse project deploys from one branch by default — usually main or master. When you push to that branch, a build starts within seconds. The build pipeline:

1. Fetches the latest commit.
2. Detects the framework (Node, Python, Go, Ruby, PHP, Java, Rust).
3. Runs the install / build / start sequence for that framework.
4. Spins up a new container alongside the old one.
5. Waits for healthcheck to pass.
6. Routes traffic to the new container.
7. Drains and stops the old container.

If any step fails, the rollout aborts and the old container keeps serving. Your production stays up.

3. Branch-based environments

Real teams need more than just main = production. The standard pattern:

On Launchverse, each non-production branch can be its own project — a clean separation of resources and config. Or you can enable PR previews: every open pull request gets an ephemeral preview URL that auto-rebuilds on each push and tears down when the PR is merged or closed.

4. Per-PR preview URLs

When PR previews are enabled on a project, every pull request opened against the trigger branch:

1. Spawns a temporary deployment with a unique URL (e.g. pr-42-app.launchverse.app).
2. Inherits the project's environment variables (with optional overrides per PR).
3. Comments the preview URL on the PR for reviewers.
4. Auto-redeploys on every push to the PR branch.
5. Tears down within a minute of the PR being merged or closed.

This is the single biggest team accelerator on a small team. Reviewers see exactly what would ship before approving — not a screenshot, not a description, the running application with their own data.

5. Status checks back to GitHub

Launchverse posts deploy status as a GitHub status check on each commit. You can require it to pass before merging, the same way you'd require lint or tests to pass. The check shows:

• Pending while the build is running.
• Success when the deploy succeeded and the new container is healthy.
• Failure if the build, test, or healthcheck failed — with a link straight to the failed deploy log.

In repository settings, mark "Launchverse / deploy" as a required status check on the trigger branch and stale code can never reach production.

6. Rolling back

The fastest rollback in the world is "redeploy the last known-good build." Every successful deploy is preserved — click "Redeploy" on it from the Deployments tab and Launchverse rebuilds and ships that exact commit. No git revert, no force-push, no merge mess.

For pathological cases (database migration that broke compatibility), a forward-fix is usually safer than a rollback. The platform doesn't downgrade your database for you; it just rebuilds your app code.

7. The "deploy hooks" escape hatch

For pipelines that aren't a git push — manual triggers, scheduled redeploys, or external CI systems — Launchverse exposes per-project deploy hooks. They're long-random URLs you POST to (with no body) to start a build, and you can rotate or expire them at any time.

curl -X POST https://launchverse.app/api/projects/<project-id>/deploy-hooks/<token>

Use cases:

• A nightly redeploy via cron to apply patched base images.
• An external CI system that only emits webhook calls.
• A "build now" button in your internal admin panel.

8. What you don't need

People migrating from a self-managed pipeline often ask: "where do I configure my GitHub Actions workflow for this?" You don't. Launchverse handles the build, deploy, and health-check transitions natively. Reserve GitHub Actions for things it's actually good at — running unit tests, linting, security scans, and reporting status checks back to PRs.

A reasonable end-state pipeline:

GitHub Actions stays in your repo, runs on PRs, gates merges. Launchverse handles the actual production deploy. The two layers don't overlap; they complement.

Common pitfalls

• Build hangs. Most "stuck" builds are a missing start script or a build that emits to a non-default directory. The build log surfaces both immediately.
• Preview URLs leak previews. By default preview URLs are publicly accessible — fine for marketing previews, dangerous for staging that uses prod data. Use the Security tab's basic-auth toggle to lock previews behind a password.
• Healthcheck flaps. If you deploy and immediately rollback, your healthcheck is too aggressive. Increase the healthcheck timeout (default: 30s) or relax the path to a cheaper endpoint (/healthz instead of /).

Further reading

• Deploy a Next.js app on Launchverse without Vercel
• Zero-downtime deployments on a modern PaaS
• Production observability without Datadog