A changelog video is a short recap of what changed in a product release. It shows the new behaviour, names the feature and tells existing users where to find it. The written release notes remain the place for the complete change list, availability details and breaking changes.
For a routine update, start with one to three changes and a 30–60-second cut. That is a useful production brief, rather than a rule every release must follow. A single improved interaction may need only 15 seconds; a monthly walkthrough can take longer.
There are two ways to make one in CoAnimator. Edit it visually in Studio if you want to trim footage and set the pace yourself. Build it from project files and render from the terminal if you want the edit in version control or plan to produce an episode for every release. Both start with approved notes and a recording that shows the change working.
What belongs in a changelog video?
Show the difference a customer can use: a new filter, a shorter setup process, a changed permission or an action that now works differently. Give each change enough screen time for someone to recognise the control and understand the result.
The strongest material is often a short recording of the released feature. A caption such as “Pause a recurring invoice” tells viewers what to look for; the click and the resulting Paused state explain it. A headline saying “Billing improvements” leaves both jobs unfinished.
A changelog video usually needs four pieces:
- Release identity: the product and version, or a clear date for a continuously deployed service.
- Selected changes: the few updates relevant to the audience watching this episode.
- Product evidence: the changed screen, interaction or output, with readable labels.
- A next action: where to find the feature, enable it, update the app or read the full notes.
Keep a Changelog treats a changelog as a curated record for people. Apply the same judgement to the video. Raw commit messages can help locate a change, but they rarely supply a usable customer explanation.
Keep migration instructions, security details, deprecations and exact compatibility requirements in the written entry. If one affects the audience, mention it in the video and point to the instructions. A patch can matter greatly even when it has nothing interesting to film.
How it differs from a launch video or product demo
| Format | The viewer’s question | What earns the screen time |
|---|---|---|
| Changelog video | What changed, and where do I use it? | The new behaviour and any action existing users need to take |
| Product demo | Will this product solve my problem? | A useful task shown from start to result |
| Launch video | Why should I pay attention to this product or major feature? | The proposition, a compelling demonstration and an invitation to try it |
A major release can support all three, but a weekly changelog episode rarely needs the company introduction or a tour of features that have not changed. For a longer demonstration, use the product-demo planning guide.
Start with a CoAnimator template and its finished video
The Cinematic UI Focus template is a useful starting point for updates that need readable product screens and deliberate camera moves. It includes a complete project you can open and change, with several software scenes and separate sound cues.
Open the template and download its .coa project · Watch the MP4 directly.
The sample is a longer product film. For a changelog episode, select the scenes that suit the update and replace the example interface, claims and branding with your approved material. Its phone-coding sequence, for example, belongs only in an episode whose subject benefits from that view.
The downloaded project has a 1920 × 1080 canvas, a 60fps timeline and about 94 seconds of animation. Those are properties of this sample, not requirements for your changelog. Keep the frame rate consistent while revising the project, and shorten the episode by removing unnecessary scenes before speeding up the remaining ones.
Make the first episode
Install CoAnimator and prepare the media tools in the quickstart. To inspect the sample, download its .coa and open it from the launcher. Keep the original so you can refer back to its scene timing, typography and sound. If you adapt the project files, work in a separate episode copy. If you’re cutting straight screen recordings in Studio, start with a blank timeline and use the film as a reference for how long to hold on a detail.
CoAnimator has a free forever plan. Connected agent accounts and optional image, voice or music services have their own allowances or charges. You can make the first adaptation with your existing captures and the supplied project assets, without commissioning new media.
Example: seven changes become a 38-second update
Consider a fictional invoicing app shipping Release 4.12. It has seven merged pull requests, but three changes supply the main on-screen story. This is a planning example; the template film above contains its original software scenes.
| Release entry | Treatment | Reason |
|---|---|---|
| Pause a recurring invoice from the invoice list | Show the action and Paused state | A customer can see and repeat it |
| Mark several invoices as paid in one action | Show selection, action and result | The group action is the useful change |
| Filter the invoice list by client | Show the filter and narrowed list | One interaction explains the feature |
| Move the reminder queue to a new worker | Written notes | The implementation detail does not explain a new action |
| Update the PDF library | Written notes, with any relevant advisory | A dependency name alone supplies no useful visual |
| Refactor permission checks | Written notes; clarify any changed access | The title does not establish a customer-facing change |
| Correct a receipt-email typo | Written notes | It needs little screen time in this episode |
The visible-change test is a starting point, not a reason to hide important fixes. If the permission change removes an action users previously had, it deserves a clear explanation. If a dependency update addresses a vulnerability, the written release should say what customers need to do.
A storyboard with enough time to read
| Time | Picture | On-screen wording or action |
|---|---|---|
| 0–14 seconds | Invoice list, cursor selects Pause, status changes | Product/version label; “Pause recurring invoices” |
| 14–26 seconds | Several invoices selected, then marked paid | “Mark multiple invoices as paid” |
| 26–33 seconds | Client dropdown opens, list narrows | “Filter invoices by client” |
| 33–38 seconds | Short closing card | Release version, actual update instructions and full-notes URL |
The durations total 38 seconds. A real cut may need more time for a slow interaction or fewer words for a small screen. Never promise a feature is available to everyone if it is still rolling out or restricted to a plan. Put that condition beside the feature, not just at the end.
Capture the released or approved staging build with sample data. Record the action and the result, leaving a short hold on each. Avoid asking an image generator to recreate the interface: button labels, status changes and available actions need to match the real product.
Make a changelog video visually in CoAnimator Studio
Open on the invoice list, pause one recurring invoice, and let viewers see the status change. That first cut sets the pace for the rest of the 38-second example. You can build it in Studio from screen recordings using the media panel, timeline and stage. CoAnimator’s footage editing guide.
1. Set up the project and collect the clips
From the CoAnimator launcher, start a blank project and open Studio. Keep a copy of the release notes handy. For this example, gather three recordings from a demo workspace: pausing a recurring invoice, marking multiple invoices as paid, and filtering by client. Capture each action in one take and let the result sit for a few seconds before you stop recording.
Drag the clips and your closing card image into the media panel. Put the recordings on a video track in the order you want viewers to see them. Start with the Pause control already on screen. You can remove the walk through the sidebar, login, and loading states.
2. Build the rough cut on the timeline
Line up the clips at roughly 0, 14 and 26 seconds. Add the closing card at 33 seconds. Use snapping to bring the clip edges together, and check each join on the stage for stray frames. Trim the pause clip so the click and the resulting Paused label both survive. If the label flashes by, give it another second and move the next cut.
3. Place the labels beside the action
Use a text track for short headings. Put “Mark multiple invoices as paid” beside the selected rows and keep the cursor and menu clear. End that label before the client filter scene. On the closing card, use the five seconds to show the release version and one next action. Put the clickable release notes link alongside the published video.
4. Watch the edit twice
Watch once muted. You should be able to point to the control, see the action and read the result in all three scenes. If you have to pause playback to catch a status change, extend that shot. Watch again with sound. Listen across each cut for abrupt jumps in the screen recording, and lower music under speech if you use both.
5. Export the episode and save the source
Choose Export and select the full timeline. Play the MP4 outside Studio and watch through the closing card. Check the smallest label on a phone. Save the reviewed project so you can swap in next week’s recordings and update the labels without rebuilding the sequence. CoAnimator’s export guide.
Make a changelog video from code
Use this route when the edit needs to live alongside the release in version control. Start from a working CoAnimator project folder and keep the approved recordings in it so the render runner can find them. Update the scene copy and media references in the animation source, then set the order and timing in the timeline files. You can make those changes yourself or give a coding agent the brief below. CoAnimator’s project file guide.
For Release 4.12, set the pause, bulk-payment, client-filter and closing scenes to start at 0, 14, 26 and 33 seconds. If the pause recording starts with two seconds of navigation, its timeline entry starts at startTime: 0 with trimIn: 2 and duration: 14. That requires at least 16 seconds of source footage. Use the installed timeline reference for the fields in your project, and move the title and the cut together if you revise the timing.
Review the changed files, then render the project from the terminal and watch the MP4. You can run the command for a single episode before wiring it into a release job.
Give the agent a release-specific brief
Supply one dated release section rather than the whole changelog. Include the exact version, audience, availability, source assets and destination for the full notes. An unfinished item under Unreleased should never become a shipped feature because it happened to be near the selected section.
Create a small episode folder that the agent can understand:
release-4-12/
release-notes.md
episode-brief.md
approved-assets/
pause-invoice.mp4
bulk-paid.mp4
client-filter.mp4
logo.svg
project/
project.json
...template project filesUse this brief after replacing the example files and release details with your own. It requests a plan before production, so the feature selection can be corrected before the agent spends time on the animation.
Copy the changelog video brief
Read release-notes.md and the instructions inside project/. Build a changelog episode for the exact released version in that file, using our copy of the Cinematic UI Focus template. The audience is existing customers. Aim for 30–45 seconds, but preserve the reading time and complete meaning of each selected change.
Use only approved-assets/ for the product interface, logo and recordings. Select up to three customer-relevant changes. For each, identify the source release-note line, the asset that demonstrates it, a short headline using the interface’s exact wording, and the action the viewer should take. List entries left for the written notes and explain why. Preserve availability restrictions, feature flags and migration requirements. Do not present Unreleased work as shipped.
First propose the scene order, wording and duration. Identify missing assets before building. Once I approve the plan, replace the original sample’s screens, claims and branding, keep the useful typography and camera treatment, and remove scenes that do not serve this release. Make the changed control readable and hold the resulting state. The clip must make sense with sound off.
Retain suitable existing music and effects, and retime them around the new edit. Do not request paid media generation. Do not invent product screens, performance figures, testimonials or integrations. End with the exact release version, approved update instructions and full-notes URL supplied in episode-brief.md.
Show the opening, the most important feature frame and the ending for review. Do not export or publish until asked. Keep the source project for the next episode.
For a more detailed Claude-specific walkthrough, see turning release notes into a product video. This guide focuses on choosing and repeating a changelog format; that article goes deeper into preparing the notes and directing the agent.
How to create changelog videos automatically
Automate after one complete episode has been reviewed. That first project establishes the typography, product framing, sound and closing action. Each later run should work in a new copy, keeping the previous release available for reference or correction.
CoAnimator’s scheduled changelog setup describes the same sequence: read a release, update a reusable project, render and notify. The schedule is configured through your own automation or CI system. A template download alone does not install a recurring job.
1. Choose the release event and exact input
For a product with GitHub releases, trigger after the release is published. GitHub supports a release event with types: [published]. A weekly schedule also works, but it needs a saved record of the last processed release so it does not remake the same episode every Friday.
Have the job save the release ID, tag, date, notes and full-notes URL as files. Add a manifest of approved screen captures. If you start from merged pull requests, filter them to the release range and ask the product owner to approve the customer-facing summary. A merge into the default branch is not proof that a feature is available in production.
2. Give the run a fresh project and bounded instructions
Copy the approved baseline into that release’s folder, then run the connected agent against those files. Reuse the brief above with an unattended-run rule: build only changes supported by the notes and available assets; return needs_assets if essential footage is missing, and skip if there is nothing suitable to show.
The interactive brief asks for approval before building. After the team has approved the recurring format, replace those approval paragraphs in episode-brief.md with these instructions for the scheduled run:
Copy the unattended episode instructions
The recurring format and this release’s source material are approved for production. Work inside this episode copy of project/. Read release-notes.md and approved-assets/. Keep the approved brand treatment, select up to three supported changes and build the episode without waiting for a chat reply. Preserve the exact version, availability and interface labels. Do not request new media, invent a missing screen or modify the baseline project.
If a selected change cannot be demonstrated with the supplied assets, stop with status needs_assets and list the missing files. If the release has no suitable changes, return status skip and the reason. Otherwise, finish the project and write build-review.json with status ready, the release ID, each selected change and its source line, asset filenames, episode duration and any remaining issues. Do not mark ready while a required asset or factual question remains unresolved. Do not render or publish; the job handles rendering after reading the status, and a person reviews the movie before publication.
Keep these decisions in a small build-review.json alongside the project: release ID, selected changes, source lines, assets used, status and remaining issues. Let the job continue to rendering only when the status is ready. A scheduler should not interpret a friendly final chat message as evidence that every required asset was present.
For Claude Code, non-interactive mode runs the editing step from a script. From a prepared episode folder, a narrowly scoped invocation can look like this:
claude -p "Read episode-brief.md and release-notes.md. Follow the approved automated-episode rules. Edit only project/ using approved-assets/. Write build-review.json with status ready, needs_assets or skip. Do not render, publish or use external media services." \
--tools "Read,Edit,Write,Glob,Grep" \
--allowedTools "Read,Edit,Write,Glob,Grep" \
--permission-mode dontAskThis is the editing step, not an entire installed automation. The runner needs an authenticated agent account, the prepared files and its approved instructions. The file-only tool list is suitable when all media already exists; a project that needs another tool must have that permission configured deliberately. Agent usage still follows the provider’s billing terms.
3. Render the ready project
Install coa from Settings → General → Command line & agent skill → Install coa command, then open a fresh terminal. Set up FFmpeg and FFprobe through media setup or the runner’s PATH. These are separate from the agent’s project instructions.
The CoAnimator CLI accepts the project folder and an explicit output path:
coa render ./project --out ./changelog.mp4In Windows PowerShell, use:
coa.cmd render .\project --out .\changelog.mp4The renderer uses the selected timeline’s frame rate unless you override it. If the project has several timelines, add --timeline with the intended timeline ID or name. The downloaded sample uses full-film; an adapted project may use a different name.
Use a runner with CoAnimator, the required media tools, assets and licence configuration already prepared. On headless Linux, Electron also needs a display server, commonly provided through xvfb-run. A generic CI runner does not acquire these dependencies because the workflow contains a render command.
4. Validate, notify and remember the release
Stop the job when the agent reports a missing asset or the render exits with an error. After a successful render, confirm that the MP4 exists, its duration fits the brief and its expected picture and audio tracks are present. Those checks catch a missing output; they cannot judge whether a headline accurately describes a shipped feature.
Send the reviewer the MP4 link, release-note link, scene list and unresolved issues. Keep the project and input files with that release. Record the release ID as completed only after the review package has been saved, so a retry can recover the existing output instead of silently producing or posting a duplicate.
| Situation | What the automation should do |
|---|---|
| No new release or no suitable customer-facing change | Skip the episode and record the reason |
| A selected feature has no approved capture | Report the missing file; leave the episode unfinished |
| A render fails | Preserve the previous good output and send a failure status |
| The same release is retried | Reuse or resume its saved package; avoid duplicate notification or publication |
| A feature is restricted or rolling out | Carry its availability into the caption and review notes |
| The package is ready | Notify the reviewer; publish only through the team’s approved process |
Start with a manual trigger and one real release. Put it on a recurring schedule after that run produces an accurate, watchable episode without missing-file or permission prompts. The runner must be available at the scheduled time, and connected agent requests can send supplied content to the provider. Give it only the release material it needs.
Make the update easy to follow
The template’s camera and focus treatment can draw attention to one part of a screen. In a changelog cut, keep the final label sharp and large enough to read. A dramatic angle that hides the changed button makes the episode less useful.
Watch your episode once with sound and once muted. Each selected change should still be understandable from the picture and text. Match narration to the actual click, leave enough time for the changed state, and keep music below speech. Caption spoken material and correct product names that transcription gets wrong.
Check the release version, availability, interface labels and destination URL against the written notes. Watch at phone size too: a detailed desktop capture may need a tighter crop and a separate portrait layout for a social version. Recompose that layout rather than cropping away the control the viewer needs to see.
Put the video beside the full changelog entry. For release emails, use a poster image linked to that page. In-app announcements should make the new action obvious even before playback. Keep a transcript or short text summary near the video so the release information remains accessible without watching it.
Questions about changelog videos
Does every release need a video?
Make a video when seeing the change helps someone use it. A new bulk action is worth showing because viewers can see which items to select, where the action lives and what happens afterward. A corrected label might only need a screenshot. A dependency update or a migration deadline belongs in the written notes, where people can find the exact instructions later.
If you ship several small changes a week, record the useful interactions as they become available. Group clips by the job they help customers do, such as managing invoices, so the roundup has a reason to exist beyond the release date.
How long should a changelog video be?
Budget about 15–30 seconds for one interaction and 30–60 seconds for a short roundup. Use the time the action needs. For a 25-second filter update, spend roughly four seconds showing the outcome, 15 seconds locating and applying the filter, and six seconds holding the filtered view and telling viewers where to find it.
If users need to enable a setting or complete a migration before they can follow along, keep the changelog clip focused on the result and link to a walkthrough with the full sequence.
How many features should I show in one video?
One feature is enough when it changes a common task. Put two or three changes together when they serve the same audience and belong to the same job. For example, filtering invoices, selecting them in bulk and marking them paid can form one story. An API rate-limit change is better covered separately because it serves a different audience and needs different evidence.
Give each change a screen, a visible result and a reason to appear. If the edit only has room to read the feature name over a title card, leave that item in the written changelog.
Can I make a changelog video without voiceover?
Yes. Use a short opening line, a real product capture and an on-screen instruction at the moment it applies. For a new filter, “Choose a client” should appear while the filter menu is open. Hold the filtered list long enough for someone on a phone to see what changed.
If you use narration, add captions for speech and any sounds viewers need to understand the clip. Keep the destination or next step visible on screen so it still works when the audio is off. W3C guidance on captions.
What if the screen contains customer data or private information?
Record in a demo workspace with synthetic records and an account that has the same permissions as your intended viewers. Seed enough realistic data to show the result. For a bulk payment update, three sample invoices in different states will tell the story more clearly than an empty table.
Review the whole recording for stray details. Check browser tabs, account menus, search suggestions, notifications and briefly visible IDs. Replace sensitive source footage before giving it to an AI agent or uploading it to a video service. Keep any public-facing samples limited to material approved for release.
When should I publish if a feature is rolling out gradually?
Publish to customers who can use the feature, or label the rollout in the opening and where the clip is embedded. For example, “Rolling out to Pro workspaces this week” gives viewers a reason they may not see the control yet. Show the workflow from an account with the same plan and permissions as the audience, and point to the release note for current availability.
For a customer-wide email, wait until the audience can act or send it only to eligible accounts. Keep the reusable project so you can change the availability line and replace the clip when the rollout ends.
Where should I share a changelog video?
Make the written changelog the reference page. Embed the full clip beside the release entry, with the feature name, availability and a link to instructions. An email can use a linked thumbnail that brings readers to that page. An in-app announcement works best near the changed control, with a direct path to try it.
For social, cut around one useful action that makes sense without the rest of the release. Check the layout and labels on a phone before posting. Give every version one next step, such as opening the invoice list or reading the release note.
Can the video be created directly from merged pull requests?
Use pull requests to find candidate changes. Start from the published release tag or approved release list, then map each included change to an approved customer-facing description and a capture that shows it working. GitHub can generate release notes from merged pull requests, which gives the agent a starting inventory. GitHub’s release notes documentation.
If a merged change is still behind a feature flag or has no approved capture, leave it out of the episode until someone confirms what can be shown. A release entry with approved screenshots is a much better input for a recurring video than a raw merge log.
What should a person review before an automated video goes out?
Ask someone to follow the video using an eligible account. Check that the feature is available to that audience, the screen matches the released build and the final instruction takes viewers to the right place. Then play the exported file at phone size and check the captions, sound and closing frame. A successful render only tells you that the file was produced.
Save approval against the release ID and the exact video revision. If a feature label changes or a scene is replaced after sign-off, review the new export before sharing it.
How do you tell whether the episode helped?
Pick one action the video is meant to encourage before you share it. If the update introduces a filter, track how many eligible users apply that filter for the first time. Watch rates and clicks help show whether people found the explanation, while first use gives you a measure of what they did afterward.
Compare with a similar release or, if you can segment the audience, compare eligible groups that received the same announcement with and without video. Note other differences, such as rollout timing and in-app prompts, before attributing a change in adoption to the clip.
Build one episode you can reuse
Start with the most useful change in your latest release and a clean capture of it working. In Studio, trim the recording so viewers can see the action and read the result. If you’re working from code, make that same cut in the project files and render it with coa. In either version, check that someone unfamiliar with the release can find the feature after watching.
Once that episode is right, preserve its project and instructions. The next release can reuse the composition and sound while replacing the claims and screens. That is the point to automate: a defined format, reliable source material and a reviewable result, repeated for each release.