Git Repository Backup: What to Do When GitHub Goes Down

When GitHub has a bad day, a surprising number of teams discover the same thing at the same time: their code lives in exactly one place, and everything that depends on it (deployments included) stops with it.

A support question we received this week put it neatly. A new customer asked whether deployments still work if GitHub is unavailable, and what their backup options are. It's a fair question, and the honest answer is that it depends on what you set up before the outage. This guide covers how to back up your Git repositories, which tools are worth looking at, and how to keep deploying when your primary host is unreachable.

Why a Git host isn't a backup

Git is distributed, so it's tempting to assume every clone is a backup. In practice that falls apart:

• Outages. Hosted Git platforms go down. GitHub publishes its incident history at githubstatus.com, and it's worth a skim to see how often degraded performance appears.
• Accidental deletion. A deleted repository, a force-push over main, or a mass branch cleanup can remove history that no developer has fully cloned.
• Account problems. A suspended account, a lost 2FA device or an offboarded admin can lock a team out of repositories they own.
• Compromise. A stolen token can delete or overwrite repositories. Ransomware-style attacks on developer accounts are a real scenario, not a theoretical one.
• Everything that isn't code. Issues, pull requests, wikis, releases and project boards live on the platform, not in your .git directory. A developer's clone has none of it.

The host protects its own infrastructure. Protecting your data is your side of the shared-responsibility line.

Decide what you're protecting against

The right setup depends on the failure you care about most:

Two terms are worth having handy. RPO (recovery point objective) is how much recent work you can afford to lose: a backup that runs nightly has an RPO of up to 24 hours. RTO (recovery time objective) is how long you can afford to be without the repository. A hobby project can live with a day of each; a team shipping to production several times a day usually can't.

Option 1: a free mirror with plain Git

GitHub's own documentation describes the baseline approach: back up a repository with a mirror clone. A mirror clone copies every branch, tag and ref, not just the default branch.

git clone --mirror git@github.com:your-org/your-app.git
cd your-app.git

# If the repository uses Git LFS, fetch the large files too
git lfs fetch --all

Keep it current with a scheduled job. This one refreshes the mirror hourly:

# crontab -e
0 * * * * cd /srv/git-backups/your-app.git && git remote update --prune >> /var/log/git-backup.log 2>&1

To make the backup useful during an outage, add a second remote on a different host (a self-hosted Gitea or Forgejo instance, GitLab, Bitbucket, or a plain SSH server) and push to it after each refresh:

git remote add backup git@git.example.com:your-org/your-app.git
git push --mirror backup

One gotcha: a mirror clone of a GitHub repository includes GitHub's internal refs/pull/* refs, and many hosts reject them. If the push fails with a hidden ref style error, push only branches and tags instead:

git push backup --prune 'refs/heads/*:refs/heads/*' 'refs/tags/*:refs/tags/*'

What this gives you: every commit, branch and tag, for free, on infrastructure you control.

What it doesn't: issues, pull requests, wikis, release notes, or any restore automation. GitHub's docs point to migration archives for selected metadata, and to third-party tools for the rest. Also remember that Actions secrets are write-only once stored, so they can't be exported. Keep the source of truth in a password or secrets manager.

The step people skip: test the restore. A backup you've never restored is a hope, not a backup.

git clone /srv/git-backups/your-app.git /tmp/restore-test
git -C /tmp/restore-test log --oneline -5
git -C /srv/git-backups/your-app.git fsck

If you already run scheduled backups for your servers and databases, the same cron-and-offsite pattern applies. We walk through it in automating server backups to Amazon S3.

Option 2: managed Git backup tools

Once you have more than a handful of repositories, need issues and pull requests included, or have to show an auditor that backups run and restore, a managed tool earns its cost. These are the ones we'd look at, with facts taken from each vendor's own pages as of November 2026:

Disclosure: we use GitProtect to back up our own repositories and pay for it ourselves. There's no partnership or sponsorship behind its place in this list.

How to choose between them, in order of importance:

1. Where does the backup live? You want it in storage under separate credentials from your Git host. A backup in the same account as the thing it protects fails the lockout and compromise scenarios.
2. Does it include metadata? Code alone is the easy part. Issues, pull requests and wikis are what hurt to lose.
3. Have you restored from it? Run one real restore into a scratch organisation before you commit. Restore speed and fidelity vary more than backup features do.
4. Does pricing track your growth? Per-repository pricing is predictable for a stable set of repos and expensive for an agency with hundreds. Per-seat or per-member pricing is the reverse.

If you're moving between hosts rather than just protecting one, our comparison of GitHub alternatives covers GitLab, Bitbucket, Gitea, Forgejo and Codeberg, including migration and deploy triggers.

What happens to your deployments when the Git host is down?

Backing up the repository solves half the problem. The other half is that your deployment pipeline depends on the host too, in two separate ways:

• Triggers. Automatic deployments are push-based: your Git host sends DeployHQ a webhook when new commits land, and DeployHQ doesn't poll your repository. If the host is down, or just slow to send webhooks, nothing triggers. Without a webhook, DeployHQ only sees new commits when you start a deployment manually or fetch the latest revision.
• The deployment itself. DeployHQ keeps a cached copy of each connected repository, but every deployment begins by updating that copy from the remote, with an Updating repository from… step at the start of the log. That step has to reach your host, so the cached copy on its own won't let you deploy through a full Git outage.

That's why a mirror matters: it gives DeployHQ somewhere else to fetch from.

Not every incident is a full outage, either. GitHub's status page reports components separately, including Git Operations, Webhooks, API Requests and Actions. An Actions or Webhooks incident can leave a deployment you start manually working, while a Git Operations incident won't. Check which component is affected before you reach for the runbook.

A failover runbook for hotfix day

Set this up before you need it. Written down, it takes about ten minutes to run; improvised during an outage, it takes much longer.

Prepare (once):

1. Keep a mirror on a second host, using the steps above, refreshed on a schedule. Mirror every branch and tag. A mirror keeps the same commit hashes as the original, which is what lets DeployHQ work out what changed since your last deployment.
2. Give DeployHQ access to the mirror. For SSH, add the project's public key (on the project's Configuration page, directly below the repository URL) to the mirror host as a deploy key. For HTTPS, have a username and access token ready.
3. Decide how deployments get triggered. Each project has its own automatic-deployment webhook URL (on the Automatic Deployments page), so you can add that same URL to a mirror hosted on a supported service: Bitbucket, Codebase, GitHub, GitLab or Planio. On any other host, start deployments manually.

During an outage:

1. The mirror only has what was last synced, and it can't sync from a host that's down. Push the commit you need directly from a developer's clone:

   git remote add backup git@git.example.com:your-org/your-app.git
   git push backup main

1. In DeployHQ, open the project's Configuration page and click Change Repository. Tick Add your repository details manually?, enter the mirror's URL and credentials, then click Update Repository. DeployHQ recaches the repository from the new location and keeps your deployment history. Large repositories take longer, so wait for the recache to finish before deploying.
2. Check the branch. If the branch your servers deploy from doesn't exist on the mirror, DeployHQ can end up pointing at a different one, so confirm it before you deploy.
3. Start the deployment manually. If the last deployed commit isn't in the new repository, choose another start commit or Deploy the entire repository. With a true mirror, the commit is there.
4. If the release misbehaves, roll back in one click to the previous known-good deployment.

After the outage:

1. Use Change Repository again to point the project back at the primary.
2. Reconcile: anything pushed to the backup during the outage has to be merged back to the primary, or the two histories drift.
3. Confirm the primary's webhook is still in place and that the next push triggers a deployment.

If your primary is GitLab or Bitbucket rather than GitHub, the runbook is identical. DeployHQ connects to GitHub, GitLab and Bitbucket the same way, and to self-hosted Git such as Gitea, so a mirror on any of them works as a failover target. The step-by-step guide to changing a project's repository has the details for each host.

Want deployments that don't depend on a single CI runner or a single Git host's good day? Start a free trial and connect a repository in a few minutes.

Don't make CI a second single point of failure

If your deploy step lives inside your Git host's CI (a GitHub Actions workflow that SSHes to the server, say), an outage takes out the repository, the pipeline and the deploy at once. Separating the stages gives you somewhere to stand during an incident. Our post on how we deploy deployhq.com shows that split in practice, with CI building and testing and DeployHQ handling the deploy. DeployHQ's build pipelines can also run your tests and asset builds before anything ships, so your deploy path doesn't have to live inside one vendor's CI. For a wider look at the options, see GitHub Actions vs GitLab CI vs Bitbucket Pipelines and our roundup of software deployment tools.

How reliable is the deployment side?

Fair question, and one worth asking of any vendor, us included. Don't rely on a summary number; read the record. DeployHQ's status page lists current status and past incidents and maintenance windows, and you can subscribe to it by email, RSS, webhook or Slack. Whichever deployment tool you choose, ask to see its incident history, and then plan for the day it and your Git host are both having a bad time. A mirror and a written runbook cover most of that gap.

A minimum viable setup

If you do only four things after reading this:

1. Mirror every production repository to a second host or storage bucket on a schedule.
2. Keep the backup under different credentials from the primary account.
3. Restore once, for real, and write down how long it took.
4. Write the failover runbook and keep a copy somewhere that doesn't depend on the host being up.

Everything else (managed tools, compliance reporting, metadata backups) is worth adding as the cost of losing a repository grows.

Ready to turn the runbook into something you can run in ten minutes? See plans and pricing and connect a repository today.

Questions about setting up a failover project or connecting a backup remote? Email support@deployhq.com or reach us on X at @deployhq.