Reshotdocs

Quick Start

Reshot works best as a two-lane setup:

  • Local-first: get one real capture working on your machine
  • Hosted upgrade: publish that capture when you want stable URLs, review workflows, and dashboard visibility
Project dashboard
After your first hosted publish, the project dashboard summarizes recent activity, pending review, and the latest captures.

1. Install and initialize

Run on demand with npx (no install — matches the in-app onboarding):

Terminal
npx @reshotdev/screenshot@latest setup

Or install globally so the reshot command is always available:

Terminal
npm install -g @reshotdev/screenshot
reshot setup

reshot setup creates reshot.config.json and helps you choose whether to stay local-first for now or connect hosted delivery immediately.

2. Start from a minimal config

Before you record anything, here is a minimal scenario:

JSON
{
  "baseUrl": "http://localhost:3000",
  "scenarios": [
    {
      "key": "billing-overview",
      "name": "Billing Overview",
      "url": "/app/billing",
      "steps": [
        { "action": "wait", "ms": 1000 },
        { "action": "screenshot", "key": "billing-overview" }
      ]
    }
  ]
}

If you want help creating the scenario, use the recorder:

Terminal
reshot record "Billing Overview" --browser

If you already have the scenario defined in reshot.config.json, skip recording and go straight to reshot run.

3. Get first value locally

Run the app with a production-like local server rather than next dev:

Terminal
npm run build
npm run start

Then run the capture:

Terminal
reshot run

Inspect the output locally before you involve hosted delivery or CI.

4. Inspect the output

Open Studio to review the generated assets locally:

Terminal
reshot studio

5. Upgrade to hosted review and delivery

Once the local capture looks right, publish it:

Terminal
reshot publish

Publishing gives you:

  • hosted asset URLs
  • dashboard visibility
  • review workflows
  • GitHub PR comments when you connect the GitHub App

Advanced reliability checks

Certified Targets are an advanced layer, not a requirement for first-run success. When your main capture path is already working, you can use:

Terminal
reshot doctor target
reshot verify publish
reshot certify

Keep the first setup narrow

For most teams, the standard path is enough:

  1. get one real page capture working
  2. verify it against a production-like local server
  3. publish only after the local result looks right

Only add extra configuration when you actually need it:

  • Read Scenarios when you need more than one stable page capture
  • Read Capture Types when you need workflow-style output
  • Read Variants only if your product needs multiple capture contexts
  • Read Cropping only if a tighter frame is clearly better than the full page

What next