Host it yourself.
The source is yours.
Clone the repo, pick your backends, and run the binary. Apache 2.0 — read it, fork it, ship it.
Not ready to host? Try the demo forge ↗ — it already runs the server for you.
baleforgit-server is a single binary that puts everything touching storage, metadata, and authorization behind a pluggable backend. The same server runs on a laptop's filesystem with SQLite, or an S3 bucket with Postgres and your forge's own auth — and the source is all there to read.
# 1 · grab it — it's open source
$ git clone https://github.com/davidrios/baleforgit
# 2 · pick your backends (exact config in the README)
# storage → a local folder, or an S3 bucket
# metadata → a SQLite file, or a Postgres URL
# auth → static tokens, or your forge via one callback
# 3 · launch the single binary
$ baleforgit-server # listens for git-bale clients
# 4 · point a repo at it and push
$ git-bale install --local
$ git push # only new chunks travel
Exact flags & env live in the README ↗
// Pluggable by design
Storage, metadata, and auth are independent interfaces. Start on the simplest option for each, then promote any one of them as you grow — the server and the git-bale clients never notice.
Storage backend
Holds the content-addressed chunks. On-disk blobs for a single box; an S3-compatible bucket when you need durability and scale.
Metadata backend
Tracks files, chunks, and per-owner / per-repo accounting. SQLite to get started in seconds; Postgres for multi-tenant scale.
Auth backend
HS256 tokens with scope enforcement and per-repo read checks. Issue static tokens, or delegate the user model to your forge over a single callback.
// Access control
Every request carries an HS256 token whose scopes are checked server-side, with per-repo read enforcement on top. Stand it up with a handful of static tokens, or hand identity to your forge — a single callback maps a user to what they're allowed to touch, so the people already in your GitHub, GitLab, or Gitea keep exactly the access they have.
Tokens
Signed tokens carry scopes the server enforces on every call.
Per-repo
Access is verified at the repository boundary, not just the door.
Static
No external system required — perfect for a small team or a single box.
Delegated
One callback maps users and permissions to the forge you already run.
# every repo reports what it's actually using
logical 2.41 TB # what your files add up to
stored 188 GB # after chunk-level dedup
dedup 92.2%
quota 500 GB # soft — warn, don't wall off
// Quotas & accounting
The metadata backend keeps per-owner and per-repo accounting, so usage and dedup savings are a query away — not a mystery. Soft quotas let you set a ceiling that warns rather than walls off, and usage endpoints make it easy to surface the numbers in your own dashboards or your forge's UI.
// One server, two ends of the curve
Nothing about the on-disk format or the client changes as you scale — you just promote a backend at a time.
Everything on one machine. Up in minutes, one file to back up.
Durable object storage, a shared database, and identities from the forge you already run.
Clone the repo, pick your backends, and run the binary. Apache 2.0 — read it, fork it, ship it.
Not ready to host? Try the demo forge ↗ — it already runs the server for you.