Keep a live replica of every repository
An archive is a file you restore from. A replica is a repository your team can clone and push to right now. Most teams want both.
Replica or archive?
Both protect a repository. They answer different questions the moment something goes wrong.
A replica is usable today
A real repository on a second host — clone it, point CI at it, keep working. Nothing needs to be unzipped or restored first.
An archive is a point in time
A compressed snapshot in storage you own, with retention rules you set. See what's inside an archive →
A replica answers "can we keep working?" An archive answers "can we get last Tuesday back?" Most teams want both.
The whole repository, not the default branch
Mirror semantics apply to the whole ref namespace, not the branch someone remembered to select.
The same git clone --mirror behavior applies whether the destination is another provider or a plain server you run yourself.
Every ref
Branches, tags, notes, and the full commit graph replicate — full git clone --mirror semantics, not a single-branch copy.
Force and non-force modes
Mirror exactly, including deletions, or only add refs and never remove them — set per account, depending on how much control you want to hand the sync.
Git LFS: pointers, not objects
LFS pointer files replicate with the rest of the repository. The LFS object content itself does not — plan to replicate large-file storage separately if you rely on it.
Bidirectional sync
Some teams commit to two providers at once, or want a backstop while migrating between them.
A binding only ever pushes in one direction. Two-way sync is two bindings, not a special mode.
A binding in each direction
Create a binding from A to B and another from B to A. Commits landing on either side are mirrored to the other, on the same push-triggered or scheduled basis as any other binding.
A repository is never mirrored onto itself
A binding whose source and destination are the same provider, host, and path is refused outright — so a webhook can never loop a repository back into itself.
What you actually do when the primary host is down
None of this requires Git Replica to be involved once you're pointed at the replica — it's an ordinary repository.
Point remotes at the replica
git remote set-url origin pointed at the replica's URL — the history is identical, so nothing about your local clone needs to change.
Keep working
Push, review, and build against the replica like any other remote. CI can point at it as easily as the original.
Re-sync when the primary returns
Reverse the binding direction, or let the next scheduled or push-triggered sync catch the primary back up once it's reachable again.
Decide if you're switching for good
Nothing about the replica is Git Replica-specific — it's an ordinary Git repository. Stay there for good, or move back once the primary is verified healthy.
Nothing here depends on Git Replica being reachable — that's the point of keeping a replica.
Self-hosted and custom destinations
The destination doesn't have to be another GitHub account. It just has to speak Git.
Any Git server over HTTPS or SSH
Self-hosted GitLab, Gitea, or a bare server you control — connect with a token or an SSH key, the same as any other generic remote.
The destination repository must exist first on custom servers
Git Replica creates missing repositories automatically on providers that support it. On a plain Git server it can't — create the destination repository before the first sync.
Anywhere a plain git push can reach counts as a valid destination.
Replication questions
Straight answers on how replication actually behaves.
What's the difference between replication and backup?
Replication keeps a live, clonable repository on a second host — useful the moment you need to keep working. Backup usually means an archived snapshot in storage you own — useful when you need to go back to a specific point in time. Git Replica supports both, and most teams run one binding of each type.
Does replication copy branches and tags?
Yes. A replication binding uses full git clone --mirror semantics: every branch, tag, note, and the complete commit graph — not just the default branch. Git LFS pointer files replicate too, though the underlying LFS object content does not.
Can I sync two repositories in both directions?
Yes. Create a binding in each direction and commits landing on either side mirror to the other. Git Replica refuses to create a binding where the source and destination are the same repository, so a webhook can never loop a repository back into itself.
Can I replicate to a self-hosted Git server?
Yes, over HTTPS or SSH with a token or SSH key. The destination repository has to already exist on a plain Git server, since Git Replica can only auto-create repositories on providers whose API supports it.
Keep reading
Git repository mirroring
Mirror between GitHub, GitLab, Bitbucket and self-hosted, in any direction.
Real-time Git backup
Webhook-triggered backups that are current the moment you push.
Git disaster recovery
Outage, lockout, force-push, deletion — and the recovery path for each.
git push --mirror explained
What it copies, force-updates and deletes — and how to verify before running it.
Mirror GitHub to GitLab
Keep an automatic GitLab copy for redundancy, migration readiness, and failover.
GitLab mirroring & backup
Mirror GitLab repositories to GitHub, Bitbucket, self-hosted Git, or cloud storage.
Give every repository a second home.
Set up real-time replication in under two minutes. Free for open source and private non-commercial use.
Get started free