cloudparts

Fossil

A distributed version control system from the author of SQLite that keeps a whole project (code, tickets, wiki, forum and chat) in one SQLite database file, served by one small executable with its own web interface.

What it is
Version control
Used for
Issue tracking
Type
Open source
Made by
The Fossil project (D. Richard Hipp)
License
BSD 2-Clause
Facts checked
20 October 2026
Website Source code

What it is

Fossil is a single self-contained C program. Underneath, its history is the same kind of structure as Git’s: a graph of check-ins, each named by a cryptographic hash of its contents and pointing to its parents’ hashes. The difference is where that lives. A Fossil repository is one SQLite database file, normally kept outside your working directory, with ACID transactions and SQL queries over the history. Finding the descendants of a check-in, which Git can only do by walking the log, is a simple query. You can open the same repository file in any number of directories, for example one per branch, and switching branches becomes a cd.

The same file also holds a bug tracker, wiki, forum, chat, technotes and embedded documentation, behind a built-in web interface with role-based access control. fossil ui browses it locally and fossil server, or a two-line CGI script, publishes it; cloning a repository gets you the whole project site, not just the code. The project says most projects can be hosted on a $5-a-month VPS or a Raspberry Pi, and its stock container image is under 11 MB.

Its defaults reflect the small, close-knit SQLite team it was built for. Autosync pushes each commit to the parent repository immediately, unless you turn it off to work offline. There is deliberately no rebase command: Fossil records what actually happened, and only lets you remove content by shunning, which doesn’t propagate between clones automatically. It moved from SHA-1 to SHA3-256 names after the 2017 SHAttered attack, without breaking old repositories. D. Richard Hipp started it in 2007 and is still its top committer. It is licensed under the BSD 2-Clause license, and the latest release is 2.28 (March 11, 2026).

Why teams pick it

  • One executable to install and one file per project: copying the .fossil file moves the code, tickets, wiki and forum together
  • Self-hosting is cheap and quick: a built-in web UI, fossil server or a two-line CGI script, on hardware as small as a Raspberry Pi
  • SQL over the history makes questions such as “what came after this check-in” or “every edit to this file” simple queries
  • Converts both ways with Git: fossil import reads Git fast-export streams, and fossil git export keeps a Git mirror updated

Watch out for

  • No rebase, squash or other history rewriting, by design; a mistaken commit stays in the history
  • Built for a small, trusted team: autosync and seeing everyone’s branches suit SQLite’s “cathedral” style more than large open projects that work in many private forks
  • Git is the norm elsewhere, 94% of respondents in Stack Overflow’s 2022 survey, so Fossil and SQLite themselves keep Git mirrors on GitHub, an export the docs say comes with limitations
  • The repository file also stores password hashes and email addresses, so run fossil scrub before handing a copy to someone else

Alternatives

What all version control have in common →Compare side by side →
GitOpen sourceThe distributed version control system almost everyone uses: every clone holds the full history, stored as objects named by the hash of their content.+1 Git LFSMercurialOpen sourceA distributed version control system from the same month as Git, written mostly in Python, with a smaller command set, append-only storage and “phases” that stop you rewriting history others already have.JujutsuExperimentalOpen sourceA Git-compatible version control system, run as jj, where the working copy is itself a commit, every operation can be undone, and conflicts are stored in commits instead of stopping you.SaplingOpen sourceMeta’s source control system, grown out of Mercurial: an open-source sl client that works with Git repositories and makes stacks of commits and undo easy, plus a server and virtual filesystem that scale it to Meta’s monorepo.PijulBetaOpen sourceA distributed version control system that stores changes instead of snapshots, built on a mathematical theory of patches: independent changes apply in any order with the same result, and a conflict, once resolved, stays resolved.

How it fits with other technologies

A repository is one SQLite file · bash

fossil init project.fossil          # code, tickets, wiki and forum, all in this file
mkdir project && cd project
fossil open ../project.fossil       # a check-out; open the same file in other directories too
fossil add hello.c
fossil commit -m 'First check-in'   # with autosync on, this also syncs to the parent repository
fossil timeline
fossil ui                           # browse the whole project site locally

fossil sql --readonly               # query the history directly
# sqlite> SELECT type, count(*) FROM event GROUP BY type;   -- ci check-ins, t tickets, w wiki, f forum

See it in a real stack

No architecture uses Fossil yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2007–2026

SQLite started out in CVS around 2000. CVS had no good view of project history and no bug tracking, so from 2002 D. Richard Hipp wrote CVSTrac, a wrapper that added a wiki, tickets and a better view of the history, and went on to inspire Trac. Around the same time Monotone appeared: one of the first distributed systems, it named artifacts by their SHA-1 hash and stored its data in SQLite, which brought it to Hipp’s attention.

By about 2005 SQLite needed something better. Hipp considered Monotone, Git and Mercurial, but none of them could sync over plain HTTP, run from a cheap shell account on a leased server, or offer anything like CVSTrac’s wiki and tickets. So he wrote his own, first prototyping in Tcl and then moving to C for delta compression and diffs. Fossil hosted itself from July 16, 2007, took over the SQLite documentation in November 2007, and the SQLite source code itself on August 11, 2009. SQLite still uses it, and explains why in “Why SQLite Does Not Use Git”.

Fossil kept adding the pieces a project site needs: a discussion forum in 2.7 (2018), a Git mirror exporter in 2.9 (2019) and chat in 2.14 (2021). When the SHAttered attack showed in early 2017 that SHA-1 collisions were practical, Fossil 2.0 arrived about two weeks later with a hardened SHA-1 and the ability to read SHA3-256 names, and 2.10 made SHA3-256 the default in October 2019.

Why it’s built this way

Store the repository in SQLite
Monotone had shown hash-named artifacts in an SQLite database. A real database gives ACID transactions and lets history be queried with SQL, so reports such as descendants of a check-in or the full history of one file are short queries rather than procedural code.
Bundle wiki, tickets and the web UI
CVSTrac had shown how much a timeline, wiki and tickets improved a project, and none of the existing DVCSs offered them. Keeping them in the repository means they sync, back up and move with the code, and can link to each other by artifact hash.
Plain HTTP and a single binary
In 2005 none of the candidates synced over ordinary HTTP or ran from an inexpensive shell account. Fossil uses HTTPS (or SSH) through firewalls and proxies, and runs as one executable or a CGI script.
No rebase, and autosync on by default
Hipp considers rebase an anti-pattern that rewrites history. SQLite’s cathedral-style team wants everyone’s work visible and synced continuously, not developers going dark and returning weeks later with a mass of changes.

Timeline

  1. 2007

    Fossil hosts itself (July 16); SQLite’s documentation moves to it (November 12)

  2. 2009

    The SQLite source code moves to Fossil (August 11)

  3. 2017

    Fossil 2.0 (March 3): hardened SHA-1 and support for reading SHA3-256 names, after SHAttered

  4. 2018

    Fossil 2.7 adds the discussion forum (September 22)

  5. 2019

    2.9 adds fossil git export (July 13); 2.10 makes SHA3-256 the default (October 4)

  6. 2021

    Fossil 2.14 adds chat (January 20)

  7. 2026

    Fossil 2.28 released March 11

Sources12 · facts checked 20 October 2026

Improve this page on GitHub