Deploying from the Web App

Most Previewops deploys start as a /deploy-previewops comment on a pull request. You can also start one from the dashboard, without opening GitHub.

Both routes run the same pipeline. Deploying from the dashboard posts the same /deploy-previewops command against the pull request you select, so the build, PR comment, preview URL, and TTL all behave identically. It is a different door into one deploy path, not a second one.

Terminology: in the command docs, "dashboard" usually means the preview dashboard comment posted on your PR. On this page it means the Previewops web app.

When to use it

• You are already in the dashboard and don't want to switch to GitHub to type a comment.
• You want to deploy to a specific named credential profile and would rather pick it from a list than remember its --name= value.
• You are redeploying something you can see in the Previews table.

Use a PR comment for options the wizard does not expose, including --ttl, --commit, and --resources. The wizard covers the common deployment path and, when the Preview DB add-on is active, its database options. See commands.md for the full flag reference.

Before you start

1. Cloud credentials must be stored. The wizard offers you providers that have credentials saved — with none stored, the provider step is empty and links you to the Credentials page. See credentials.md.
2. The pull request must be open. Closed and merged PRs are rejected; deploy from a reopened PR or a new one instead.
3. The GitHub App must be installed on the repository. Repos the App cannot reach do not appear in the repository picker.

Deploying

Go to Previews in the sidebar and click Deploy new preview. The wizard has up to four steps; the credential-profile step is skipped when no profile selection is required.

Step 1 — Repository

Search across every repository the GitHub App can reach for your org. Repositories are listed alphabetically and show when they were last updated.

If a repository is missing, the App is not installed on it. That is a GitHub permission, changed from your organisation's GitHub App settings rather than from Previewops.

Step 2 — Provider

Pick the platform to deploy to. Only providers with stored credentials are shown.

If your repository has a provider: set in .previewops.yaml, choosing a different provider here overrides it for this deploy — the same way --provider= does on a PR comment.

Step 3 — Credentials

Choose which stored credential profile to deploy with. Orgs with a single set of credentials have one option preselected; teams using separate, dedicated preview accounts can choose between named profiles here. Use least-privilege credentials intended for preview workloads rather than production credentials.

This is the equivalent of --name= on the comment form.

Step 4 — Pull request

Enter the number of the open pull request to deploy. Previewops verifies that the PR exists and is open, posts the deploy command on it, and queues the build.

If the Preview DB add-on is active, this step also lets you choose between an isolated Preview DB branch and the configured DATABASE_URL. You can optionally enter a Preview DB branch alias. These controls correspond to the --database and --db-branch command options; see databases.md.

After it is queued

You will see a Build queued confirmation. From there:

• The deployment-progress sidebar updates while the build runs. After deployment succeeds, the Previews table adds or refreshes the preview row automatically — no page refresh is needed.
• The pull request gets the same "Building Previewops environment…" comment, updated with the preview URL when the deploy completes.
• Typical end-to-end time is 2–8 minutes, mostly Docker build time.
• Fly.io is the exception. It builds on a Docker-in-Docker builder machine created in your own org for each build, so allow 5–15 minutes for a first build and 2–5 minutes once layers are cached. See Fly build times.

If the build fails, the PR comment carries the error and build logs, exactly as it would for a comment-triggered deploy. Run /validate-previewops on the PR to check credentials and configuration without deploying.

Redeploying and deleting

Each row in the Previews table has actions to open, redeploy or delete that preview.

• Redeploy rebuilds from the current PR head using the same provider, named environment, credentials, and database selection.
• Delete tears the preview down immediately and frees a concurrency slot, rather than waiting for the TTL to expire.

Deleting from the dashboard removes only the selected preview. By contrast, running /delete-previewops without a --provider or --env filter removes every active preview for that PR.

Permissions

Deploying and deleting are available to org admins and members. Storing credentials is admin-only — if the Credentials page is read-only for you, ask an org admin to add them. See team-access.md.

Related pages

• commands.md — full /deploy-previewops flag reference
• credentials.md — storing and naming cloud credentials
• getting-started.md — your first deploy end to end
• configuration.md — .previewops.yaml options