Documentation

Getting started

Create an account, add the URL of your live app and run a check. Passive checks run right away on any public URL. Active checks and load tests require domain verification.

A check takes about a minute. You receive an email when it is done, and the report stays available in your dashboard.

Verify your domain

Verification proves you control the domain. Pick any one of the three methods; your personal token is shown on the project page.

1. Verification file

Serve a plain-text file at this path containing exactly your token:

launchcheck-verify=3f9a…your-token

2. DNS TXT record

Add a TXT record on your domain (or on the _launchcheck subdomain) with your token as the value. DNS changes can take a few minutes.

your-app.com.   TXT   "launchcheck-verify=3f9a…your-token"
# or
_launchcheck.your-app.com.   TXT   "launchcheck-verify=3f9a…your-token"

3. Meta tag

Add this tag inside the <head> of your home page:

<meta name="launchcheck-verify" content="launchcheck-verify=3f9a…your-token" />

Then click "Verify" on the project page. Verification is checked again before every active test.

Reading a report

The score goes from 0 to 100 and the verdict summarizes it: Ready (85 and above with no high-priority issue), Caution (60 to 84 or at least one high-priority issue) and Not ready (below 60 or any critical issue).

Each issue has a severity, a plain-language explanation, the evidence we found and a fix prompt. Mark an issue as fixed or ignored; ignored issues stay hidden in future checks of the same app.

Critical

Data or money at risk right now (exposed secret, public database, leaked .env). Fix before anything else.

High

Visitors are affected or you are losing money (test-mode payments, errors under load, no title).

Medium

Degrades the experience or trust (slow server, broken links, missing policy).

Low / Info

Good hygiene and small details.

Load tests

A load test sends simulated visitors to your app for a chosen duration and measures response times and errors. Start with 10 to 25 visitors for 30 seconds, then increase.

Rule of thumb: 50 simultaneous visitors is roughly what a content site sees with 75 000 visits a day. The result is a verdict (held, slowed down, broke) plus recommendations with fix prompts.

Tests run from our built-in runner by default. Larger tests can be routed to external providers (Grafana Cloud k6, loader.io) when configured.

Public API

Available on the Pro and Agency plans. Create a key in Settings → API keys and send it as a Bearer token. Base URL:

https://vibeappguard.com/api/v1

Authentication

Authorization: Bearer lc_xxxxxxxxxxxxxxxxxxxxxxxx

Endpoints

• GET

  /api/v1/projects

  List your apps.

• POST

  /api/v1/projects

  Add an app. Body: '{ name, url }'. Returns the verification token.

• GET

  /api/v1/checks?projectId=…

  List checks.

• POST

  /api/v1/checks

  Start a check. Body: '{ projectId, modules?, load?: { virtualUsers, durationSec }, wait?: boolean }'. With wait: true the request blocks until the report is ready.

• GET

  /api/v1/checks/{id}

  Get a check with its findings.

• POST

  /api/v1/load-tests

  Start a standalone load test. Body: '{ projectId, virtualUsers, durationSec, rampUpSec?, region?, scenario?, wait? }'.

• GET

  /api/v1/load-tests/{id}

  Get a load test.

Rate limit: 120 requests per minute per account. Errors come back as { error: { code, message } }.

Example: start a check and wait for the result

curl -X POST https://vibeappguard.com/api/v1/checks \
  -H "Authorization: Bearer $LAUNCHCHECK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "projectId": "clx…", "modules": ["SECURITY","PERFORMANCE","FLOWS","SEO","LEGAL"], "wait": true }'

# → 200 { "data": { "id": "…", "score": 78, "verdict": "RISKY", "findings": [ … ] } }

Webhooks

Register an HTTPS URL in Settings → Webhooks. We POST a JSON payload for the events check.completed, check.failed, load.completed and alert.regression.

Every request carries the header x-launchcheck-signature with the HMAC-SHA256 of the raw body using your webhook secret. Verify it before trusting the payload:

import { createHmac, timingSafeEqual } from "node:crypto";

export function verifyLaunchCheck(rawBody, signatureHeader, secret) {
  const expected = "sha256=" + createHmac("sha256", secret).update(rawBody).digest("hex");
  return timingSafeEqual(Buffer.from(expected), Buffer.from(signatureHeader ?? ""));
}

// Payload shape
// { "event": "check.completed", "createdAt": "…", "data": { "checkId", "projectId", "score", "verdict", "counts", "shareUrl" } }

CI/CD example (GitHub Actions)

Run a check after every production deployment and fail the job when the app is not ready. The verdict is in the response, so you decide what blocks your pipeline.

name: VibeAppGuard
on:
  deployment_status:
jobs:
  readiness:
    if: github.event.deployment_status.state == 'success' && github.event.deployment_status.environment == 'Production'
    runs-on: ubuntu-latest
    steps:
      - name: Run VibeAppGuard and wait for the report
        env:
          LAUNCHCHECK_API_KEY: ${{ secrets.LAUNCHCHECK_API_KEY }}
          PROJECT_ID: ${{ vars.LAUNCHCHECK_PROJECT_ID }}
        run: |
          RESPONSE=$(curl -sS -X POST https://vibeappguard.com/api/v1/checks \
            -H "Authorization: Bearer $LAUNCHCHECK_API_KEY" \
            -H "Content-Type: application/json" \
            -d "{\"projectId\":\"$PROJECT_ID\",\"wait\":true}")
          echo "$RESPONSE" | jq '.data | {score, verdict}'
          VERDICT=$(echo "$RESPONSE" | jq -r '.data.verdict')
          if [ "$VERDICT" = "NOT_READY" ]; then
            echo "::error::VibeAppGuard verdict is NOT_READY"
            echo "$RESPONSE" | jq -r '.data.findings[] | select(.severity=="CRITICAL" or .severity=="HIGH") | "- [\(.severity)] \(.title)"'
            exit 1
          fi