pomber/stargazer: Render GitHub Star Milestone Videos

What pomber/stargazer Does for GitHub Repositories

pomber/stargazer addresses a narrow publishing problem: turning the people who starred a GitHub repository into a celebratory video. It is intended for repository owners who want to mark a stars milestone, rather than for video editors seeking a general-purpose editing application. The README presents the project as a way to "Celebrate with a video of your stargazers", while the repository topics identify GitHub, stars and video as its central subjects.

The project is a template built with TypeScript, React and Remotion. Its package name is `template-stargazer`, and the available scripts include a Remotion Studio preview, a bundle build and an ESLint plus TypeScript check. The GitHub Actions route is presented as the easier option for producing a video, while local rendering gives the user an interactive preview before invoking the render command.

The template does not document arbitrary video imports, custom timelines or export-format selection. Its visible configuration is centered on selecting a repository and rendering its stargazers. That narrow scope is useful when the desired result is a repository milestone video, but it makes the project unsuitable for a broader content workflow.

The Remotion Composition and Render Path

The repository is built around Remotion rather than a separate media-editing interface. The dependency list includes `@remotion/bundler`, `@remotion/cli`, `@remotion/renderer` and `remotion`, so the rendering path is implemented through Remotion packages. The package scripts identify the main operations: `npm run dev` starts Remotion Studio, `npm run build` creates a Remotion bundle, and `npm run lint` runs ESLint followed by TypeScript.

The documented data input is a GitHub repository name entered through the right sidebar of the preview. The README also requires a `REMOTION_GITHUB_TOKEN` environment variable. Based on the repository name and the stated purpose of retrieving stargazers, the workflow is designed to fetch GitHub data for the selected repository. The README does not expose the source files under `src/`, so the exact composition tree, request functions and frame calculations cannot be confirmed from its documentation alone.

Rendering is therefore a preview and render workflow rather than a general editing workflow. The local route lets the user inspect the generated composition in Remotion Studio and then either click `Render` or use `npx remotion render`. The GitHub Actions route accepts repository details and displays progress before providing the resulting video.

Installing the Template and Creating a Local .env File

The README gives a direct path for local use. First, use the repository as a template. It then directs the user to GitHub's personal access token page and asks for a `.env` file containing the token variable below. The example uses a token placeholder rather than a real credential, so replace that placeholder with a token created through GitHub's settings.

REMOTION_GITHUB_TOKEN=github_pat_...

The local setup then installs the dependencies declared in `package.json`.

npm i

After installation, start the preview server.

npm run dev

Remotion Studio should provide the interactive preview described in the README. Open its right sidebar, enter the target repository name and click `Render` if the preview is suitable. The README also gives a command-line alternative.

npx remotion render

The README does not specify a required Node.js version, output directory, video format or rendering duration. Those details should remain unspecified rather than being inferred from the dependency versions.

Running stargazer Through GitHub Actions

For users who do not want to manage a local render, the README documents a workflow based on a fork. Fork the repository, open the fork's Actions page, enable the workflow using the control shown in the repository instructions, and select the render video option. The workflow then asks for the repository whose stargazers should appear in the video.

The documented sequence is based on the GitHub interface rather than a shell command. From Actions, the user enables the workflow, opens the render video option, enters the target repository and follows the progress screen. Once rendering finishes, the result is available through the link shown by the workflow.

This route removes the local installation step, but it does not remove the underlying access requirement. The GitHub token and repository selection remain part of the setup. The README does not describe artifact retention, failure notifications, rerun behavior or permissions for private repositories. It also does not state whether the workflow is intended for public repositories only. Those are concrete points to inspect in `.github/` before relying on it for unattended rendering.

The GitHub Actions approach is a hosted execution path. Local rendering is more suitable when the user wants to inspect the composition interactively, while the Actions path is positioned in the README as the easy choice for producing the final video.

Remotion Upgrades and Repository Changes

The README provides a dedicated upgrade command for the rendering framework.

npx remotion upgrade

This command is the documented mechanism for upgrading Remotion. The repository's `package.json` uses Remotion dependencies with `^4.0.0`, while the project also pins `react` and `react-dom` at `19.2.3` and includes `zod` at `4.5.4`. Because the package uses caret ranges for the Remotion family, the exact installed versions are not established by the README. A successful application of the upgrade command should be followed by a preview or render check, since the README does not describe compatibility behavior for this template.

There are no GitHub releases listed for the repository, so there is no published release history to use as an upgrade guide. The README also does not document a migration process for custom compositions, token handling or workflow changes. Developers who modify the template will need to treat `npm run lint`, the local preview and a completed render as separate checks rather than assuming that dependency installation alone verifies the result.

The repository is not archived, and its last push was on 2026-10-12. That supports treating the codebase as recently changed, but it does not establish a release cadence, compatibility policy or long-term support commitment.

License Boundaries for the Template and Remotion

The README says that the code in this repository is licensed under MIT, while `package.json` contains `"license": "UNLICENSED"` and `"private": true`. Those repository statements are not identical. The README's license wording is the more direct project-level statement, but the package metadata still marks the package as unlicensed and private, so a person planning redistribution should resolve that discrepancy before publishing a derivative.

The README also says that Remotion is normally subject to a paid company license and that creating videos with this template is accepted without a company license, linking to an issue comment. This is a project-specific licensing note, not a general statement about all Remotion uses. The README does not establish the terms for changing the template, distributing rendered videos or using modified versions in organizations.

Consequently, the license question is not limited to checking whether the source code has an MIT notice. It also involves the dependency's stated licensing condition and the scope of the linked exception. Review the relevant license files and the linked issue comment before using the template beyond the stated purpose.

Limits and a Custom Remotion Alternative

The main limitation is scope. pomber/stargazer is designed around GitHub repositories, stargazers and milestone celebrations. It is not documented as a tool for editing uploaded footage, composing arbitrary scenes, adding custom narration or producing videos for non-GitHub data. The repository topics, repository input and GitHub token requirement all point to a specific data source and output.

There is also limited operational documentation. The README does not state how a failed GitHub API request appears, how authentication failures are handled, how many stargazers can be rendered, whether pagination is supported or how long the GitHub Actions job can run. A repository with a large stargazer list therefore needs investigation before it is used for a major milestone. These are documentation gaps, not claims that the workflow fails under those conditions.

A general video editor or a custom Remotion project would be the alternative approach. A general editor is suitable when the user needs manual timeline work, arbitrary assets and independent media handling. A custom Remotion project stays closer to the underlying technology, but it requires the user to implement the GitHub data retrieval and composition behavior. Stargazer saves that implementation work for its specific milestone-video case, while narrowing the choices available in a general editor.

Editorial conclusion

Repository owners should consider pomber/stargazer when a GitHub star milestone needs a themed video and they are comfortable configuring Remotion and GitHub access. It is a poor fit for general video editing, analytics, or repositories whose owners cannot supply a GitHub token. Check the intended Remotion licensing terms first, confirm that the workflow can access the target repository, and preview a short render before adopting the template.

Frequently asked questions

Official sources

1. Issues
2. pomber/stargazer on GitHub
3. README