My Star History

It's a self-hosted alternative, not a replacement. star-history.com itself still works for repo owners who log in with their token, but the embedded chart badge for public visitors is broken since the 2026 API restriction. My Star History takes a different approach: instead of a hosted service that renders charts on demand, you generate the SVG yourself with a Python CLI or a Docker GitHub Action and commit it as a static file to your repo. The chart then works for every visitor, no login required on the viewer's side, no external service involved, and no risk of the embed breaking again if the API changes further.

No, for your own repo you do not need a PAT. The default ${{ github.token }} injected into every GitHub Actions run is enough to read stargazers for the repo the workflow lives in. This token is automatically available, scoped to your repository, and requires no configuration. You only need a personal access token if you want to chart a repo you don't own or collaborate on, which is an edge case. Even then, a fine-grained token with read-only metadata access is sufficient - you do not need broad repo or workflow scopes.

Yes, this is one of the key design decisions. The action pushes to a separate star-history orphan branch, not to main. Orphan branches are independent branches with no shared commit history, so they are not subject to your main branch's protection rules. No bypass configuration, no PAT with admin permissions, no PR required. The action creates the branch on first run using a temporary directory and git init - your workspace is never modified. This means it works even on repos with strict branch protection, required reviews, or status check requirements on main.

No conflict at all. The SVGs live on a separate orphan branch called star-history, not in your Pages branch (gh-pages or main/docs). The README references them via raw.githubusercontent.com URLs pointing at the star-history branch, not via your Pages domain. Your Pages site and your star-history chart are completely independent. Even if you use Pages for documentation, a project site, or a custom domain, the star-history action will not interfere with any of it.

Yes. The CLI (mystarhistory.py) runs anywhere with Python 3.6+ and the gh CLI installed. You can run it locally on your machine, in any CI system (GitLab CI, CircleCI, Jenkins, etc.), or on a schedule via cron. The GitHub Action is just a convenience wrapper that packages the CLI in a Docker container and handles the git operations for you. If you prefer to keep full control, clone the repo, run python3 mystarhistory.py --repo yourname/yourrepo, and commit the resulting SVG yourself. The README includes a copy-paste manual workflow example for GitHub Actions users who don't want the Docker Action.

No, the chart is a static snapshot from the moment the action runs. This is by design - a static SVG cannot break the way a live API-driven embed can. Schedule the workflow daily or weekly to keep it current. GitHub caches raw.githubusercontent.com responses for about 5 minutes (controlled by the Cache-Control header), so even after a commit the old chart may show briefly until the cache expires. For most projects, a daily update is more than enough since star counts change slowly. If you need more frequent updates, you can set the cron to every 6 hours, but anything more frequent than that just wastes CI minutes for identical charts.

The xkcd sketch aesthetic is a nod to the original star-history.com visual style, which was itself inspired by Randall Munroe's xkcd comics. The hand-drawn look is achieved with an SVG feTurbulence filter combined with feDisplacementMap, which slightly wobbles every line and curve to simulate the imperfections of hand-drawing. The Handlee font (an open-source cursive font by Jonnie Hallman, licensed under the SIL Open Font License) is embedded directly into the SVG, so it renders consistently on every platform without external font loads. If you prefer a cleaner, more technical look, the renderer is a single Python file (mystarhistory.py, about 290 lines) that you can modify to remove the sketch filter or change the font.

Yes, completely free. The tool is MIT-licensed open source, which means you can use it, modify it, and distribute it freely. The GitHub Action is free to use on the Marketplace. GitHub Actions minutes are free for public repos (unlimited) and included in your account for private repos (2,000 minutes/month on the free tier). Each star-history run uses approximately 1 minute of CI time, so even on the free tier you could run it daily for a year and use less than 1% of your monthly allowance. There are no paid tiers, no premium features, and no usage limits beyond GitHub's standard Actions limits.

Two steps, about 5 minutes total:

Step 1 - Add the workflow file. Create .github/workflows/star-history.yml in your repo with the workflow configuration shown in the Two ways to use it section. Make sure permissions: contents: write is set.

Step 2 - Trigger the first run. Go to the Actions tab in your repo, select the "Star History" workflow, and click "Run workflow" manually. This creates the star-history branch and generates the first SVGs.

Step 3 - Add the embed code to your README. Copy the <picture> block from the Embed in your README section, replace OWNER/REPO with your GitHub repo slug, and paste it into your README.md:

<picture>
  <source media="(prefers-color-scheme: dark)" srcset="https://raw.githubusercontent.com/OWNER/REPO/star-history/assets/my-star-history/star-history-dark.svg">
  <img alt="Star history" src="https://raw.githubusercontent.com/OWNER/REPO/star-history/assets/my-star-history/star-history-light.svg">
</picture>

Step 4 - Commit and push. The chart renders in your README on GitHub. It auto-switches between light and dark themes based on the viewer's GitHub theme preference. The action runs on the schedule you set (daily by default) and updates the SVGs automatically.

On June 30, 2026, GitHub restricted the stargazers API endpoint /repos/{owner}/{repo}/stargazers to repo admins and collaborators.

What changed:

• Anonymous requests now get 403 Forbidden
• Requests from users without repo access also get 403
• Repo admins and collaborators can still read their own stargazer data with an authenticated request

Why GitHub made the change: the stargazers endpoint previously exposed the list of users who starred a repo, along with timestamps. This data could be scraped for surveillance, spam targeting, or competitive intelligence. The restriction was part of a broader effort to reduce API abuse and protect user privacy.

Why this broke live embeds: tools like star-history.com's embedded badges relied on the visitor's browser making an anonymous API call to fetch stargazer data. That call now fails with a 403, so the chart cannot render. mystarhistory avoids this by fetching the data server-side with the repo owner's token and committing a static SVG.

GitHub announced the restriction on June 30, 2026, as part of their "Upcoming access restrictions to public API endpoints and UI views" changelog entry. The stargazers endpoint, which returns who starred a repository and when, was limited to the repository's own admins and collaborators. This affected every tool that relied on anonymous access to star data: star-history.com's embedded charts, browser extensions, third-party analytics tools, and any script that fetched stargazer timestamps without authentication. Star-history.com acknowledged the breakage in a blog post on July 6, 2026, explaining that live charts for repos you don't own are no longer possible. The restriction is permanent - there is no workaround for anonymous access.

Install the mystarhistory GitHub Action in your repo with a daily or weekly schedule. The action fetches your stargazer list (with timestamps) via the gh API, builds a cumulative star-count curve, and renders it as an SVG chart with time on the X-axis and star count on the Y-axis. The chart shows exactly when your project gained traction - a launch on Hacker News, a viral tweet, a mention in a popular newsletter all show up as steep upward curves. The SVG is committed to a separate branch, so you can view the historical chart at any time by checking out older commits. For long-term tracking, the chart accumulates data from every run, so the curve becomes more detailed over time.

Yes, mystarhistory supports multi-repo charts. Pass a comma-separated list of owner/repo pairs to the repos input of the GitHub Action, or use the --repo flag with multiple values in the CLI. Each repo gets its own line in the chart with a distinct color, and the legend identifies which line belongs to which repo. This is useful for comparing your project against competitors, tracking multiple repos in an organization, or visualizing the growth of a fork relative to the upstream. Note that you need read access to each repo's stargazer data, so this works best for repos you own or collaborate on.

An orphan branch in git is a branch with no commit history - it starts completely empty, with no connection to any other branch in the repo. mystarhistory uses an orphan branch called star-history to store the generated SVG files.

Three advantages of using an orphan branch:

• No history pollution - automated chart updates don't clutter your main branch's commit log
• No branch protection conflicts - orphan branches are not subject to main's protection rules, so the action can push without a PR or admin token
• Lightweight - the branch contains only the SVG files (~30 KB total for light and dark themes), not your full codebase

The orphan branch is managed in a temporary directory during the action run - your workspace is never modified.

The CLI accepts several optional flags: --color sets the line color (default is a warm red #dd4528, but any hex color works), --title sets the chart title text, --width and --height control the SVG dimensions in pixels. The GitHub Action exposes the same options as inputs: color, title, and dimensions. For more advanced customization (font, sketch filter intensity, axis labels, background color), you can fork the mystarhistory.py renderer - it's a single Python file with no dependencies beyond the standard library, so modifying it is straightforward. The dark theme automatically inverts colors for dark mode display.

Yes, but you don't need Pages for it. The standard setup references the SVGs via raw.githubusercontent.com URLs pointing at the star-history branch, which works without Pages. However, if you want to use the SVGs in a Pages site, you can reference them the same way - raw URLs work from any HTML page. If you prefer to serve the SVGs from your Pages domain instead, you can change the output-dir to a directory in your Pages branch and adjust the README URLs accordingly. There is no conflict between the star-history orphan branch and a Pages branch.

Daily is the recommended cadence for most projects. Star counts change slowly - even a popular repo might gain 5-20 stars per day, which doesn't produce a visibly different chart at that resolution.

Recommended cron intervals:

• 0 0 * * * - daily at midnight UTC (recommended for most repos)
• 0 */6 * * * - every 6 hours (for repos going viral)
• 0 0 * * 0 - weekly (for smaller repos with slow growth)

Avoid: the 5-minute cron (*/5 * * * *). It burns CI minutes for identical charts and GitHub may pause scheduled runs on repos with no activity for 60 days. Each run uses about 1 minute of CI time, so even daily for a year uses less than 1% of your monthly allowance on the free tier.

Yes. The CLI (mystarhistory.py) is a standalone Python script that runs anywhere with Python 3.6+ and the gh CLI installed and authenticated. You can run it locally: clone the repo, run python3 mystarhistory.py --repo yourname/yourrepo, and commit the resulting SVG to your repo manually. You can also run it in any CI system: GitLab CI, CircleCI, Jenkins, or even a cron job on a server. The GitHub Action is just a Docker container that wraps the CLI and handles the git operations - if you prefer to handle those yourself, the CLI is all you need. The README includes a manual workflow example that clones the repo and runs the script directly in a GitHub Actions step without the Docker Action.

star-history.com is a hosted web application that generates charts on demand from the live GitHub API. You visit the website, type a repo name, and it renders a chart in your browser. It also offered embedded badges for READMEs, but those broke in 2026 when the API was restricted. mystarhistory is a self-hosted tool (Python CLI + Docker GitHub Action) that generates the chart locally with your own token and commits it as a static SVG file. The codebases are completely different: star-history.com is a Node.js/Vue.js app, mystarhistory is pure Python with zero dependencies. The visual style is similar (both use the xkcd sketch aesthetic) but the implementation is independent - mystarhistory does not vendor or reuse any code from star-history.com.

This error appears when a star-history.com embedded badge tries to fetch stargazer data anonymously and gets a 403 from the restricted API. To fix it permanently, switch to mystarhistory: install the GitHub Action, which uses your repo's own GITHUB_TOKEN to fetch the data server-side and commits a static SVG. The SVG is then served as a static file via raw.githubusercontent.com - no API calls from the visitor's browser, no token validation, no error. If you want to keep using star-history.com's embed, you need to supply a personal access token (fine-grained with read-only metadata access) encrypted in the embed code, but this exposes your token (even if encrypted) in a public README, which is a security concern mystarhistory avoids entirely.

star-history.com offers a Chrome extension that pops up a star-history chart when you visit any GitHub repo. Since the API restriction, this extension only works for repos you own or collaborate on (with a token). mystarhistory does not offer a browser extension - it's a CI/CLI tool, not a browser tool. However, if you install the mystarhistory Action in your repo, the chart is always available as a static SVG in your README, visible to every visitor without any extension. For browsing other repos' star histories, you can still use star-history.com with a token, or use the mystarhistory CLI locally: python3 mystarhistory.py --repo owner/repo (requires read access).

Yes, with a caveat. The GitHub Action's default GITHUB_TOKEN has read access to the repo it runs in, including private repos, so stargazer data is accessible. However, the generated SVG will be committed to a star-history branch in the same private repo - and raw.githubusercontent.com URLs for private repos require authentication to view. This means the chart will only be visible to repo collaborators, not the public. For private repos, this is usually fine since you're the only audience. If you want to display a private repo's star history publicly, you would need to commit the SVG to a public repo or a GitHub Pages site instead.

The generated SVG is approximately 15 KB per theme (light and dark), so about 30 KB total for both themes. This is smaller than most README badge images and small enough to commit without bloating the repository. The file is a self-contained SVG with the Handlee font embedded as a subset (only the characters used in the chart), the sketch filter definition, and the chart paths. No external resources are loaded. For comparison, a typical GitHub README badge SVG is 2-5 KB, and a screenshot PNG of the same chart would be 50-100 KB. The SVG scales to any resolution without quality loss, making it ideal for retina displays and high-DPI screens.

The stargazers API is the endpoint at /repos/{owner}/{repo}/stargazers on the GitHub REST API. It returns a list of users who have starred a repository, along with a timestamp for each star (when they clicked the star button). This timestamp data is what makes star-history charts possible - by plotting cumulative stars over time, you can see when a project gained momentum. GitHub restricted this endpoint on June 30, 2026, limiting access to the repo's own admins and collaborators. The restriction was motivated by privacy concerns (the endpoint exposed user identities and activity patterns) and API abuse prevention (the data was being scraped for surveillance, spam targeting, and competitive intelligence). Repo owners can still access their own stargazer data with an authenticated request.

Yes, that is exactly what mystarhistory is designed for. The only external dependency is the gh CLI (GitHub's official command-line tool), which you need to authenticate and fetch stargazer data. The renderer itself (mystarhistory.py) uses only the Python 3 standard library - no pip install, no numpy, no matplotlib, no pillow. The Handlee font is embedded directly in the SVG output. The Docker GitHub Action packages everything (Python, gh, git) in a single container. Once the SVG is generated, it's a completely self-contained file that renders in any browser, any README, any markdown renderer, with no external requests, no JavaScript, and no font loads.