Diagnose deploy and AI-build errors, then ship the fix.

You need three minutes and the URL of one failing build or preview. No CLI, no SDK.

1. Sign in at deploydoc.com/login with Google or email.
2. Open Run a diagnosis and paste a preview URL, a build log, or a raw error message.
3. Wait ~20 seconds. DeployDoc returns a ranked report: root cause, affected files, and the smallest patch that fixes it.
4. If your code lives on GitHub, click Open fix PR and review the diff in your repo.

Three input modes are accepted on /diagnose:

• Preview URL — any public preview (Vercel, Netlify, Cloudflare Pages, Lovable, Railway). DeployDoc loads the page, captures runtime errors, console output and failing network requests.
• Build log — paste the raw output from vercel build, netlify deploy, GitHub Actions or Lovable's chat.
• Stack trace / error — a single error message from your IDE, terminal or browser console.

You can also start a scan from /env-scanner — that flow inspects the environment variables a project references vs. the ones actually set, so missing keys surface before you redeploy.

A report has four blocks. Read top-to-bottom; the top block is what you fix first.

• Root cause — one sentence, plain English. No stack traces.
• Evidence — the exact log lines, failed requests or env keys that prove it.
• Suggested fix — a diff against your repo, or a deploy-side change (env key, build command, redirect rule).
• Related findings — secondary issues that did not cause this failure but will bite you next.

Every finding ships with a confidence score from 0–100.

• 85–100 — direct evidence in the log or DOM. Safe to auto-PR.
• 60–84 — strong pattern match (e.g. a known Next.js + Supabase misconfig). Review the diff before merging.
• 0–59 — heuristic. Use as a starting hypothesis; the report links to the docs section that explains the failure mode.

The PR bot will only auto-open a PR for findings ≥ 85 unless you flip Open PRs for medium confidence in Account settings.

Every Lovable project exposes a preview URL of the form:

https://id-preview--<project-id>.lovable.app

Copy it from the top-right of the Lovable editor and paste into /diagnose. DeployDoc opens the preview headlessly, replays a real navigation, captures runtime errors, and reads any inline error overlays Lovable injects on build failure.

If your Lovable project uses Lovable Cloud (managed Supabase), open /connect → Lovable and paste the project ID. DeployDoc never reads your data — only the schema names, RLS policy names, and the list of declared environment variables.

This unlocks two checks:

• Missing env keys — keys referenced in code but not declared in Cloud.
• RLS gaps — tables exposed via the Data API that have RLS disabled or no policies.

DeployDoc compares process.env.* / import.meta.env.* references in your bundle against the keys declared in Lovable Cloud. The output looks like:

Missing in production:
  STRIPE_SECRET_KEY          referenced in src/lib/stripe.functions.ts:14
  RESEND_API_KEY             referenced in src/routes/api/public/email.ts:8

Set but unreferenced:
  OLD_SENDGRID_KEY           safe to remove

Only key names ever leave the sandbox. Values are never read or stored.

Lovable projects sync to GitHub by default. Once you've connected GitHub on /connect, the Open fix PR button on any report will:

1. Create a branch deploydoc/<report-id>.
2. Apply the suggested diff.
3. Open a PR against your default branch with the report linked in the description.

Lovable picks up the merged PR on its next sync — no extra step on the Lovable side.

Go to Settings → MCP and generate a token. Then add this block to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%/Claude/claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "deploydoc": {
      "url": "https://mcp.deploydoc.com",
      "transport": "http",
      "headers": {
        "Authorization": "Bearer <your-mcp-token>"
      }
    }
  }
}

Restart Claude Desktop. The server exposes three tools: diagnose, scan_env, and open_pr.

The first time Claude calls a tool, you'll see a single consent prompt asking which DeployDoc workspace the token can act on. Tokens are workspace-scoped — rotate or revoke them anytime from /settings/mcp.

In any Claude chat:

/diagnose https://id-preview--abc123.lovable.app
/diagnose --log "$(pbpaste)"
/diagnose --error "TypeError: Cannot read properties of undefined (reading 'id')"

Claude streams the report inline and offers to call open_pr if you've also connected GitHub.

The MCP transport is HTTP+SSE — partial findings arrive as soon as they're confident, so Claude can start explaining the root cause while DeployDoc is still scanning for related issues. Total time is the same; you just see results sooner.

Visit /github and click Install on GitHub. You'll be redirected to the GitHub App install flow. Choose between All repositories or Select repositories. Only repos you grant access to are visible to DeployDoc.

Required permissions:

• Contents · read & write — to read source and create fix branches.
• Pull requests · read & write — to open PRs.
• Metadata · read — required by GitHub for all apps.

DeployDoc does not request Actions, Secrets or Admin scopes.

You can change the repository list any time from github.com/settings/installations → DeployDoc → Configure. Newly granted repos show up on /github within a minute.

From any report, click Open fix PR. The PR title is the root-cause sentence; the body includes the evidence block, the diff explanation and a link back to the report. Reviewers see a checklist of what to verify before merging.

If you'd rather review locally, click Copy patch to get a git apply-compatible diff.

Connect on /connect with a Vercel token (Settings → Tokens → Create, scope: full account or a single team).

What DeployDoc reads:

• The last failed deployment per project — build log, framework preset, Node version.
• Declared environment variables (names only).
• Project-level redirects and rewrites.

Common fixes DeployDoc auto-detects: missing VERCEL_URL, output: "standalone" mismatch, Edge-runtime imports of Node-only packages.

Connect with a Netlify personal access token (User settings → Applications → New access token).

Auto-detected issues: missing _redirects for SPA routing, build image mismatch (NODE_VERSION not pinned), Functions exceeding the 50 MB bundle limit.

For Cloudflare Pages and Workers, paste the failing deployment URL into /diagnose. Token-based connect is not required — DeployDoc reads the public build log via the deployment URL.

Auto-detected: nodejs_compat flag missing, use of Node-only npm packages, __dirname in Worker code.

Connect with a Railway API token (Account → Tokens). DeployDoc reads service logs and the env-variable manifest for the connected project.

Auto-detected: missing PORT binding, Nixpacks builder picking the wrong start command, Postgres connection-string format errors.

Paste the public deployment URL into /diagnose. Token connect is on the roadmap; until then DeployDoc reads the build log via the deploy URL.

Auto-detected: free-tier instance sleeping mid-build, npm ci failing when package-lock.json is absent.

Symptom: payments succeed in Stripe but your DB never updates. DeployDoc checks for the four common causes:

1. Webhook endpoint returns 401 because the route requires auth — it shouldn't.
2. Signature verification reads the parsed JSON body instead of the raw body.
3. The endpoint secret used in code is from a different Stripe environment.
4. The webhook is subscribed to the wrong event types.

// Correct pattern (TanStack Start server route)
const body = await request.text();
const sig = request.headers.get("stripe-signature")!;
const event = stripe.webhooks.constructEvent(body, sig, process.env.STRIPE_WEBHOOK_SECRET!);

Symptom: users sign in but the next page renders signed-out. DeployDoc looks for:

• Site URL / Redirect URLs not including your production domain.
• Server function calling supabase.auth.getSession() in an isomorphic loader (returns null on the server).
• Missing client-side bearer attacher when a server fn uses requireSupabaseAuth.

Symptom: post-sign-in lands on /sign-in instead of your app. Usually NEXT_PUBLIC_CLERK_SIGN_IN_FALLBACK_REDIRECT_URL is unset, or middleware matchers exclude the destination. The report shows the exact middleware.ts diff.

Symptom: InvoiceURL 200s in test but returns InvalidApiKey in live. Causes DeployDoc flags:

• Using the sandbox base URL (apitest.myfatoorah.com) with a live key.
• Country-specific endpoint mismatch (KSA key against KWT endpoint).
• Webhook IP allowlist blocking MyFatoorah's production range.

Symptom: charges authorize but never capture. DeployDoc checks for source.id = src_all on a non-3DS test card, the post.url webhook returning non-200, and signature header (hashstring) not being recomputed from the raw payload.