A self-hosted code forge where Git and Jujutsu users work on equal terms

Slath is a secure, lightweight forge you run yourself. A small installation needs only Slath, PostgreSQL, Git, and OpenSSH. It's free software under the AGPL.

Early development. Slath isn't usable yet. Configuration, storage layout, and interfaces will change without notice. This page describes what works today and what's planned.

Follow development on GitHub See the roadmap

For self-hosters

Small enough to run on one machine

Slath is a single Rust binary. It doesn't need Kubernetes, Redis, a hosted account, or anything on the internet once it's installed.

Four parts, all of them familiar
Slath, PostgreSQL, system Git, and the OpenSSH server you already run. Background jobs use a queue in PostgreSQL. Repositories and uploads live on the local filesystem.
Security boundaries you can check
Git runs only through a hardened process runner with a scrubbed environment. SSH helpers never see database credentials. Hooks that can't reach the server reject the push instead of letting it through. CI jobs run on separate runner hosts, never on the forge.
Self-contained and air-gap friendly
Every font, icon, and script is served by your instance. No CDNs, remote fonts, analytics, or avatar services.
Upgrades in one command (planned)
Upgrades from any earlier release are planned as a single command, with preflight checks, an automatic backup, and a tested way back.

SSH access goes through your sshd: /etc/ssh/sshd_config.d/slath.conf

Match User git
    AuthorizedKeysFile none
    AuthorizedKeysCommand /usr/bin/slath ssh-keys --socket /run/slath/slath.sock %f
    AuthorizedKeysCommandUser slath
    PasswordAuthentication no
    PermitTTY no
    AllowTcpForwarding no
    AllowAgentForwarding no
    X11Forwarding no
    AcceptEnv GIT_PROTOCOL

What a small installation needs

# the forge
slath serve
# and three things you probably already have
postgresql   # 15 or newer
git
openssh

For Git and Jujutsu users

Review changes, not just branches

Plain Git clients clone, fetch, and push over HTTPS and SSH with the standard protocols. Jujutsu is first-class too: Slath follows a change across rewrites, so reviews survive rebases and amends.

A change keeps its identity however often you rewrite it. Slath reads that identity from either of two places:

the change-id header that jj writes into Git commits, or
a Change-Id: trailer in the commit message, for Git users and existing Gerrit-style tooling.

On top of that, merge requests will show each revision of a change, interdiffs between revisions, and stacks of dependent changes that can be reviewed one by one and landed partially, from the web or by pushing.

Merge requests and stacks are planned. Today Slath serves Git over smart HTTP (protocol v0 and v2) and over SSH, and its test suite runs jj git clone and jj git push over both for every supported jj version.

The same change, written by jj

$ git cat-file commit HEAD
tree 9c1d…
parent 4e07…
author Ada <ada@example.org> 1793520000 +0100
committer Ada <ada@example.org> 1793520000 +0100
change-id wnzqrpvsoxtlmuqyvvklwkqrnzosklpt

Retry webhook delivery with backoff

…and by Git with a trailer

Retry webhook delivery with backoff

Change-Id: I8f3c2a7d5e9b14c06a2f8e1d3b7c9a5e4f2d1c0b

Federation

ForgeFed: after 1.0, on solid ground

Slath 1.0 won't federate. We'd rather say that plainly than promise a half-working protocol.

ForgeFed lets issues, merge requests, and follows cross instance boundaries. Experiments with it are on the roadmap for the 2.x series. Interoperability with the AT Protocol and Tangled is a research topic, not a commitment.

Until then, Slath builds what federation depends on:

Stable change identity that doesn't break when a commit is rewritten, so a change can be referred to from elsewhere.
A complete REST API and webhooks, so other systems can follow what happens on an instance.
Full data export, so nothing you put into an instance is locked in.

If you work on ForgeFed, run a federated forge, or have opinions on how jj change identity should travel between instances, we'd like to hear from you early, while the data model is still open.

Start a conversation in the issue tracker

Roadmap

Releases have no dates. Each one ships when its acceptance tests pass, and those tests cover security, accessibility, and upgrades alongside features.

Planned releases up to 1.0
Version	Theme	Status
foundation	Workspace, hardened Git runner, job queue, Git over HTTPS and SSH, jj compatibility tests	In progress
0.1	Self-hosted Git: accounts, tokens, SSH keys, organizations, repositories, code browser, API, backup and restore	Planned
0.2	Team alpha: OIDC, TOTP, passkeys, teams, branch protection, issues, notifications, search, import, robust upgrades	Planned
0.3	Merge requests and forks: revisions, interdiffs, batched reviews, suggestions, statuses, webhooks, bot accounts	Planned
0.4	Stacks: per-change review, stack view, partial landing, landing by push, conflicts	Planned
0.5	CI with GitHub Actions-style workflows on separate runners, with approval for external contributions	Planned
0.9	Release candidate: data export, performance, external security review, signed releases	Planned
1.0	Stable interfaces	Planned

Not in 1.0: federation, a package registry, Git LFS, wikis, code search, and Kubernetes-native high availability. Some of these are planned for later releases.

Free software

Built in the open

The server is licensed under the GNU AGPL v3.0 or later. Hosting repositories on Slath doesn't affect their licenses. Contributions are welcome with a DCO sign-off.

Source code Changelog Development setup