Quickstart
Create a session, checkpoint prepared state, rewind, and reconnect over CDP.
The shortest useful brawsr workflow is: prepare browser state, checkpoint at a
safe point between actions, make a later change, rewind, and reconnect to the
restored browser. Keep BRAWSR_API_KEY in your server-side environment; never
embed it in browser code or a public bundle.
Run an exact example
The public examples below explain the workflow in small steps and show only the
important code. Each page links to its complete runnable program in
brawsr/examples (opens in a new tab).
TypeScript + Playwright
Checkpoint, rewind, reconnect, and verify restored state.
Python + Playwright
Run the equivalent synchronous Python flow.
What the example proves
- A session exposes an authenticated CDP connection for Playwright.
- Browser state is prepared before the checkpoint, at an application-chosen safe point.
- State changed after the checkpoint is discarded by rewind.
- Rewind replaces the browser process, so the program reconnects and rediscovers its page instead of reusing stale handles.
- The restored page contains the checkpointed value.
- The program waits for terminal rewind completion before close, because close is another lifecycle mutation on the same session.
Usable before terminal
A rewind result can be CDP-usable while bounded post-restore work is still
completing. Reconnect immediately if you only need browser work. Before
checkpointing, rewinding, forking, or closing that session again, wait with
waitRewind in TypeScript or wait_rewind in Python using the returned
operation ID.
Try a branch
Once rewind is clear, fork the same captured state into ordered peer sessions. The fork example verifies every child inherited the checkpointed value; the speculative example keeps result selection in your application instead of inventing a brawsr winner.