Real-Time Git Backup to Amazon S3

01 — Your bucket

The storage stays yours

GitReplica writes to storage you control. It never becomes the system of record for your archives.

Your account, your keys

You create the bucket and the access key. GitReplica writes objects into it and, if you ask it to, prunes old ones — it never owns the storage account itself.

Encrypted in transit and at rest

Your storage credentials are encrypted before they're stored, and the bucket's own encryption applies to the objects GitReplica writes into it.

Leave any time

The archives are plain zip files in your bucket — they keep working, and stay readable, if you stop using GitReplica tomorrow.

02 — Providers

S3-compatible storage that works

Anything that speaks the S3 API — connected the same way, with the same fields.

Amazon S3

The reference implementation of the API every other option here also speaks. The safe default if you're not already using one of the others.

Cloudflare R2

S3-compatible object storage from Cloudflare. Point GitReplica at your R2 bucket and an access key, the same way you would S3.

Backblaze B2

B2 exposes an S3-compatible endpoint alongside its native API — GitReplica talks to that endpoint with the same bucket, region and key fields as any option here.

Wasabi

A drop-in S3-compatible bucket. Use the region-specific endpoint Wasabi assigns your account and the rest of the setup is identical.

DigitalOcean Spaces

Spaces speaks the S3 API natively. Pick your Spaces region as the endpoint and the rest of the setup matches any other S3-compatible bucket.

Hetzner, OVH and Scaleway

Three more S3-compatible object storage services, each connected the same way: endpoint, bucket, access key.

Google Cloud Storage

GCS accepts S3-style requests when you authenticate with an HMAC key pair instead of a Google service account. Generate one and connect it like any other S3-compatible bucket.

Any custom S3-compatible endpoint

MinIO, a homelab NAS, or anything else that implements the S3 API. Supply the endpoint and credentials directly — no preset required.

03 — Setup

Four steps to your first archive

The same flow regardless of which S3-compatible provider you picked.

Create a bucket and an access key

Write access is enough — GitReplica doesn't need admin permissions on the bucket.

Add it as a destination

Endpoint, region, bucket, key — pick a preset and the endpoint template is filled in for you.

Bind your repositories

Choose the source account and the repositories that should be archived to this destination.

Your next push is archived

Or run a sync immediately if you don't want to wait for the next commit.

If your provider's endpoint URL already contains the bucket name — some R2 and DigitalOcean Spaces URLs do — leave it out of the endpoint field. The bucket is appended automatically, and including it twice puts every object under a doubled path. The connect form warns you when it spots this.

04 — In the bucket

What lands there

Predictable object keys, bounded growth, and an optional slice of your project data alongside the code.

backups/acme/api/api-2026-08-13T09-14-02Z.zip
backups/acme/api/api-2026-08-12T09-13-58Z.zip
backups/acme/web/web-2026-08-13T09-14-05Z.zip

One object per sync

Timestamped and never overwritten — every successful archive is a new object next to the last one.

Keep the last N

Older archives are pruned automatically once a retention count is set on the binding.

Metadata alongside the code

Optional per binding — issues, pull requests, reviews and release notes as JSON inside the same archive. See what's in an archive →

05 — Not on S3?

Azure Blob works the same way

Not every team standardizes on S3 — GitReplica doesn't assume you have.

Azure Blob Storage

Connect with an account key or a connection string. Same push-triggered archives, same retention, same object layout.

Or mirror to another Git host instead

An archive isn't the only option — a binding can also push a live, clonable replica to a second Git host. See repository mirroring →

FAQ

Git backup to S3 questions

How do I back up a Git repository to S3?

Create a bucket and an access key with write access, then add it to GitReplica as a storage destination — endpoint, region, bucket and key, with a preset available for the common providers. Create a binding from a source account to that destination and choose which repositories to archive. From there, pushes to a GitHub, GitLab or Bitbucket source archive automatically the moment they land; self-hosted and custom sources archive on a schedule or on demand instead.

Which S3-compatible providers are supported?

Amazon S3, Cloudflare R2, Backblaze B2, Wasabi, DigitalOcean Spaces, Hetzner, OVH, Scaleway, Google Cloud Storage via HMAC keys, and any other custom S3-compatible endpoint — anything that implements the S3 API works.

Are the archives encrypted?

Two layers. The storage credentials you give GitReplica — access key, secret, connection string — are encrypted at rest the same way OAuth tokens are, so they're never stored in plain text. The archive itself travels to your bucket over HTTPS, and once it lands, encryption at rest is whatever your bucket provides — S3 server-side encryption, Azure Storage encryption, or your provider's equivalent — since GitReplica doesn't retain a copy to encrypt separately.

How much storage will I need?

Roughly the size of a bare clone of the repository, per archive, multiplied by how many archives you retain. A repository that compresses to a few hundred megabytes as a bare mirror uses about that much per archive; keeping ten of them uses roughly ten times that. Set a keep-last-N retention count on the binding, or a lifecycle rule on the bucket, to bound total usage instead of letting archives accumulate indefinitely.

Related guides

Send your next push to your own bucket.

Add an S3 destination and create a binding — the first archive lands immediately. Free for open source and private non-commercial use.

Get started free

Real-time Git backups to Amazon S3