Skip to content
launchroom

Deployments and previews

Push, and it's live.

Every push to your main branch becomes a new version on your server. launchroom builds it, starts it next to the running version and switches traffic once the new version answers.

Deployment 'fix: order totals with discounts' of the web service in production: Live, 1m 51s, built on vps-fra-1, with the steps Plan, Build, Roll out, Health check and Switch traffic all finished.Deployment 'fix: order totals with discounts' of the web service in production: Live, 1m 51s, built on vps-fra-1, with the steps Plan, Build, Roll out, Health check and Switch traffic all finished.

Builds

Builds from your repository as it is.

You don’t write a Dockerfile or a compose file. launchroom reads the repository, picks the build steps and builds on your build server. The result is an image in the built-in registry.
  • Detects Next.js, Laravel, Django, FastAPI, Node and static sites
  • Shows the build plan before it builds; you can override any step
  • Uses your Dockerfile when the repository has one
How builds work

Releases

When a release fails, the old one keeps serving.

A deployment never changes after it is created. If a new version doesn’t start, traffic stays on the current one, and the deployment page shows what went wrong.
  • Health checks run from outside the container
  • Replicas update one at a time
  • The failing step opens with the error line highlighted
When a build fails
Failed deployment 'chore: bump next to 16.1': a card explains the build failed because pnpm-lock.yaml is out of date, the site still serves the previous commit, and the build step shows the log excerpt with the ERR_PNPM_OUTDATED_LOCKFILE line highlighted.Failed deployment 'chore: bump next to 16.1': a card explains the build failed because pnpm-lock.yaml is out of date, the site still serves the previous commit, and the build step shows the log excerpt with the ERR_PNPM_OUTDATED_LOCKFILE line highlighted.

Previews

A full copy of your app for every pull request.

Open a pull request and launchroom deploys it next to production. Services you didn’t change reuse their existing image.
  • Its own URL and its own database
  • A status and a comment in the pull request
  • Behind a login or share link; pull requests from forks wait for approval
Previews
Previews page: a fork pull request #128 waiting for approval, and cards for PR #124 (Live, new empty database) and PR #119 (Deploying, database cloned from staging) with their preview URLs and expiry.Previews page: a fork pull request #128 waiting for approval, and cards for PR #124 (Live, new empty database) and PR #119 (Deploying, database cloned from staging) with their preview URLs and expiry.

Environments

Staging to production in one step.

Compare two environments, select the changes to bring over and promote them. Domains and secrets that belong to one environment stay where they are.
Environments and promotion

Details

Staged changes
Edits collect into one list. Review them, then deploy them together.
Instant rollback
Recent images are kept. Rolling back switches traffic to one of them.
Config as code
An optional launchroom.json in your repository, applied on push.
Git providers
GitHub, GitLab, Gitea, Forgejo and any git server over SSH.
Cron jobs
Schedules with a time zone. They run even while the dashboard is offline.
Templates and Compose
Start from a template or import a Compose file.

Install it on your server with one command.

curl -fsSL https://launchroom.vantezzen.io/install | sh