GitFut: a GitHub profile scored out of 99 as a World Cup player card
Your GitHub stats, turned into a World-Cup-style player card
At a glance
- What is it?
- GitFut turns a live GitHub profile into a FIFA-style card with six football stats and a set of yearly trophies. It is a Next.js app you can self-host, and the scoring rules are the interesting part.
- Who is it for?
- Adopt GitFut if you want a self-hosted, MIT-licensed card generator whose scoring rules are written down in the README, and if you accept that the number is a game and not a performance review. Skip it if you need per-repo analytics, if you want a stable score to compare across quarters, or if you cannot supply a GitHub token with the scopes the GraphQL queries need.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 43 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem GitFut solves, and who it is actually for
A GitHub profile page shows activity as a green grid and a list of pinned repositories. It does not answer the question people ask when they look at someone's account: how strong is this profile, in one number? GitFut answers that with a football card. The README states the premise directly: "your GitHub, rated out of 99". Six signals are read from a live profile and mapped to the football stats printed on a FIFA-style card, then the card is exposed as an image URL that can be dropped into a profile README or a portfolio page.
The audience is narrow and specific. It is for developers who already publish a profile README and want something more distinctive than a stats card, and for anyone who wants to run that generator on their own infrastructure rather than depend on a hosted service. The repository is a full Next.js application, not a library and not a GitHub Action. There is a Dockerfile, a package.json with a build and a start script, and a public deployment at gitfut.com. If you only want the card, you use the hosted URL. If you want to change how the scoring works, you clone the app.
One thing worth saying early: this is a game. The README never claims the overall rating measures engineering ability, and the mapping between commits and Pace is a metaphor, not a metric. Treat the number as a conversation piece and the project is fine. Treat it as a hiring signal and you are using it for something it was not built to do.
How six GitHub signals become PAC, SHO, PAS, DRI, DEF and PHY
The scouting pipeline reads a profile through GitHub's GraphQL API and derives six stats. The README gives the mapping in a table: Pace from commits in the last year, Shooting from stars earned across repositories, Passing from pull requests plus followers, Dribbling from language diversity, Defending from reviews plus issues, and Physical from lifetime contributions. The overall rating is described as the headline figure. Raw stats are capped at 88, and the README explains why: the 90s are a legacy gate earned over years, so a single strong year cannot produce an Icon card.
Position and archetype come from the shape of the six stats rather than from a separate input. The README gives two examples: a shooting spike scouts a poacher up top, and a defending-and-passing lean scouts a deep playmaker. There is no configuration file where you declare yourself a striker. The card is a function of the numbers.
Cards are then grouped into finishes by overall rating. The README lists Bronze at 64 or below, Silver from 65 to 74, Gold from 75 to 84, TOTY from 85 to 89, and Icon at 90 or above. In-Form is separate and is described as a spike rather than a band. The awards layer sits on top of this and is where the design gets opinionated.
The award rulebook is the most thought-through part of GitFut
Yearly awards are judged on one score per year, and the README prints the formula:
yearScore = 4·log(commits) + 3·log(PRs) + 3·log(reviews) + 2·log(issues) + 2·log(private)The logarithms are the anti-spam mechanism, and the README quantifies the effect: 20,000 commits score 17.2, barely ahead of the 13.2 that 2,000 commits earn, while a year of 800 commits, 80 pull requests, 80 reviews and 40 issues scores 26. Breadth collects from every term; volume on one axis stalls. The README is also honest that there is no balance requirement, so a commits-only kernel maintainer still scores on the volume terms alone.
The Ballon d'Or requires at least two years of history and three conditions: 2,000 or more raw contributions, a year score of 16 or higher, and one of two paths. The spike path needs a year at 1.2 times the career-median year. The elite path needs a score of 19.5 or higher with the ratio waived, and the README explains the reasoning: a sustained-great career has a large median that no single year can tower over, and those are the years the award exists for. Repeats are gated on the card's overall rating, with 80 holding one, 87 unlocking a second and 94 a third; Icons can take a fourth, and only for a year scoring 28 or above. The current year competes while in progress but can only under-score, never over-score, so nothing is awarded on a projection.
The WC Golden Ball is judged per tournament window, with era adjustment. The README lists five editions from South Africa 2010 to North America 2026, with the 2010 bar being presence at all, 2014 a handful of contributions, and 2018, 2022 and 2026 requiring a real window at 1.2 or 1.3 times your own pace. The pace test compares your daily rate inside the window to your daily rate across the same year, and for the current year the pace is computed over elapsed days rather than 365 so a routine mid-year cannot masquerade as tournament form. The Golden Boot is held on current form and requires elite Shooting at 80 or above from a scoring position among ST, RW and CAM. Every trophy except the Spanish gift also requires an overall of 80 or higher, which the README calls a floor rather than a driver.
My read: the log scaling and the median-relative spike test are the two decisions that keep the award from being farmable by commit volume alone. The 80 overall floor is the weaker part, because it makes the trophy set depend on a rating whose own inputs are capped and partly derived from stars and followers, which are not things a single developer controls.
Installing GitFut and generating your first card
The repository is a Next.js app with a Dockerfile. The README does not include a local setup walkthrough, so the steps below come from package.json and the Dockerfile rather than from documentation.
The package.json defines the scripts you would use in development. Running the dev server is the shortest path to a card you can look at.
npm ci
npm run devThe Dockerfile is a multi-stage build on node:22-alpine. It runs npm ci in a deps stage, builds in a builder stage with NEXT_TELEMETRY_DISABLED=1, and copies the standalone output into a runner stage that drops to a non-root nextjs user. The container listens on port 3000, and the file sets PORT=3000 and HOSTNAME="0.0.0.0" before starting with node server.js. The build expects the standalone output that next build produces, so the next.config.ts in the repository has to be emitting it for this image to run.
docker build -t gitfut .
docker run --rm -p 3000:3000 gitfutOnce it is up, a card is a URL. The README documents three routes: gitfut.com/<username>.png for the live image, gitfut.com/<username> for the full scout report, and a ?country=XX query parameter to override the flag, with ?country=DZ given as the example. To embed the card in a profile README, the README gives this Markdown snippet:
[](https://gitfut.com/YOUR_USERNAME)Self-hosting means replacing the host with your own origin. The README does not document which environment variables the GitHub GraphQL queries need, and the repository has instrumentation files for Sentry and a dependency on ioredis, so a deployment will need a GitHub token and a Redis instance that the README does not spell out. That gap is the first thing to resolve before you invest time in a deployment.
Where GitFut breaks down or is the wrong tool
The most concrete limitation is the cap. Raw stats stop at 88, so the visible difference between two strong profiles is compressed into the top of the range, and the overall rating is not a linear scale you can compare across time. A profile that improves steadily may show almost no movement until it crosses an award threshold.
The second is the input mix. Shooting is stars earned across repositories and Passing includes followers. Those are popularity signals, not work signals, and they are the two terms in the card that a developer has the least direct control over. The yearly award formula does not use stars or followers at all, which means the card's headline number and its trophy case are measuring partly different things.
The third is operational. The README describes a live service that re-fetches profile data and renders an image. It does not document caching behavior, rate-limit handling, or what happens when GitHub's GraphQL API returns an error, even though the repository depends on ioredis and ships Sentry configuration on both the server and the edge. If you self-host this and your token hits a rate limit, the README gives you no documented failure mode to plan around.
Finally, the scope. There is no per-repository breakdown, no comparison across a team, and no historical charting beyond the yearly totals used for awards. If you want to know which repository is consuming your review time, this is the wrong tool. It answers one question: what does this profile look like as a player card?
GitHub Readme Stats and the difference in approach
The closest well-known alternative is GitHub Readme Stats, which renders a stats card or a top-languages card as an SVG you embed with a URL. The two projects share the delivery mechanism, a hosted image endpoint you paste into a README, but they differ in almost everything else.
GitHub Readme Stats reports the numbers it reads: total stars, total commits, a language breakdown, a rank computed from a documented formula over those totals. The output is a chart. GitFut does not report the underlying numbers at all. It maps them onto six football stats, derives a position and an archetype from the shape of those stats, and then applies a separate yearly award system with its own log-scaled formula, median-relative tests and tournament windows. The card is a character sheet, not a dashboard.
The practical difference for a reader is what happens when the number is unflattering. A Readme Stats card is a table you can read and argue with. A GitFut card is a rating with a finish attached, and the README's own design notes (the 88 cap, the legacy gate on the 90s) show that the authors thought about how the rating would feel, not only about what it would measure. That is a design choice, not a defect, but it means GitFut is the worse option if you want to see the raw inputs.
Maintenance, licence and what self-hosting commits you to
The last push to the repository was on 2026-08-05. The repository is not archived. The version in package.json is 0.1.0, and no releases were retrieved, so there is no published changelog to read and no tagged version to pin against. If you deploy this, you are tracking the master branch.
The dependency set is the real upgrade cost. The app runs Next.js 16.2.9 with React 19.2.4, Tailwind CSS 4, TypeScript 5, Vitest 4 and Playwright, plus Sentry, ioredis and sharp. Several of those are major versions, and a Next.js major upgrade is not a small change for an app that renders images on the server. There is a tests directory and a vitest.config.ts, and the test script is vitest run, so there is some safety net, but the README does not describe test coverage or a CI workflow beyond the presence of a .github directory.
The licence is MIT, declared in package.json and present as a LICENSE file at the repository root. That permits use, modification and redistribution with the copyright notice and permission notice retained. It says nothing about the hosted service at gitfut.com, which is a separate matter from the source. If you fork and deploy, you are responsible for the GitHub API usage your instance generates, and the README does not discuss API terms or quotas. This is a description of what the licence text allows, not legal advice.
Editorial conclusion
Adopt GitFut if you want a self-hosted, MIT-licensed card generator whose scoring rules are written down in the README, and if you accept that the number is a game and not a performance review. Skip it if you need per-repo analytics, if you want a stable score to compare across quarters, or if you cannot supply a GitHub token with the scopes the GraphQL queries need. Before you deploy, verify that your token covers the private-contribution read the scoring uses, that Redis is reachable, and that the awards you expect actually appear on your own card, because the README documents the rules but not the edge cases.
Frequently asked questions
What is GitFut and what does it do?
GitFut turns a GitHub profile into a World-Cup-style player card rated out of 99. It reads six signals from a live profile through GitHub's GraphQL API and maps them to PAC, SHO, PAS, DRI, DEF and PHY, then serves the card as an image at gitfut.com/<username>.png.
How do I install GitFut and run it myself?
The repository is a Next.js app with a Dockerfile. The package.json scripts are npm run dev, npm run build and npm run start, and the Dockerfile builds a standalone image that listens on port 3000. The README does not document the environment variables a self-hosted instance needs.
How is the GitFut overall rating calculated?
The README states that the overall is the headline figure derived from the six stats, and that raw stats cap at 88 because the 90s are a legacy gate. It does not publish a single formula that combines the six into the overall.
What does GitHub stand for?
The material for this project does not cover the origin of the GitHub name; it only describes reading profile data through GitHub's GraphQL API.
What is Git used for?
The material for this project does not explain Git itself. GitFut reads contribution data from a GitHub profile and does not document version control usage.
Community notes