Feature video
Source for the 81-second feature tour in docs/assets/tollgate.mp4 and the animated tollgate.webp. Each scene is a React component rendered with Remotion.
Story and sources
The opening identifies the product and its main controls within three seconds. The tour then explains each feature with diagrams, configuration examples, logs, and dashboard views.
| Start | Scene | Content |
|---|---|---|
| 0:00 | Introduction | Current logo, product name, and three concrete capabilities |
| 0:04 | Architecture | Clients, the gateway, and native provider APIs |
| 0:10 | Request pipeline | Authentication, preflight, limits, cache, forward, and settlement |
| 0:26 | Failover | A primary returns 529; a backup returns a successful stream |
| 0:33 | Resilience | Circuit breaker states and retry rules |
| 0:41 | Budgets | A hard budget refuses a request with HTTP 402 |
| 0:46 | Agent sessions | Sticky targets, personal data redaction, and session budgets |
| 0:54 | Observability | A schematic trace and the gateway's metric names |
| 1:00 | Dashboard | Overview, session details, and provider health |
| 1:11 | Engineering | Tests, coverage, SDK checks, and architecture decisions |
| 1:16 | Install | Install command and repository address |
The scenes are animated explanations, not a continuous screen recording. Failover logs and the 402 response reproduce local Tollgate output with fake providers. Configuration and protocol names follow the repository guides. The trace uses illustrative span placement; its bars do not use a uniform time scale.
Dashboard images come from make dashboard-demo and use synthetic data. The sticky-routing cost comparison comes from the synthetic replay.
The displayed 89 µs is the overhead of one local demo request, not a general latency guarantee. Repository statistics reflect the code at render time: 250 Go tests, 90.8% statement coverage, 33 ADRs, and four fuzz targets.
Edit
Goal: change a scene and inspect its composition.
Prerequisites: Node.js 20 or later and npm. The first render downloads headless Chrome. Allow several GB of disk space for PNG frames.
Install dependencies:
shcd docs/video npm ciOpen Remotion Studio:
shnpm run studioSelect
Launchfor the complete video, orScene1throughScene11for an individual scene.After edits, run
npm run typecheck.
Result: the compositions show the current source. If Chrome cannot start, pass --browser-executable <path> to the Remotion command.
Remotion has its own license terms. Review them before commercial use.
Export
Goal: produce a sharp 1920×1080 MP4 and animated WebP.
Prerequisites: the dependencies above.
Render and encode both formats:
shnpm run renderThe MP4 is 60 fps. The WebP is 20 fps at the same 1920×1080 resolution. Both use the PNG frame sequence in
out/launch-frames/.To repeat only an encoding step:
shnpm run encode:mp4 npm run encode:webpCopy the exports and poster:
shcp out/tollgate.mp4 out/tollgate.webp ../assets/ cp out/launch-frames/element-0150.png ../assets/video-poster.png
Result: the README and documentation site use the refreshed assets. If the render fails, inspect the Remotion error, correct the source, and repeat step 1.
The WebP encoder reads PNGs directly. An intermediate H.264 video would reduce color detail around small text. Mixed WebP encoding preserves flat UI regions, while a fixed background avoids noise and excessive file size. Larger text and focused screenshot views help at GitHub's narrower display width.
The still input prop fixes the background and removes grain. It does not stop scene animations. The output directories are ignored by Git.
README images
The README banner, the "How it works" diagram, and the GitHub social preview are Remotion stills in src/stills/. The banner artwork in public/readme/banner-art.jpg was made with an image model and has no text. The stills add the logo and all words, so that text stays sharp and matches the brand.
| Composition | Output | Use |
|---|---|---|
Banner | docs/assets/readme-banner.webp | Top of the README |
FlowLight, FlowDark | docs/assets/readme-flow-{light,dark}.webp | "How it works" in the README, for each GitHub theme |
Social | docs/assets/social-preview.jpg | Repository Settings → Social preview |
Goal: render and encode the README images again after a change.
Prerequisites: the dependencies from Edit.
Run:
shnpm run readmeInspect the images at the width that GitHub shows them, about 900 CSS pixels, in both themes.
Result: scripts/readme.mjs writes the four files in docs/assets/. If text is too small in the diagram, keep its smallest text at 20 px or more.
The diagram has a transparent background, so its cards sit on the GitHub page. Lossless WebP keeps its edges sharp and is smaller than lossy WebP for flat colors. GitHub accepts only PNG, JPEG, or GIF for the social preview.
Refresh screenshots
Goal: capture current dashboard screens with the current logo.
Prerequisites: a browser that can capture at 2× device scale.
- From the repository root, run
make dashboard-demo. - Open
http://127.0.0.1:9090with a 1540 CSS-pixel viewport at 2× scale. - Capture Overview, Sessions, a session detail, Providers, and Keys in both themes. Crop only empty space below the page content.
- Save the captures as
docs/assets/dashboard-{page}-{theme}.png. - Copy the dark Overview, session detail, and Providers images into
public/overview.png,public/session.png, andpublic/providers.png. - Render the tour again, then inspect the dashboard camera at each focus point.
Result: the README, guides, and video show the same product version. If session data is sparse, wait for the synthetic traffic before capture.