RunThru docs

RunThru turns a pull request into a narrated walkthrough video and checks that the feature works. This page covers the hosted GitHub app: how to trigger it, point it at your preview, and read what it posts.

Quickstart

1. Install the RunThru Video GitHub app and choose the repositories it can see.
2. Open a pull request that has a deploy preview (Vercel, Netlify, Render, Cloudflare Pages and others).
3. Comment /runthru. RunThru reacts to your comment, then posts a comment of its own that turns into the video about 5 to 8 minutes later.

Want to see the result first? Every open pull request in the public demo repository has one.

Comment commands

Comment on any pull request in a repository where the app is installed. Only owners, members and collaborators can trigger a run.

Comment again after a new push, or with new direction, and the same RunThru comment updates with the new cut. The QA review often suggests the direction to give, for example “zoom out so the goal ring is in frame”.

How it finds previews

RunThru looks for a deployment on the pull request's head commit, the way GitHub shows it in the pull request's checks and deployments. Vercel, Netlify, Render and Cloudflare Pages previews are picked up automatically, along with other providers that report deployments to GitHub.

If it can't find one, it says so on the pull request and suggests what to do:

• Comment /runthru https://your-preview-url with the URL.
• If your preview URLs follow a pattern, add url: to .runthru.yml.
• For a plain static site, add static: <folder> and RunThru serves that folder of the pull request's commit. No build step runs.

.runthru.yml

Optional. Put it at the root of the repository. Every key is optional.

url: https://pr-{number}.preview.example.com   # {number} {branch} {sha} {short_sha}
static: public                                 # or serve this folder of the PR's commit
start: /dashboard
prompt: Sign in with the demo account, then open billing
viewport: 1440x900
dark: true
test_data: email demo@example.com, password demo-pass
vercel_bypass: <Protection Bypass for Automation secret>   # private repos only
notify: off                                    # keep this repo out of Slack, or "attention"

Cuts, 4K, colors, voice and music

On Pro and Team, a few more keys in .runthru.yml change what the video looks and sounds like. Every key is optional.

formats: square, vertical                      # 1:1 and 9:16 cuts next to 16:9
quality: 4k                                    # 16:9 at 3840×2160
accent: "#0c7d43"                              # highlights, click ripples, progress bar
background: "#0b1020, #1e1b4b, #4c1d95"        # one to three gradient colors
voice: Sarah                                   # the narrator
music: true                                    # a quiet music bed under the voice

Paid videos also leave the “Made with RunThru” line off the end card. Extra cuts and 4K take longer to render: a run that asks for either can take 10 to 20 minutes, and the 16:9 cut is reviewed before the other cuts are made.

If a setting can't be honored (a voice that doesn't exist, music that couldn't be made), the video is still made and the comment says what was left out. On the Free plan these keys are ignored, and the comment says which ones need Pro.

Logins and protected previews

Your app's own login

Add a demo account as test_data and tell the agent how to sign in with prompt. Use an account that only exists on previews or staging.

Vercel Deployment Protection

If previews sit behind Vercel Authentication, RunThru's browser only sees Vercel's login page. Either comment /runthru <a public URL that has this change>, or create a Protection Bypass for Automation secret (Vercel, Project, Settings, Deployment Protection) and, in a private repository, add it to .runthru.yml as vercel_bypass.

Bot protection

Sites behind a firewall challenge block automated browsers on purpose. Film the preview or staging deployment instead of production.

What you get

One comment per pull request, updated on every run:

• A title and one-line summary of the feature.
• A GIF preview that opens the video's share page (the MP4 is 1920×1080 with voice and captions).
• Share links: the page, an email with the link filled in, and the MP4.
• Chapters with timestamps.
• The QA verdict: a score out of 10, whether the feature works, a short summary, and a table of timestamped issues with suggested fixes. App errors are listed first.
• A full transcript.

Videos are hosted by RunThru. Nothing is committed to your repository.

The RunThru check

Each run also posts a check named RunThru on the pull request's head commit, next to CI. It shows as in progress while RunThru films, then completes with the verdict, the QA score, a link to the video, the chapters and the top three issues with timestamps. Its details link opens the comment.

• Success: the feature visibly worked.
• Failure: the feature didn't work, and a second check of the captured page confirmed it.
• Neutral: the reviewer and the second check disagree, there was no preview to film, or the run failed on RunThru's side. Neutral doesn't block a merge, so a RunThru problem never holds up yours.

To require it, open the repository's Settings, then Branches (or Rules → Rulesets), and add RunThru to the required status checks for your default branch. The check appears in that list after RunThru has run once in the repository. RunThru runs only when someone comments /runthru, so a required check waits for that comment.

Share, email and Slack

The share page

Every finished video has its own page at runthru.co/v/…, linked from the walkthrough comment. It has the player, chapters you can jump to, the verdict with its issues, and the transcript. Anyone with the link can watch, with no GitHub access and no RunThru account, so it works for product, design, sales and customers.

• Copy link for a ticket, a doc or a chat. The link unfurls with the poster, the title and the verdict.
• Email opens a new message in your own mail app with the title, link and verdict filled in. You choose who gets it.
• Download saves the MP4. When a run has square and vertical cuts, the page switches between them.

Share pages are unlisted: the address is random, and search engines are told not to index them.

Slack notifications

RunThru can post each finished video to a Slack channel: the title, the verdict, a short summary, the top issues, an animated preview, and links to watch it or open the pull request. Setup takes about a minute and needs no login.

1. Open runthru.co/connect. Paste the channel's incoming webhook URL (in Slack, add the Incoming Webhooks app and choose a channel), then choose what to send. RunThru posts a test message to the channel.
2. Comment the code the page gives you on a pull request: /runthru connect SLACK-WXYZ-6789. RunThru confirms on the pull request.

The code is how RunThru knows which GitHub account the channel belongs to. An owner of the account (the user, or an owner of the organization) can connect a channel for every repository. Anyone else needs write access to the repository where they comment, and connects that repository only. A code works once, for one account, and expires after 24 hours.

To change a channel's settings, connect it again with new choices. /runthru notify lists what's connected, /runthru notify test posts a test, and /runthru notify off turns a channel off. Testing or turning off a channel takes write access too, and a channel that covers every repository can only be turned off by an owner. Free and Pro accounts send to one channel. Team accounts can send each repository to its own.

A webhook lets RunThru post to that one channel and nothing else. It can't read messages, and RunThru never shows the webhook again after setup. If Slack starts refusing it (the channel was archived, or the webhook removed), the channel pauses itself and /runthru notify says so.

How it works

Six stages run in order. Each writes its output to disk, so a run can resume, re-voice or re-cut without starting over.

The 81-second explainer above was voiced and rendered by RunThru.

1. Explore

   An agent reads a curated version of the diff, opens the preview in a real browser, and clicks through until it finds the shortest path that shows the change. It saves that path as a replayable flow.

   Claude Opus 5.5, accessibility snapshots plus screenshots

2. Validate

   It dry-runs the flow and screenshots every step. If a step breaks, the agent repairs it, or reports that the app itself is broken.

   Playwright, self-repairing locators

3. Write and voice

   One line of narration per step, written from the screenshots, using only labels and numbers that are on screen. A studio voice reads each line with word timings, so captions match word for word.

   Claude for the script, ElevenLabs for the voice

4. Film

   The flow is replayed at the pace of the voice and composited frame by frame: a natural cursor, a camera that zooms toward each click, spotlights and callouts on what changed, title and end cards.

   Deterministic HTML compositor, parallel headless render into ffmpeg

5. Review

   A second model watches the finished cut next to the script. It flags narration that doesn't match the screen, dead air, framing problems and errors in the app. Before a "feature doesn't work" verdict is posted, another model re-checks the claim against the captured page.

   Gemini 3.1 Pro with native video input, then a Claude check of any failing claim

6. Deliver

   One comment on the pull request with a GIF preview, the video, chapters, transcript and verdict, a share page, and a Slack message if a channel is connected. Re-runs update the same comment.

   GitHub app or your own CI

Free plan and limits

The Free plan is 5 videos a month for each installing account (a user or an organization), at 720p with a RunThru end card. It needs no card and no API keys. To keep it fair:

• Up to 3 runs per pull request each month.
• A run that fails doesn't count.
• The month resets on the 1st (UTC).

When an account runs out, RunThru says so on the pull request with a link to upgrade that account. See plans.

Plans and billing

Plans belong to the GitHub account that owns the repositories (a user or an organization), and cover every repository where RunThru is installed. Pro ($29 a month) includes 30 videos per billing period and Team ($99 a month) 100, rendered at 1080p60 with no RunThru credit on the end card; extra videos are $1 (Pro) or $0.90 (Team) each. Both can add square and vertical cuts, 4K, their own colors, a choice of narrator and music. Team runs go to the front of the queue. Failed runs never count. Share pages and Slack notifications are on every plan; Team can send each repository to its own Slack channel.

• Upgrading from a pull request: the upgrade link in RunThru's reply starts checkout for that account, so the plan switches on as soon as you pay.
• Buying on runthru.co: after checkout you get a claim code. Comment /runthru claim <code> on any pull request in the account's repositories, and RunThru confirms on the pull request.

Permissions and security

• Permissions: pull requests and issues (write, to post its comment); contents, deployments and statuses (read, to find the diff and the preview).
• Checks (write): to read other checks when looking for the preview, and to post the RunThru check on the pull request's head commit. It never changes or re-runs other checks.
• It never pushes code and never runs your repository's code. A static folder is served as plain files.
• Only members trigger it. Comments from anyone else get a 😕 reaction and nothing runs.
• No reaching inward. Its browser blocks loopback, private, link-local and internal addresses.
• Share pages are unlisted. Each has a random address, is never indexed, and shows only what the video and the pull request comment already show.
• Slack is post-only. RunThru stores one incoming webhook per channel. It can post there and can't read anything.
• What models see: a curated diff, screenshots of the preview and the narration script. Claude explores and writes, ElevenLabs voices, Gemini reviews the video. The agent never sends messages, buys anything or changes settings in your app.

Self-hosted

The same pipeline runs as a CLI and a GitHub Action on your own machines with your own model keys. That's how it reaches localhost, staging behind a VPN, and native iOS apps in the Simulator, and how teams keep diffs and screenshots inside their own vendor accounts.

$ runthru branch --url http://localhost:3000        # film what this branch changed
$ runthru pr 5031 --comment                         # film a PR and post the comment
$ runthru make https://app.example.com -p "show how to invite a teammate"
$ runthru studio                                    # dashboard: edit a line, re-voice

Self-hosted licenses are part of Enterprise. Talk to us.

Compared with other ways

Checking a preview by hand and recording a demo both work when a person has the time. RunThru is for the pull requests nobody has time to check.

A screen recorder is still the right tool for talking-head updates and quick messages.