How to add sponsorship options to a GitHub repo

How do I add sponsorship options to my GitHub repo

Add a FUNDING.yml file in the repository’s .github folder on the default branch, then turn on Sponsorships in the repo settings. GitHub uses that file to show a sponsor button and the funding links you list there. GitHub documents this in the repo customization and sponsor-button guides.

The fastest path is to edit .github/FUNDING.yml from the repository itself. GitHub says anyone with admin permissions can enable the sponsor button, then click Set up sponsor button or Override funding links in the Sponsorships box. After that, commit the file change to the default branch so GitHub can read it.

A basic FUNDING.yml can point to GitHub Sponsors, Patreon, OpenCollective-style external pages, or a custom URL. GitHub allows one username, package name, or project name per external funding platform, plus up to four custom URLs, and one organization plus up to four sponsored developers for GitHub Sponsors.

A simple example looks like this:

yml github: [your-github-username] patreon: your-patreon-name custom: ["https://your-site.example/support"]

GitHub notes that if a custom URL contains a colon, you should wrap it in quotes. That is the part people miss when they paste a normal URL array and the file does not parse the way they expect.

If you want the button to appear for the repository, go to the repo page, open Settings, then General, then the Features section, and select Sponsorships. GitHub’s documentation says the sponsor button is controlled from repository settings, not from the README alone.

The part people get wrong is assuming a README link is enough. A README can mention support, but GitHub’s sponsor button comes from the sponsorship feature and the funding file. If the button does not show up, check that the file is on the default branch, that the repository settings feature is enabled, and that the account type is allowed to receive sponsorships.

If you are an individual contributor, GitHub Sponsors lets sponsors support your profile directly. GitHub says sponsors can choose one-time or monthly sponsorships, and can sponsor a profile through their personal account or an organization account. For open source contributors, GitHub also recommends offering a range of sponsorship options, including monthly and one-time tiers.

If you are setting this up for an organization, the path is slightly different. GitHub says organization owners can set up GitHub Sponsors for an organization, complete the sponsored profile, create tiers, submit bank and tax information, enable 2FA, and submit the application for approval. That is for receiving sponsorships as an organization, not just displaying a repo button.

If you want reward-based sponsorships, use sponsorship tiers. GitHub lets you publish up to 10 one-time tiers and 10 monthly tiers, with each tier defined by its own amount and description. You can use tiers for benefits like early access, newsletter updates, or private repository access.

Private-repository access is the part that usually needs attention. GitHub says you can add a repository to a sponsorship tier only if the repository is private, owned by an organization, and you have admin access. When you add it, GitHub sends invitations to new sponsors and removes access when a sponsorship ends.

If you want the repo itself to be the benefit, make that clear in the tier description and in the welcome message. GitHub supports a welcome message for a tier, and that message appears after payment and in the welcome email. That is the place to explain how access is granted, where the private repo lives, and what a sponsor should do if they do not see the invitation.

The inconvenient part is that sponsorship links are not a substitute for a real funding setup. GitHub says funding links are meant for open source projects receiving direct financial support, and not for advertising or unrelated causes. If you want the repo to represent a real support path, the funding target should match the project and the work behind it.

A practical setup for most repos is simple: add the sponsor button, point the funding file at one or two real support options, then keep the tier list short. Too many choices slow people down. GitHub’s own guidance says to make sponsorship easy to understand, and the repo button is only useful when the destination is clear.

If you already have GitHub Sponsors enabled on your profile, link the repo button to that profile through github: in FUNDING.yml. If you use an external platform, keep the link current, because GitHub will show what the file says on the default branch, not what you intended last month. That is why stale funding files confuse supporters and make the button feel broken.

A clean workflow is: create or update .github/FUNDING.yml, commit it to the default branch, enable Sponsorships in repo settings, then verify the button on the public repository page. If you manage an organization, also confirm that the sponsored profile and payout setup are complete before announcing the button. That avoids a public call to support that goes nowhere.

If you want a place to coordinate testers, contributors, or launch help around the repo, you can also use DevConnect at https://devconnectplatform.com, but that is separate from GitHub’s sponsorship feature. GitHub still needs the funding file and the settings change before the sponsor button appears.

Common mistakes

People often put the funding link only in the README and expect the sponsor button to appear. That does not happen. GitHub reads FUNDING.yml from the .github folder on the default branch, and the repository settings need Sponsorships enabled before the button appears.

Another common mistake is using the wrong branch. GitHub says the file must live on the default branch. If you edit it on a feature branch and never merge it, the public repo page will not show the change. That is a simple failure, but it is easy to overlook during a rushed release.

A third mistake is overcomplicating tiers. GitHub supports both one-time and monthly tiers, but you do not need many of them to start. A small set of clear tiers is easier to maintain, easier to explain, and easier for sponsors to choose from.

When the button still does not appear

If the button is missing after you set everything up, check three things in order: the file path, the default branch, and the Sponsorships toggle in repository settings. Then confirm that the account behind the repository can actually receive sponsorships and that the funding links are valid. GitHub’s docs separate display settings from sponsorship setup for a reason.

For organizations, the approval and payout side can block the flow even when the repo config is correct. GitHub’s organization setup requires the sponsored organization profile, financial details, tax details, and approval steps. That means the repo can be ready before the organization is fully ready to receive money.

A simple setup that works

Start with one GitHub Sponsors profile link, one external support link if you need it, and a short tier list if you offer rewards. Put the file in .github/FUNDING.yml, commit to the default branch, enable Sponsorships, then test the public repo page in a fresh browser session. That sequence matches the way GitHub documents the feature.

If you want private repo access as a reward, configure it through sponsorship tiers, not through the repo README. GitHub handles access and revocation automatically when the tier is tied to a private repository, which makes it a better fit than manual invite tracking.

FAQ

Can I use sponsorship links without GitHub Sponsors

Yes. GitHub’s funding file supports external funding platforms and custom URLs, not just GitHub Sponsors. The sponsor button can point to those destinations if they are listed in FUNDING.yml.

Do I need a public repository

The sponsor-button guide is written for repository settings on GitHub, and the button is meant to increase visibility of funding options on a repository page. For private-repo access as a reward, GitHub says the repository must be private and owned by an organization.

Can I add more than one support option

Yes. GitHub allows multiple funding destinations in FUNDING.yml, including GitHub Sponsors, external platforms, and custom URLs. GitHub also supports multiple sponsorship tiers when you are using GitHub Sponsors directly.

Should I put prices in the README

You can, but the real source of the button and the links is still FUNDING.yml. If the README and the funding file disagree, the button will follow the funding file on the default branch. Keep the README as a human explanation, not as the source of record.