Making a GitHub repository private is one click and one confirmation: open the repository, go to Settings, scroll to the Danger Zone, and change visibility. The setting itself takes seconds. What catches people out is everything downstream of it: public forks get detached into their own network rather than turning private with you, GitHub Pages built from a private repository needs a paid plan rather than working on GitHub Free, and GitHub Actions minutes start drawing from the plan’s included quota instead of running unmetered. This covers the UI path, the one-line gh CLI equivalent, exactly what changes when the flip happens, and how to keep deploying once the repository a service builds from is no longer public.
There’s rarely a mystery about why a repository goes private. A side project turns into something with paying users, a client asked for it, or code that was fine to share while learning shouldn’t stay public once it has real credentials or business logic in it. The setting itself is simple. The parts worth knowing before doing it are the ones GitHub doesn’t spell out in the confirmation dialog: what happens to existing forks, whether GitHub Pages still works, whether CI minutes start counting against a quota, and whether anything that deploys from the repository needs reconfiguring afterward. This walks through both the dashboard and CLI paths, the actual consequences verified against GitHub’s own documentation, and what deploying from a private repository looks like once it’s done.
Table of contents
- Making the change from Settings
- The gh CLI equivalent
- What happens to forks
- What happens to stars, watchers and search visibility
- GitHub Pages on a private repository
- GitHub Actions minutes after the switch
- Deploying once the repository is private
- How this fits the rest of the stack
- FAQ
Making the change from Settings
From the repository, open Settings, then General, scroll to the bottom, and the Danger Zone has a Change repository visibility button. Selecting Make private shows a confirmation that names the repository and requires typing its full name to confirm, a deliberate friction point, since the action has real consequences for anyone who has forked or starred it. For background on how GitHub, GitLab and plain Git differ as concepts before picking visibility settings specific to GitHub, see Git vs GitHub vs GitLab.
GitHub requires repository admin access to change visibility, and for an organization-owned repository, the organization’s settings can also restrict who is allowed to change visibility at all, independent of individual repo permissions. If the option is missing or greyed out, that’s usually the org policy rather than a bug.
- Settings tab on the repository, not the organization or account settings
- Danger Zone section, near the bottom of General settings
- Change visibility, then Make private, then type the repository name to confirm
The gh CLI equivalent
The same change from a terminal, useful for scripting or for repositories managed outside the browser, uses the GitHub CLI. If your team also manages GitLab access tokens, our post on GitLab personal access token expiry covers the parallel problem over there.
gh repo edit OWNER/REPO --visibility private --accept-visibility-change-consequencesThe —accept-visibility-change-consequences flag exists because gh refuses to make a visibility change that could affect other users, such as detaching forks or breaking dependent workflows, without an explicit acknowledgment; omitting it fails the command with an error naming the flag rather than making the change silently. Running it against the current directory’s repository works without specifying OWNER/REPO if gh is already inside a cloned copy.
gh repo edit --visibility private --accept-visibility-change-consequencesReversing it later is the same command with —visibility public, which is worth knowing before treating the change as one-way. It isn’t, though forks detached during the private period stay detached.
Before running either version, gh repo view OWNER/REPO —json visibility confirms the current setting, which is a cheap sanity check before a scripted change touches the wrong repository, especially in a loop over several repositories at once.
What happens to forks
Public forks of a repository that goes private are detached from the parent and placed into a new, independent network rather than becoming private along with the original. They are not deleted and they are not made private; they keep whatever visibility they already had, just disconnected from the upstream repository’s fork graph. That means pull requests open from those forks against the now-private repository stop being usable in the normal cross-fork way, and anyone relying on git fetch upstream against the old relationship needs to re-point it manually.
This is a one-way effect for the fork network specifically: switching the repository back to public later does not automatically reconnect forks that were already detached while it was private. If the repository has meaningful public contribution activity, it’s worth notifying anyone with an open pull request before the switch, since their access to the conversation and the diff disappears the moment the repository becomes private and they aren’t already a collaborator.
What happens to stars, watchers and search visibility
Existing stars and watchers are retained on a repository that goes private, the counts don’t reset, but the repository disappears from public search results, GitHub’s trending pages, and anyone’s view who isn’t a collaborator or, for an organization repository, a member with access. It also drops out of the GitHub Archive Program’s public dataset going forward. None of this shows up in the confirmation dialog, so a repository with a following built up over time should expect that following to lose visibility into new activity immediately, even though the historical star count doesn’t change.
For a repository that was being used as a portfolio piece or a public proof of work, this is the detail that matters most: going private removes it from view for anyone evaluating it externally, even though nothing about the code itself changed. Reversing the decision later restores that visibility, but any links shared while it was private will have returned a 404 in the meantime.
GitHub Pages on a private repository
This is the part that surprises the most people: on GitHub Free, Pages can only be published from a public repository, as documented in GitHub’s own Pages plan requirements. A private repository on the Free plan cannot serve a GitHub Pages site at all; the option is unavailable in the repository’s Pages settings until either the repository goes public again or the account upgrades. Publishing Pages from a private repository requires GitHub Pro on a personal account, or a paid GitHub Team or Enterprise plan for an organization. For background on turning a repository into a Pages site in the first place, see Getting Started With GitHub Pages, which covers the settings this section assumes.
If a Pages site is already live on a repository about to go private, check the plan first: the site either needs to move to a public repository, or the account needs the paid tier that unlocks private-repo Pages, before the visibility change happens. Otherwise the site goes down the moment the repository does.
GitHub Actions minutes after the switch
Public repositories run GitHub-hosted Actions runners unmetered on standard runners. Once a repository is private, its Actions usage draws from the account or organization’s included minutes for the plan, and then from paid usage beyond that allotment. A workflow that ran for free indefinitely on a public repository starts consuming quota the moment the repository is private, which is easy to miss until a billing notice arrives. Checking the plan’s included minutes and current usage under account billing settings before flipping visibility avoids the surprise, particularly for a repository with an active CI pipeline running on every push.
Self-hosted runners are one way around this, since they use the organization’s own compute rather than GitHub’s, and their usage doesn’t draw from the included-minutes quota at all. That’s more infrastructure to maintain, so it’s usually only worth it once Actions usage on a private repository is already a meaningful line item.
Deploying once the repository is private
A private repository still deploys the same way a public one does, as long as whatever builds from it has permission. On GitHub itself, a deploy key or a GitHub App installation grants a specific service read access to one private repository without handing over full account credentials, the same pattern used for CI systems and third-party deploy integrations. On RunxBuild, connecting a private repository to a web service works the same as a public one: authorize access once through GitHub, and the dashboard pulls from it on every push, same build logs and rollback behavior either way. Nothing about the deploy path assumes the source is public; visibility is a GitHub-side concern, not a hosting-side one.
The same applies to any third-party CI or deployment integration beyond GitHub’s own products: each one authenticates against the repository independently, through its own installed GitHub App or deploy key, and each one needs re-authorizing if it was previously relying on the repository being publicly readable rather than an explicit grant.
How this fits the rest of the stack
Locking a repository down is simple; the fallout is the part worth planning for: detached forks, a Pages site that might need a paid plan or a public mirror, and Actions minutes that start counting against a quota the moment the repository stops being public. None of that should block the decision to go private when the code genuinely needs it; it should just happen with the consequences known in advance rather than discovered in a billing email.
Deploying from a private repository doesn’t get harder once the switch is made; a service connected to it keeps building on every push the same way. The RunxBuild hosting calculator prices a web service against the plan it would run on, so the cost of hosting what used to be a public side project is a known number before the repository visibility changes anything else.
Useful related references:
- Deleting a GitHub Repository: The Danger Zone and What Goes With It
- GitHub Actions Cross Repository: Reusable Workflows vs Dispatch vs Checkout
- Render and GitHub: How Connecting a Repository Actually Works, What Auto-Deploy Does on Every Push, and the Settings That Bite
- Deploying from GitHub on RunxBuild
FAQ
Does making a GitHub repository private delete my stars?
No. Existing stars and watchers stay on the repository when it goes private, the counts don’t reset. What changes is visibility: the repository drops out of public search results, GitHub’s trending and Explore pages, and the public GitHub Archive dataset, and only collaborators, or organization members with access, can see it going forward. Anyone who starred it before can still see it in their own starred list.
What happens to forks when a repository goes private?
Public forks are detached from the repository and placed into their own independent network rather than becoming private with it. They are not deleted and keep whatever visibility they already had, but they lose their connection to the original repository’s fork graph, so cross-fork pull requests and git fetch upstream against the old relationship stop working as before. Switching back to public later does not reconnect forks detached during the private period.
Can GitHub Pages run from a private repository?
Not on GitHub Free. A Free-plan account can only publish Pages from a public repository. Publishing from a private repository requires GitHub Pro on a personal account, or a paid GitHub Team or Enterprise plan for an organization. If a Pages site is already live when a repository goes private, check the account’s plan first, since the site can go down immediately otherwise.
Does GitHub Actions still run for free on a private repository?
Public repositories get unmetered GitHub-hosted Actions minutes on standard runners. Once a repository is private, its Actions usage draws from the account or organization’s included minutes for its plan, then from paid usage beyond that. A workflow that ran indefinitely for free on a public repository starts consuming quota the moment the repository becomes private, so it’s worth checking the plan’s included minutes beforehand.
What is the gh CLI command to make a repository private?
gh repo edit OWNER/REPO —visibility private —accept-visibility-change-consequences, or omit OWNER/REPO when run inside a cloned copy of the repository. The —accept-visibility-change-consequences flag is required because the command refuses to change visibility silently when it could affect forks or dependent workflows; leaving it off fails the command with an error rather than making the change.