How to Grow GitHub Stars Without Buying Them?

One of our customers' open-source repos grew by 1,512% in six weeks on zero paid spend, and it happened because the team changed where the project appeared.

That single fact explains almost everything in this guide. Below is how to get your first ones, how to fix a repo that's stopped growing, why paying for stars costs you more than it saves, and what realistic growth actually looks like by stage.

Key takeaways

• Stars are a one-click bookmark. They cost a developer nothing and commit them to nothing, which is exactly why they're easy to get and easy to fake.
• A front-page Hacker News or Product Hunt launch decays inside about 72 hours. A distribution system built around Reddit, README quality, and repo hygiene can still be accelerating in week six.
• Buying stars is not a gray area. Carnegie Mellon researchers found more than 6 million suspected fake stars on GitHub, and about 60% of repos running fake-star campaigns were phishing or malware, not harmless resume padding.
• The README is the actual landing page. Three separate sources, on three separate projects, arrived at the same rule independently: you have about five to fifteen seconds before a visitor decides to leave.
• Reddit converts better than Hacker News or Product Hunt when it's done as genuine participation rather than a promotional post. One open-source team saw an 80,000-to-100,000-impression Reddit push convert at 5 to 8% into GitHub stars, versus roughly 1% from a Product Hunt-style ask.

What does a GitHub star actually mean?

A star is a bookmark. Clicking it takes a developer one second, adds the repo to their personal "stars" page, and signals nothing more than "I want to find this again" or "I like this." It doesn't mean the person installed your tool, read your docs, or ever came back. GitHub's own documentation describes starring as a way to "keep track of projects you find interesting," which is a much smaller claim than most founders assume a star makes.

Having said that, the number is not meaningless. GitHub confirms directly that "many of GitHub's repository rankings depend on the number of stars a repository has," and that its Explore and Trending pages surface repos based partly on star counts.

So a star doesn't prove adoption, but it does feed the systems that decide whether the next developer ever sees your project at all.

That's the real value: discoverability, not proof of quality.

One quick point of confusion worth clearing up. "GitHub Stars" is also the name of GitHub's own recognition program for community leaders and advocates, run at stars.github.com. That program has nothing to do with the star count on your repository. If you searched for one and landed here for the other, now you know the difference.

If you want the fuller picture of which metrics actually predict pipeline instead of attention, Infrasity's open-source marketing strategy guide breaks that down in detail.

Are GitHub stars a vanity metric, or do they actually matter?

Both, and the honest answer depends on what decision you're using the number to make. As social proof and a discoverability signal, stars work. As a stand-in for adoption, they lie to you constantly.

Infrasity's own team learned this the hard way while running multiple open-source projects. When they finally set up tracking for downloads instead of stars, they found that roughly half of all downloads never finished installing. The star count on those projects kept climbing the whole time. If you're only watching stars, you have no idea how many of those "wins" ever became a working install.

A cleaner way to think about it is to separate growth into three stages and track different numbers at each one:

A maintainer on GitHub's own community forum put it about as bluntly as it can be put: responding to a "how do I get more stars" thread, developer lissy93 wrote that "stars don't mean a lot, they're a vanity metric," and that the real target is users, because users produce stars as a side effect, not the other way around.

That's a practitioner talking, not a marketer, and it lines up exactly with what the data above shows.

How many GitHub stars should you actually have?

There's no universal number, but there are honest ranges you can use to check your own progress, and a growth pattern that matters more than any single benchmark.

For a brand-new, early-stage project, somewhere around 50 to 100 stars is enough to signal that real people looked at it and didn't bounce immediately.

Crossing roughly 1,000 stars is usually the point where a project starts reading as "established" to a developer doing a quick evaluation.

Category leaders run into the tens of thousands, but comparing yourself to them is the wrong exercise, because they've usually had years and a much bigger addressable audience.

Our customer found themself in a similar situation; here's how we helped them: MemClaw case study.

Also there's the outlier ceiling. Kamran Ahmed, the founder of roadmap.sh, has grown that project's main repository past 300,000 stars. It's not a fair comparison point for a new repo, but the growth shape behind it is instructive, and we'll come back to it in the next section.

The pattern that matters more than any specific number is the shape of the curve, not its height.

A big Hacker News or Product Hunt launch produces a spike that typically decays within about 72 hours, based on repeated observation across dozens of launches Infrasity has tracked.

A distribution system built the right way does the opposite. In the MemClaw engagement, the repo went from flat at 15 stars for weeks, to an inflection within days of the first Reddit wave (17 to 63 stars), to steady compounding (135 stars by late June), to its fastest single stretch of growth in week six, crossing 200 stars. Growth accelerating in week six is the signature of a system compounding. A launch spike wearing off looks nothing like that.

Before you plan a launch, it's worth auditing where your repo currently stands on the things that actually predict whether a launch will land. Infrasity's free OSS Launch Visibility Checklist walks through exactly that.

How do you get your first 100 GitHub stars?

If you're starting from zero, these tactics are most likely to help you gain early traction.

Make the README do the selling before you promote anywhere

Every credible source on this topic, independently, arrives at the same number: you have somewhere between five and fifteen seconds before a visitor decides whether to stay.

That's true whether the source is a marketing agency, a demo-video vendor, or a solo founder who has personally grown a repo past 300,000 stars.

A README that holds attention does a few specific things. It states, in one plain sentence near the top, what the project actually does. It shows the thing working, through a screenshot or a short clip, instead of describing it in the abstract.

It gives a copy-paste quick start that runs on the first try, on a clean machine, not just the machine it was built on. And it sets a custom social preview image in the repo settings, so the link looks intentional wherever it gets shared.

Kamran Ahmed built the first version of roadmap.sh in about two hours, using a wireframing tool to draw two simple learning-path diagrams for front-end and back-end development. He posted it to Hacker News and Reddit, and it crossed roughly 1,000 stars within eight to ten hours.

In a separate project, notes he'd written for his own interview prep ("Design Patterns for Humans"), a single Sunday-evening Hacker News post brought around 250 upvotes and one to two thousand stars in a day. Neither project was polished. Both worked because the value was obvious in the first few seconds, which is the same rule stated three different ways by three unrelated sources.

Be honest with yourself about the "friends and family" round

A widely-cited playbook from the team behind the open-source tool Preevy describes an explicit first phase: asking coworkers, friends, and family to star the repo, going as far as printing a QR code and walking a shared office floor. That got them to their first 100 stars before they shifted into what they called organic growth.

There's a real distinction worth drawing here, because a lot of content on this topic blurs it. Asking twenty people you actually know to look at something you built, and being upfront that you'd appreciate a star if they like it, is a normal, honest way to get an early signal. It is not the same thing as paying a marketplace for stars from accounts that never existed as real people. The next section covers exactly where that second line sits and why crossing it costs you more than it gets you.

Post where developers already gather, and say why you built it

Hacker News and Reddit did the early lifting for our biggest projects, and Reddit specifically became our main source of traffic over time, because a single project can be submitted across four or five relevant subreddits, while Hacker News only has one front page to compete for.

The mechanics that separate a post that lands from one that gets ignored or removed are consistent across every credible source we reviewed: post the actual GitHub link, not a company landing page; open with the problem you personally hit, not a feature list; and if you're posting to Reddit specifically, read that subreddit's self-promotion rules first, because getting removed for ignoring them tanks trust in that community going forward.

If you'd rather have a team that already knows which threads convert and which ones get you banned run this for you, that's what Infrasity's free consultation covers first: an audit of where your project is currently invisible across the five buying questions your actual customers are asking, on GitHub, on Reddit, and increasingly inside AI answers.

How Do You Increase Stars On a Repo That's Already Stalled?

Getting your first 100 stars and reviving a repo that's been flat for months are different problems, and most advice online doesn't separate them. If your repo is stalled, promoting it harder before fixing what's underneath will waste the traffic you do get.

Audit before you promote

Start by finding out exactly where you're invisible. The method that worked for MemClaw: write down the five specific questions a buyer in your category would type into ChatGPT, Claude, Gemini, or Perplexity before choosing a tool like yours, not brand names, but the actual questions.

Run each one across all four models and log which competitors get named, in what order, and whether they're cited. Then check whether your project appears in the Reddit threads and comparison pages that those models cite as sources.

In MemClaw's case, that audit turned up 78 specific Reddit threads that ChatGPT, Perplexity, and Google's AI were already citing to answer those five questions, none of which mentioned MemClaw at all. That list became the exact target list for outreach.

Do the same, or use an AI visibility tool to find the content gap and opportunity prompts to target.

Fix repo hygiene, because it's cheap and it compounds

A handful of small fixes carry outsized weight. Use the bare project name for the repo (mem0ai/mem0, not caura-ai/caura-memclaw), because every strong competitor does this and a prefix adds friction to search and recall.

Fill in your GitHub Topics field completely; you can add up to twenty, and a repo with zero topics gets zero topic-page discovery.

Add a COMPARISONS.md file that factually lays out how you stack up against the two or three tools people already compare you to, on the specific dimensions where you actually win.

Competitors rarely publish this because they often can't, and it gives AI models a clean, structured page to quote when someone asks for a comparison.

Finally, label a handful of issues "good first issue," because contributors are the strongest retention signal an open-source project has.

Build proof instead of making promises

Developers don't trust claims. They clone repos. The method that consistently out-converts a polished landing page is a small demo repository reverse-engineered from a real complaint you find in an existing Reddit thread: quote the exact pain in your README so the person who wrote it recognizes it instantly, then build a scenario that reproduces that specific failure and runs locally in under ten minutes on a cheap machine.

If it needs a cloud account or half a day of setup, it isn't proof anymore; it's homework, and most developers won't do homework for a tool they haven't decided to trust yet.

Understand how GitHub actually decides what's trending

GitHub Trending is not a lifetime leaderboard. It ranks repos by stars gained inside a short window (daily, weekly, or monthly) relative to their recent baseline, which means a concentrated burst of 80 stars in one day can outrank a slower repo that added twice that over a month.

That's the mechanical reason coordinated launches work at all, and it's also why a slow trickle of promotion spread across two weeks almost never crosses the trending threshold, even if the total stars end up higher.

Once a stalled repo is fixed structurally, the growth trigger sometimes isn't more promotion at all; it's a real product improvement.

When Kamran Ahmed converted the roadmap.sh's static diagrams into an interactive version, monthly visitors roughly doubled, from about 100,000 to 200,000, within one to two months, with no separate promotional push behind it.

Sometimes the highest-leverage move for a stalled repo is shipping the thing people have been asking for in your issues, not posting about it more.

If auditing and fixing all of this yourself sounds like a lot to run alongside actually building the product, Infrasity's GitHub Marketing service runs this exact audit-to-hygiene-to-distribution motion for developer-tool and AI infrastructure teams.

Which Channels Actually Convert Visitors Into Stars?

Not all traffic behaves the same way, and the gap between channels is bigger than most teams expect. When the open-source tool AFFiNE ran a Product Hunt-style push through Reddit, it drove 3,000 to 4,000 impressions with roughly a 1% conversion rate to upvotes. When the same team ran an open-source-focused Reddit push for the same product, framed around the actual problem instead of an upvote ask, it drove 80,000 to 100,000 impressions with a 5 to 8% conversion rate to GitHub stars.

Same platform, same team, radically different result, because the pitch changed.

A separate comparison from the open-source coding tool Watermelon shows the same pattern from a different angle.

Its founder launched the same tool on both platforms: #2 on Hacker News brought 107 points, 61 visitors to the GitHub page, and over 100 installs. #14 on Product Hunt, without ever reaching the front page, still brought 193 votes, 243 visitors, 30 installs, and ten new GitHub stars in a single day.

Neither channel is useless, but Hacker News converted better for that specific audience, and even a modest, non-front-page Product Hunt placement still produced real stars.

Infrasity's own experience matches this: Reddit is our main source of traffic over time, specifically because a single project fits into several relevant subreddits at once, while Hacker News gives you one shot at one front page.

There's a newer channel worth naming directly, because it changes how you should think about all of the above: developers increasingly ask ChatGPT, Claude, or Perplexity "best open source X" instead of searching Google first.

If your project isn't in the sources those models cite, usually specific Reddit threads and comparison pages, you're invisible to that developer no matter how good your README is. Infrasity's GitHub marketing strategies guide covers the full method for mapping and winning those threads in detail.

If you want a starting map of which Reddit threads in your category are worth your time before you post anywhere, Infrasity's Reddit Opportunity Finder is free to run, and Infrasity's Reddit Marketing service is built specifically to place engineers, not marketers, into the threads that actually convert without getting a project banned from a community.

If you want to plan the full launch end-to-end, Infrasity's OSS Launch Visibility Checklist walks through 57 checks across repo readiness, Show HN, Reddit, awesome lists, syndication, and measurement.

Should You Buy GitHub Stars? Why It Backfires

Yes, it's technically possible. No, you shouldn't do it. And the reason isn't just that it's against GitHub's rules; it's that fake stars are cheap to buy and easy to trace, and the trace-back costs you the exact credibility you were trying to buy in the first place.

Pricing is public and easy to find. Basic packages run around $8 for 100 stars on freelance marketplaces, $25 to $50 for 500 to 1,000 stars delivered gradually to look more natural, and full aged accounts, complete with backfilled contribution history and unlocked achievement badges, sell for as much as $5,000. Some sellers even offer "star insurance," promising to replace any stars GitHub removes.

The data-analytics company Dagster ran its own purchase experiment to see how the marketplace actually behaves. They bought stars from two real vendors,

Baddhi Shop, at $64 per 1,000 stars, and GitHub24, at €0.85 per star. GitHub24 delivered 100 stars to a three-star dummy repo in 48 hours, which was itself the giveaway, since no organic repo grows that fast from a standing start.

Dagster then built a detection method combining simple account-activity heuristics with unsupervised clustering, and reported 98% precision and 85% recall at identifying fake stargazers, even the more realistic-looking "sophisticated fake" accounts.

Within 48 hours of Dagster publishing those findings, every account they'd used to buy those stars had been deleted, whether by GitHub's own trust and safety systems or by the vendors trying to cover their tracks.

The scale of this is bigger than a niche problem. Research from Carnegie Mellon University found more than 6 million suspected fake stars across GitHub, and in July 2024 alone, more than 15% of repositories with 50 or more stars showed signs of involvement in fake-star campaigns.

The part that should genuinely concern anyone evaluating a tool: roughly 60% of repositories running fake-star campaigns turned out to be phishing or malware repositories, using inflated popularity as bait to get developers to install something they shouldn't trust.

That reframes the whole question. Buying stars isn't just against the rules; it's the same tactic attackers use to make malicious code look legitimate, and any developer who checks your stargazers list closely enough will draw exactly that comparison, whether it's fair to you or not.

It's worth being precise about where the real line lies, because much content on this topic blurs it on purpose or by accident.

Messaging twenty people you actually know and asking if they'd take a look is a normal, transparent way to get an early signal, and it's what most successful early-stage projects, including the ones cited throughout this blog, actually did.

Paying a marketplace for stars from accounts that were created solely to inflate a number is a different action entirely, with a different, worse set of consequences. The difference isn't the ask; it's whether a real person made the decision.

The projects referenced throughout this guide grew the harder, slower way, and the shape of that growth is the actual argument against shortcuts.

Earned stars bring real stargazers who fork the repo, file real issues, and sometimes become contributors.

ToolJet, an open-source tool that grew fast through a genuine Hacker News launch, maintains roughly a 1-to-10 fork-to-star ratio, which is a strong sign of real usage rather than passive bookmarking.

Bought stars bring nothing, and the account behind each one is often deleted within days of anyone looking closely.

How Does This Fit Into Your Broader Growth Strategy?

Stars are a lever for getting the right developer to look at your project. They are not the goal, and treating them as the goal is how teams end up with an impressive-looking repo and no real usage behind it.

Everything in this blog points back to the same sequence: audit where you're actually invisible, fix the repo itself so it converts the traffic you already have, then earn attention in the specific places, Reddit threads, comparison pages, and increasingly AI answers, where your next user is already deciding what to try.

For the full ten-play distribution system this guide draws from, Infrasity's GitHub marketing strategies guide covers positioning, listings, and the content loop that feeds AI answers in detail.

For the metrics worth tracking once you've moved past chasing stars, Infrasity's open-source marketing strategy guide covers the full three-stage scorecard.

The AI-answer piece deserves one more mention here specifically because it's the newest part of this whole picture and the one most teams haven't adjusted for yet.

If you want to know exactly where your project currently stands when a developer asks an AI model to recommend a tool like yours, Infrasity's AI GEO Optimization service audits that visibility directly, the same audit method used in the MemClaw engagement referenced throughout this guide.

When You Should Work With Infrasity?

Every number in this guide, the 1,512% star jump, the 78 cited Reddit threads, the fork-to-star ratios, came from repos that ran a real system instead of chasing a single metric. That's the difference between a project that spikes for three days and one that's still accelerating six weeks in.

Infrasity runs this exact motion for AI infrastructure and developer-tool teams: the audit, the repo hygiene fixes, the Reddit engagement done by engineers instead of marketers, the directory placements, and the AI answer visibility work, all measured against a real baseline instead of a vanity number.

If you're launching or trying to revive an open-source repo this quarter, book a free consultation, and the first thing Infrasity will do is show you exactly where your project is invisible across your top five buying questions, the same starting point used for every case study in this guide.

Explore the services: GitHub Marketing, Reddit Marketing, AI GEO Optimization.

Frequently asked questions

How can I find repositories with the highest star counts on GitHub?

GitHub's Explore and Trending pages surface repos by star activity, and Trending can be filtered by programming language and by daily, weekly, or monthly windows. For a full lifetime ranking rather than recent momentum, third-party tools like star-history.com let you compare cumulative star counts and growth curves across multiple repos side by side.

What tools track GitHub star growth or project popularity?

Star-history.com is the most commonly used free tool for plotting a repo's star growth over time and comparing it against competitors. GitHub's own Insights, under the Traffic tab on any repo you maintain, shows visitor counts, clones, and referring sites, which are the more useful data for understanding what's actually driving your growth, as opposed to just how much of it happened.

Can buying GitHub stars get my account banned?

Yes. Purchasing stars violates GitHub's Acceptable Use Policies, and the accounts used to deliver bought stars are frequently detected and removed by GitHub's own trust and safety systems, sometimes within days, as documented directly in Dagster's published research. There's also real reputational risk once a developer or a competitor checks your stargazers list and notices the pattern.

Does a high star count help with hiring or funding conversations?

It can help as a first impression, since a recruiter or investor scanning a GitHub profile quickly will read a strong star count as credibility. It won't hold up under real scrutiny on its own. Anyone doing serious due diligence will look past the star count to contributor activity, issue and PR history, and whether the code actually runs, which is exactly why earned stars with real engagement behind them matter more than the raw number.

What's the fastest legitimate way to get GitHub stars?

Fix the README so the value is obvious in the first few seconds, then post the actual repo link to Hacker News and the two or three most relevant subreddits, leading with the problem you personally solved rather than a feature list. That combination is what produced fast early growth for every real example in this guide, from the roadmap.sh's first day to MemClaw's first Reddit wave.

Is 1,000 GitHub stars a lot?

It depends entirely on your category and how long the project has existed. For a brand-new, narrow-purpose tool, 1,000 stars usually reads as a genuinely successful launch. In a crowded, well-funded category like AI agent infrastructure, competitors can already be sitting at 10,000 to 60,000 stars, which is why comparing your own number against similar projects in your specific category, not against an absolute figure, is the more useful exercise.