Command Reference

Previewops is driven by comments on GitHub pull requests. This page covers every available command and its options.


/deploy-previewops

Builds a Docker image from the PR branch and deploys a preview environment.

/deploy-previewops [options]

Options

Option Type Example Description
--ttl number (hours) --ttl=48 Override the TTL for this specific deploy. Must be within your plan's TTL maximum.
--resources small | medium | large --resources=medium Override the container resource preset for this deploy.
--dockerfile string --dockerfile=apps/web/Dockerfile Path to the Dockerfile relative to the repo root. Overrides dockerfilePath in .previewops.yaml.
--provider string --provider=fly Override the deployment provider for this deploy. Overrides provider in .previewops.yaml.
--perf flag --perf Immediately run a load test against the preview after deploy completes. Equivalent to having performance.enabled: true in .previewops.yaml but scoped to this single deploy.

Examples

/deploy-previewops
/deploy-previewops --ttl=24
/deploy-previewops --resources=medium
/deploy-previewops --provider=hetzner --ttl=48
/deploy-previewops --perf
/deploy-previewops --ttl=48 --perf

What happens

  1. Previewops checks capacity — if the concurrency limit is reached, the oldest preview is evicted.
  2. A Docker image is built using Cloud Build.
  3. The image is deployed to the configured provider.
  4. A PR comment is posted with the preview URL and TTL expiry time.

/delete-previewops

Immediately deletes the preview environment for the current PR.

/delete-previewops

No options. Previewops deletes the cloud resource and posts a confirmation comment.

Edge cases:


/validate-previewops

Validates your .previewops.yaml configuration and credentials without deploying anything. Useful for checking that credentials are correctly stored before your first real deploy.

/validate-previewops

Previewops will:

  1. Parse and validate your .previewops.yaml (if present).
  2. Check that credentials are stored for the configured provider.
  3. Reply with a success confirmation or a description of any issues found.

/qa-previewops

Runs a QA analysis on the current PR. What you get depends on your plan:

/qa-previewops [options]

Options

Option Type Example Description
--url string (https://) --url=https://preview-pr42.example.com Explicitly provide the preview URL to test against. When omitted, Previewops looks up the active preview for this PR automatically. Private/internal IP addresses are always rejected.

Examples

/qa-previewops
/qa-previewops --url=https://pr-42-preview.fly.dev

What happens

  1. Previewops posts a placeholder comment while analysis runs.
  2. Up to 300 changed files are fetched from the GitHub API (paginated).
  3. Each changed source file is mapped to its expected test file. Supported languages: TypeScript/JavaScript (src/X/Y.ts → src/__tests__/X/Y.test.ts), Python (test_X.py / X_test.py), Go (X_test.go in the same directory), Ruby (X_spec.rb/X_test.rb), and Java (XTest.java). Playwright (.spec.ts) and Cypress (.cy.ts) test files are also recognised. A fuzzy fallback handles provider subdirectories and cross-root test layouts.
  4. Eligible plans only: an AI model reviews the diff and produces: a summary with flagged issues, 3–6 HTTP smoke test scenarios, and regression risk areas.
  5. Eligible plans only: if a preview URL is available (via --url or the active preview for this PR), the generated HTTP scenarios are executed against it.
  6. The placeholder comment is updated with the final report.

On the Free plan, steps 4–5 are skipped and an upgrade prompt is included in the report. On Premium BYOC without the Custom LLM add-on, steps 4–5 are also skipped and a prompt to activate the add-on is shown instead.

See qa-testing.md for the full guide including language support, the report format, and FAQs.


alwaysOn — automatic deploys on push

Certain branches can be configured to deploy automatically whenever a push arrives and an open PR exists — no comment needed.

Add the branch names to .previewops.yaml:

alwaysOn:
  - staging
  - preview

When a push to a listed branch is received and a PR is open for that branch, Previewops automatically runs the equivalent of /deploy-previewops.


/perf-previewops

Runs a k6 load test against the active preview for this PR and posts a full results comment with latency percentiles, throughput, and SLO pass/fail. On eligible plans, AI-generated scenarios and post-run insights are included.

/perf-previewops [options]

Options

Option Type Example Description
--vus=N int --vus=50 Virtual users. Capped by your plan: Premium BYOC = 10, Pro = 50, Enterprise = 100, Custom = 150.
--duration=<time> string --duration=2m Test duration. Accepts 30s, 2m, 30m. Capped at 30 min (60 min with the Advanced Perf add-on).
--target-tps=N int --target-tps=100 Target requests per second.
--set-baseline flag --set-baseline Save this run as the baseline for future delta comparisons. Requires the Advanced Perf add-on (Pro / Enterprise / Premium BYOC).

Examples

/perf-previewops
/perf-previewops --vus=20 --duration=1m
/perf-previewops --set-baseline
/perf-previewops --vus=50 --duration=5m --target-tps=200

What happens

  1. Previewops looks up the active preview URL for this PR (or the URL from the most recent deploy if triggered via --perf).
  2. The plan VU and duration caps are applied — if the requested values exceed the plan limit, the test runs at the plan cap and a notice is shown.
  3. Endpoints are detected from the PR diff (all plans: regex; paid plans with LLM: AI-generated).
  4. A placeholder "running…" comment is posted immediately, then automatically updated with a live progress bar at 10 / 30 / 50 / 75 / 95 % milestones.
  5. A Cloud Build job runs grafana/k6 against the preview URL. Results are stored in GCS.
  6. When the load test finishes, the comment updates to "Analyzing results…" while AI analysis and database writes run.
  7. SLO thresholds from .previewops.yaml are evaluated (warnings only — never blocks the deploy).
  8. Paid plans with history enabled: the result is persisted and compared against the baseline (if one exists).
  9. Paid plans with LLM: AI analysis is generated and included in the results.
  10. The comment is updated with the full results including latency table, SLO status, baseline delta, and AI insights.

See performance-testing.md for the full guide including .previewops.yaml configuration and baseline tracking.


Who can trigger commands

Commands in PR comments are only processed from users with Write, Maintain, or Admin permission on the repository. Comments from users with Read-only access or no access are silently ignored.

Organisation owners and repository administrators always have permission.