Fossil SCM: Self-Hosted All-in-One DVCS with Built-in Wiki, Bug Tracker & Forum

Most version control workflows require assembling a stack of separate tools: Git for source control, a wiki for documentation, an issue tracker for bug management, and a forum for team discussions. Each tool has its own database, authentication system, and backup procedure. Fossil SCM takes a radically different approach: it bundles a distributed version control system, wiki, bug tracker, technotes system, forum, and web interface into a single self-contained binary with a single SQLite database.

For teams comparing Git-based forges, our Gitea vs Forgejo vs GitLab CE comparison covers the traditional Git forge landscape. For a look at Git-powered code sharing, see our OpenGist vs Pastefy vs PrivateBin guide. And for those interested in version-controlled databases, our Dolt vs TerminusDB vs CouchDB comparison explores a related concept.

What Is Fossil SCM?

Fossil SCM (Self-Contained Management) is a distributed version control system created by D. Richard Hipp, the same developer behind SQLite. First released in 2006, it was originally built to manage the SQLite and Tcl projects and has been in continuous development ever since.

Unlike Git, which focuses solely on version control and relies on external services (GitHub, GitLab, Gitea) for issue tracking, wikis, and code review, Fossil includes all of these features built in. Every Fossil repository is a single SQLite database file that contains:

• Version control: Full DVCS with branching, merging, and history
• Wiki: Built-in wiki with version history
• Bug tracker: Ticket system with customizable workflows
• Technotes: Timestamped technical notes (blog-like entries)
• Forum: Discussion boards with threaded conversations
• Web UI: Integrated HTTP server with a clean, responsive interface
• Access control: Fine-grained user permissions

Key Features

• Single binary: The entire Fossil system is one ~10 MB statically linked executable. No dependencies, no package managers, no complex installation.
• Single database: Everything — source code, wiki pages, tickets, forum posts — lives in one SQLite database file. Backup is as simple as copying one file.
• Built-in web server: Fossil includes an HTTP server that serves the web UI, so you do not need Nginx, Apache, or any other web server.
• Self-hosting: Designed from the ground up to be self-hosted. No cloud dependency.
• Git interoperability: Fossil can clone from and push to Git repositories, making migration and interoperability straightforward.
• Offline-first: As a DVCS, all operations work offline. Sync with other repositories when you reconnect.
• Automatic conflict detection: Fossil detects and prevents certain types of merge conflicts that Git handles silently.
• ** skins and themes**: Customize the web UI appearance with built-in themes or custom CSS.
• RSS feeds: Every component (commits, wiki changes, tickets, forum posts) has an RSS feed.
• Extensible ticket system: Define custom ticket workflows with configurable fields, states, and transitions.

Why Fossil Instead of Git + Separate Tools?

The primary advantage of Fossil is operational simplicity. Consider what it takes to run a Git-based project management stack:

For a solo developer or a small team, Fossil eliminates the overhead of managing 5–6 separate services. You install one binary, create one repository file, and everything works.

Docker Compose Deployment

Fossil is not typically distributed as a Docker image on Docker Hub, but community images are available. Here is a complete docker-compose.yml using a community-maintained image:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

services:
  fossil:
    image: duvel/fossil:latest
    container_name: fossil-scm
    restart: unless-stopped
    ports:
      - "8080:8080"
    volumes:
      - ./repos:/repos
    environment:
      - TZ=UTC
    command: >
      sh -c "
        fossil init /repos/myproject.fossil --admin-user admin --admin-password admin &&
        fossil server /repos/myproject.fossil --port 8080 --scgi
      "

Alternatively, run Fossil directly without Docker:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Download the static binary
wget https://www.fossil-scm.org/home/uv/fossil-linux-x64
chmod +x fossil-linux-x64
sudo mv fossil-linux-x64 /usr/local/bin/fossil

# Create a new repository
mkdir ~/fossil-repos
cd ~/fossil-repos
fossil init myproject.fossil

# Start the web server
fossil server myproject.fossil --port 8080 --localhost

The web UI is now available at http://localhost:8080. Log in with the admin credentials you set during initialization.

Using the keyopt/fossil-scm Image

Another popular community image is keyopt/fossil-scm, which supports multiple architectures:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

services:
  fossil:
    image: keyopt/fossil-scm:latest
    container_name: fossil
    restart: unless-stopped
    ports:
      - "8080:8080"
    volumes:
      - ./repos:/repos
      - ./data:/data
    command: fossil server /repos/myproject.fossil --port 8080

Running Fossil Behind a Reverse Proxy

For production use, run Fossil behind a reverse proxy for TLS termination:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

services:
  fossil:
    image: duvel/fossil:latest
    container_name: fossil-scm
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080"
    volumes:
      - ./repos:/repos
    command: fossil server /repos/myproject.fossil --port 8080 --localhost

Then configure Nginx or Caddy to proxy requests to 127.0.0.1:8080. For reverse proxy setup guides, see our mutual TLS with Nginx, Caddy, and Traefik guide.

Fossil vs Git: Architectural Differences

Fossil and Git are both distributed version control systems, but they differ fundamentally in architecture and philosophy.

When Fossil Shines

Fossil excels in scenarios where:

• Simplicity matters most: You want one tool, one binary, one database file. No Docker, no PostgreSQL, no Redis.
• You are a solo developer or small team: The integrated wiki, bug tracker, and forum eliminate the need for separate services.
• You value self-containment: A Fossil repository file is completely self-contained. Copy it to a USB drive and you have your entire project — code, docs, issues, and discussion history.
• You want immutability: Fossil does not support history rewriting. Once a commit is made, it is permanent. This is ideal for projects where auditability matters.
• You need offline access: As a DVCS, all operations work without network connectivity.

When Git Is Still Better

Git remains the better choice when:

• Ecosystem matters: You need GitHub Actions, GitLab CI, or the thousands of Git-based tools and integrations.
• Large teams or enterprises: Git’s branching model, pull request workflow, and code review tools are more mature for large-scale collaboration.
• Industry standard: Your team already knows Git, and hiring developers who know Git is easier than finding Fossil users.
• Multi-repo projects: If your project spans multiple repositories, Git’s submodule and monorepo tooling is more established.

Git Interoperability

Fossil can interoperate with Git repositories, making it possible to use Fossil locally while syncing with a Git remote:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# Clone a Git repository into Fossil
fossil clone https://github.com/example/repo.fossil repo.fossil
cd repo
fossil open repo.fossil
fossil git-export /tmp/git-repo

# Or import from Git
git clone https://github.com/example/repo.git
cd repo
fossil import --git ../repo.fossil

This makes migration from Git to Fossil (or vice versa) feasible without losing history.

Backup and Migration

Backing up a Fossil repository is trivial — it is a single SQLite database file:

1
2
3
4
5

# Simple file copy
cp myproject.fossil /backup/myproject-$(date +%Y%m%d).fossil

# Or use Fossil's built-in backup
fossil backup myproject.fossil /backup/myproject-backup.fossil

To migrate to a new server, simply copy the .fossil file and start the server. There are no database migrations, no configuration files to sync, and no dependencies to install.

When Should You Use Fossil SCM?

Ideal Use Cases

• Solo developers who want a complete project management system without managing multiple services
• Small teams (2–10 people) who value simplicity over ecosystem breadth
• Embedded / IoT projects where resources are limited and a single binary is preferred
• Long-term archival projects where immutability and self-containment are important
• SQLite and Tcl projects — Fossil was built for these and they continue to use it

Less Ideal Use Cases

• Large open-source projects that rely on GitHub’s network effects (contributors, issue templates, Actions)
• Enterprise environments that require SSO, LDAP integration, and enterprise support contracts
• Projects using monorepo tooling that is tightly coupled to Git (Bazel, Turborepo, Nx)
• Teams already invested in Git with established CI/CD pipelines and code review workflows

FAQ

Is Fossil SCM actively maintained?

Yes. Fossil has been in continuous development since 2006 and is actively maintained by the SQLite development team. New releases come out regularly with bug fixes, feature additions, and security updates. The project is hosted at fossil-scm.org.

Can I use Fossil with GitHub or GitLab?

Fossil can interoperate with Git repositories through its fossil git-export and fossil import --git commands. However, Fossil does not natively push to GitHub or GitLab — you need to export to a Git repository first. The interoperability works well for occasional sync but is not a replacement for native Git hosting.

Does Fossil support pull requests?

Fossil uses a different collaboration model. Instead of pull requests, Fossil uses a shared repository model where contributors push to a central repository. However, Fossil’s web UI supports a review workflow where changes can be discussed before being accepted.

How does Fossil handle large binary files?

Fossil stores all content in its SQLite database, including binary files. For very large binaries, this can make the database file grow significantly. Fossil has a configurable size limit for individual files. If you need to manage large binaries, consider using an external file store and referencing files from the repository.

Is Fossil suitable for production use?

Yes. Fossil has been used in production for the SQLite project itself since 2006 — a project with millions of users worldwide. The SQLite source code, documentation, bug reports, and developer discussions all live in a single Fossil repository.

How does Fossil compare to Mercurial?

Both Fossil and Mercurial are DVCS alternatives to Git. Mercurial focuses on being a better Git (cleaner commands, better UX) but still requires external tools for wikis and issue tracking. Fossil goes further by bundling everything into one system. Mercurial has a larger ecosystem but is no longer actively developed by its original creators.

Can I host multiple Fossil repositories on one server?

Yes. Run multiple fossil server processes on different ports, or use a reverse proxy (Nginx, Caddy) to route different URL paths to different Fossil repository files. For example: https://example.com/project-a and https://example.com/project-b can serve two separate Fossil repositories.