Recording Terminal and CLI Demos That People Can Actually Follow

Terminal demos are some of the most useful videos a developer can make. They are also some of the hardest to watch. Tiny monospace text, a wall of scrolling output, a command that disappears off the top of the screen before anyone can read it — and the viewer gives up two minutes in.

The fix is almost entirely preparation. A terminal recording that works is set up before you press record, not rescued afterward. Here is the full process.

Why Terminal Recordings Are Hard to Watch

Screen recordings of a GUI have visual anchors: buttons, icons, layout. A terminal has none of that. Everything is the same size, the same color, and it moves fast. The specific problems are always the same:

• Text too small: A font that is comfortable at arm’s length is unreadable in a 1080p video played in a small window
• Low contrast themes: Dim grays on near-black look elegant on your monitor and vanish after video compression
• Output that scrolls past: The interesting line flies by while you are still talking about the command
• Invisible input: Viewers cannot see your keystrokes, so a flag typed quickly looks like magic
• Dead time: Installs, builds, and test suites produce thirty seconds of nothing

Every one of these has a fix you can apply in under five minutes.

Set Up the Terminal Before You Record

Treat your demo terminal as a separate environment from your working terminal. Most terminal apps support profiles — make one called “Recording” and configure it once.

• Font size 18–24pt: Roughly double what you normally use. If it looks absurd on your monitor, it is probably right for video
• High-contrast theme: Bright foreground on a solid dark background. Avoid transparency and background images entirely — they compress badly and add visual noise
• Window size, not full screen: An oversized full-screen terminal shrinks the text relative to the frame. A window around 90–100 columns fills a 16:9 frame nicely
• Turn off ligatures if they confuse: Fancy arrow glyphs for -> and != can puzzle viewers who are trying to copy your commands
• Increase line spacing slightly: A little breathing room makes dense output far easier to scan

Clean Up Your Shell

Your prompt and history carry more than you think. Before recording:

• Simplify the prompt: A long prompt with git branch, node version, timestamp, and a two-line path eats horizontal space and distracts. A short ~/project $ is ideal
• Hide your username and hostname: They identify you and your machine in a video you may publish
• Clear scrollback and history: Previous commands can reveal client names, internal hostnames, or unrelated work
• Check your environment variables: env output in a video has leaked more API keys than any code snippet
• Use a throwaway directory: A clean project folder avoids unrelated files appearing in ls output
• Disable notifications: Terminal bells and desktop popups both interrupt a take

If your demo touches real credentials, use dummy values. Redacting in post is far more work than setting API_KEY=demo-key-1234 beforehand.

Plan the Command Sequence

Write your commands down before you record — in a scratch file, not from memory. A short script of exactly what you will type, in order, does three things: it stops you from mistyping under pressure, it keeps the demo on a straight line, and it becomes the outline for your narration.

Then run through it once, in full, without recording. This catches the surprises: a cache that was already warm, a dependency that needs installing, a prompt you forgot about. Reset the directory afterward so the recorded run starts from the same state.

Recording Settings for Terminal Work

Terminal content is mostly static text, which makes it forgiving in some ways and demanding in others.

• Capture the window, not the whole screen: Window capture keeps the frame tight on the terminal and hides everything else on your desktop
• 30fps is plenty: Text does not need 60fps. Lower frame rates also mean sharper text at the same bitrate
• Record at your display’s native resolution: Scaling text up after the fact is where blur comes from
• Skip the webcam overlay, or keep it small: In a terminal demo the output is the subject. A large picture-in-picture covers the bottom corner, which is exactly where new output appears

Pacing: The Part Most People Get Wrong

The rhythm of a good terminal demo is not the rhythm of you working.

1. Say what you are about to do before you type it: “Now I’ll install the CLI globally”
2. Type at a steady, deliberate pace — slower than your normal speed, but not artificially slow
3. Pause for a beat before pressing Enter so the full command is visible and readable
4. Stay quiet while the output appears, then talk about it
5. Point to what matters in the output rather than reading the whole thing aloud

For long commands, consider typing them in two visible steps — the base command first, then the flags — while you explain what each flag does. It is much easier to follow than a forty-character line appearing all at once.

Handling Long-Running Commands

Nobody wants to watch a ninety-second npm install. You have three good options:

• Speed ramping: Keep the command visible but run the waiting period at 4x–10x so viewers see that it happened without sitting through it
• Trim the wait: Cut from the moment the command starts to just before the result appears. Cut on a prompt line so the edit is invisible
• Pre-warm the cache: Run the command once before recording so the recorded run completes in a few seconds naturally

Whichever you choose, say out loud how long it actually takes — “this usually runs about two minutes” — so nobody is surprised when they try it themselves.

Make Output Readable in the Editor

The editing pass is where a decent terminal recording becomes a good one.

• Zoom on the important output: A zoom effect into the three lines that matter is dramatically more effective than asking viewers to squint at a full screen of logs
• Add text overlays for key commands: Putting the command on screen as a caption gives viewers something to read while you narrate
• Annotate error messages: When you deliberately show a failure, highlight the line that explains it
• Add chapters: Install, Configure, First run, Troubleshooting — terminal demos are followed along with, and viewers need to jump back
• Remove silences: Automatic silence removal tightens the gaps around commands without touching your delivery

Mixing the Terminal With Other Windows

Most real demos are not terminal-only. You run a command, then check a browser, then edit a config file.

• Decide the layout before recording: Side-by-side terminal and browser, or full-screen switching — pick one and stay with it
• If you switch windows, pause first: Give viewers half a second to register the change before you keep talking
• Keep font sizes consistent: A large terminal font next to a tiny editor font makes the editor unreadable
• Consider area capture: If you have a fixed two-window layout, capturing that region keeps the framing stable across the whole video

A Pre-Record Checklist

[ ] Recording profile active: large font, high-contrast theme, no transparency
[ ] Prompt simplified, username and hostname hidden
[ ] Scrollback and history cleared
[ ] Secrets replaced with dummy values
[ ] Command sequence written down and rehearsed once
[ ] Working directory reset to a clean state
[ ] Notifications and terminal bell disabled
[ ] Window capture selected, 30fps, native resolution
[ ] Ten-second test recording checked for readability

That last item matters most. Record ten seconds, play it back at the size your viewers will actually watch it, and ask whether you can read the text comfortably. If not, increase the font and try again before committing to a twelve-minute take.

Common Mistakes

• Recording at full screen on a 4K display: The text ends up microscopic in the exported video
• Clearing the screen constantly: Viewers lose the context of what just happened
• Resizing the terminal mid-recording: This reflows text and looks jarring
• Reading output verbatim: Summarize instead — “all twelve tests pass”
• Leaving the cursor blinking on a static frame: Trim those tails; they make a video feel stalled
• Assuming viewers know your aliases: If you type gs, say that it is git status

Conclusion

A terminal demo succeeds or fails on readability. Set the font large, pick a high-contrast theme, clean your prompt, rehearse the sequence, and give every command a beat before you hit Enter. Then use zoom effects and speed ramping in the editor to keep attention where the output matters. Do that and your command line walkthroughs stop being something people endure and start being something they follow along with, terminal open beside them.