Reshot

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

1. Install and initialize

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": [
    {
      "name": "billing-overview",
      "steps": [
        { "action": "goto", "url": "/app/billing" },
        { "action": "capture", "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
Studio Scenarios List
Studio showing recorded scenarios and their latest local run status after a local-first capture

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

Quick Start | Reshot Docs