Automatically deploy every pull request to its own preview URL using GitHub webhooks.
Preview environments spin up a live, isolated deployment for every pull request. Reviewers get a real URL to click instead of pulling the branch and running it locally. When the PR is merged or closed, the preview is torn down automatically.
The {{number}} template variable gets replaced with the PR number at deploy time.
Tip: Use a separate database for previews so they don't touch production data. You can create a shared preview database or let each preview use an ephemeral SQLite/in-memory database if your app supports it.
Preview environments consume server resources. A few things to keep in mind:
Expiry — set a reasonable expiry (default 7 days) so stale previews get cleaned up
Concurrency — by default, Vardo limits previews to 5 per app. Adjust under Preview Environments → Max concurrent
Resource limits — previews use the same resource limits as the parent app. Override them in preview settings if you want to give previews less CPU/memory
The PR targets the configured branch (usually main)
The GitHub App has access to the repo — check Settings → Integrations → GitHub
Webhook deliveries are succeeding — check your repo's Settings → Webhooks
Preview build fails
Open the preview's build log in Vardo. Common issues:
Missing environment variables — check your preview overrides
Branch has merge conflicts — resolve them in the PR
Dockerfile uses features the preview runner doesn't support
Preview URL shows 404
The preview container might still be starting. Give it a minute. If it persists, check the container logs — the app might be crashing on startup due to missing config.
"Too many preview environments"
You've hit the concurrency limit. Close old PRs or increase the limit under Preview Environments → Max concurrent.