Security Guides

#Git #self-hosting #secrets management #supply chain #server

Self-hosted Git vs GitHub: which is actually more secure?

What a self-hosted Git server removes (accidental public exposure), what you take on (patching, backups, secret scanning), and how to make it safer than GitHub.

Published 2026-06-11 Updated 2026-10-04 7 min read

On this page

For: indie developers and small operators wary of GitHub's "accidental public repo" and secret-leak incidents, weighing whether to run a self-hosted Git server (bare git, or Gitea/Forgejo/GitLab). No attack steps here — just the decision of which is safer for your setup.

This site's view: self-hosting only works if you take over what GitHub did

This site itself runs a self-hosted Git server. But the reason isn't only "accidental exposure is scary" — it's separating the scope of impact: one compromised service must not cascade to others. And because we self-host, we always bundle in offsite backups to a separate server, never putting secrets in git, and automated dependency CVE monitoring. Self-hosting's safety comes not from "not using GitHub" but from doing yourself the work GitHub used to do.

1. What self-hosting genuinely removes

Your worry has a valid basis. GitHub's classic "public incidents" simply can't happen on a self-hosted server.

no 'make public' button

no secret left in a public fork

instant

public-repo secrets get exploited

Public repos are continuously crawled by automated scanning bots. Commit an .env or an API key by mistake and bots pick it up before a human notices — exploited within minutes is common (real cases → a key leaked via a public repo and billed for fraud · an entire .env exposed). Self-hosting removes that public surface. "Meant to be private but was public," "a secret you thought you deleted lingering in a public fork" — those classes can't occur by design. That isn't a vague comfort; it's a real advantage.

2. The work you take on when you self-host

This is the crux. GitHub handled a lot of defense for you by default, out of sight. Self-host and those defenses don't exist unless you build them.

GitHub handled this

Blocks secret commits (push protection)
Auto dependency CVE alerts (Dependabot)
Server operation, patching, TLS
2FA, fine-grained access, audit logs
High availability, redundant backups

Now it's your job

Add a pre-commit secret-detection hook
Run dependency CVE monitoring yourself (cron)
Patch the Git server's own vulnerabilities
Key management = effectively all access control
Lost data stays lost unless you prepare a restore

What GitHub guarded for you by default (left) vs what doesn't exist on self-host unless you do it (right).

Two are especially easy to miss. First, a paradox: the secret leak you fear most is something GitHub actually stops for you, by machine. GitHub's push protection rejects commits containing what looks like an API key. A bare self-hosted git has no such check. Accidental exposure is gone, but the accidental commit isn't — so if you self-host, a pre-commit secret hook is mandatory.

Second, the Git server itself becomes a target. Feature-rich servers like GitLab have had multiple serious vulnerabilities (unauthenticated remote code execution, i.e. RCE-class), and an unpatched self-hosted server becomes the way in. More features, more attack surface. Plain bare git + SSH has the smallest surface; GitLab/Gitea are convenient but add the burden of chasing patches yourself.

3. How to make self-hosting safer than GitHub

The minimum set that makes self-hosting genuinely — not cosmetically — safe. Only with these is "safer than GitHub" true.

Stop secrets before the commit

Add a pre-commit hook (gitleaks, etc.) that automatically blocks commits containing API keys, .env, or private keys. This replaces GitHub's push protection.

Minimize and patch the Git server

Default to the small-surface bare git + SSH. If you use a feature-rich server, track its CVEs and patch promptly as a standing routine.

Offsite backups + a tested restore

Auto-back up to a separate location so a dead server doesn't lose your data. Not just "it's running" — actually try a restore once.

Separate keys, least privilege, non-root

A distinct SSH key per host (one leak doesn't expose every server). Run the server non-root to shrink the reachable surface.

Run dependency CVE monitoring yourself

With no Dependabot, run osv-scanner or pnpm audit continuously in CI/cron (→ not falling behind on CVEs).

4. Which should you choose?

Self-host isn't "pro" and GitHub isn't "amateur." Decide on whether you can keep operating it.

Self-host fits (if you meet the bar)

you want to remove the public-exposure surface itself
you can keep patching and backing up the server
you don't want code held by a third party / you want to limit the scope of impact
you can adopt the secret hook and dependency monitoring as a bundle

GitHub can be safer

no capacity to keep patching/backing up → a neglected self-host is the most dangerous
you want to lean on push protection / Dependabot auto-defense
you can't provide availability / redundant backups yourself
you can rigorously manage private repos (exposure is preventable by discipline)

In short, self-hosting means taking on the work GitHub was doing for you. Take it on and do it, and you remove a large incident class. Take it on and neglect it, and you can end up worse than GitHub: an unpatched server, a mis-committed secret, and a backup you can't restore. And supply-chain poisoning (like the xz-utils backdoor) is defended by continuous dependency monitoring wherever your code lives.

What this site does itself

This site runs a self-hosted Git server (plain bare git + SSH) and wires it so that every push is also copied to a backup on a separate server. Secrets (keys, passwords, connection strings) never go into git or docs, and dependency CVE monitoring runs via pnpm audit before every deploy and daily. "Not using GitHub" is not the goal — removing the accidental-exposure class while doing yourself all the work GitHub used to do is. Only doing both makes self-hosting safe.

FAQ

QIs a self-hosted Git server more secure than GitHub?

Not inherently. Self-hosting structurally removes the 'accidental public exposure' class, but the responsibilities GitHub handled for you — server patching, backups, pre-commit secret detection — move onto you. It's a good call if you keep doing that work, and worse than GitHub if you neglect it.

QWhat scares people away from GitHub?

Mostly two incidents: a repo that was meant to be private but was set public, and an API key committed to a public repo and exploited within minutes. Public repos are continuously crawled by automated scanning bots, so a leaked secret turns into real damage immediately. Self-hosting removes that public surface entirely.

QIf I self-host, what's the minimum I must do?

1) a pre-commit hook that detects secrets (gitleaks, etc.), 2) patch and minimize the Git server and OS, 3) offsite backups with a tested restore, 4) separate keys, non-root, least privilege, 5) run dependency CVE monitoring yourself (osv-scanner / pnpm audit). Only then is 'safer than GitHub' true.