<title>Benefits of a Fossil Server</title>

<h2>No Server Required</h2>

Fossil does not require a central server.
Data sharing and synchronization can be entirely peer-to-peer.
Fossil uses 
[https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type|conflict-free replicated data types]
to ensure that (in the limit) all participating peers see the same content.

<h2>But, a Server Can Be Useful</h2>

Fossil does not require a server, but a server can be very useful.
Here are a few reasons to set up a Fossil server for your project:

  1.  <b>A server works as a complete project website.</b><p>
      Fossil does more than just version control.  It also supports
      [../tickets.wiki|trouble-tickets], 
      [../wikitheory.wiki|wiki], 
      a [../chat.md|developer chat room], and a [../forum.wiki|forum].
      The [../embeddeddoc.wiki|embedded documentation]
      feature provides  a great mechanism for providing project documentation.
      The [../unvers.wiki|unversioned files] feature is a convenient way
      to host builds and downloads on the project website.

  2.  <b>A server gives developers a common point of rendezvous for
      syncing their work.</b><p>
      It is possible for developers to synchronize peer-to-peer but
      that requires the developers coordinate the sync, which in turn
      requires that the developers both want to sync at the same moment.
      A server alleviates this time dependency by allowing each developer
      to sync whenever it is convenient. For example, a developer may
      choose to automatically sync
      after each commit and before each update.  Developers all stay
      in sync with each other without having to interrupt each other
      constantly to set up a peer-to-peer sync.

  3.  <b>A server provides project leaders with up-to-date status.</b><p>
      Project coordinators and BDFLs can click on a link or two at the
      central Fossil server for a project and quickly tell what is
      going on.  They can do this from anywhere — even from their phones
      — without needing to actually sync to the device they are using.

  4.  <b>A server provides automatic off-site backups.</b><p>
      A Fossil server is an automatic remote backup for all the work
      going into a project. ([../backup.md | Within limits].)
      You can even set up multiple servers at
      multiple sites with automatic synchronization between them for
      added redundancy.  Such a setup means that no work is lost due
      to a single machine failure.

  5.  <b>A server consolidates [https://www.sqlite.org/howtocorrupt.html
      | SQLite corruption risk mitigation] to a single point.</b><p>
      The concerns in section 1 of that document assume you have direct
      access to the central DB files, which isn't the case when the
      server is remote and secure against tampering.<p>
      Section 2 is about file locking, which concerns disappear when Fossil's
      on the other side of an HTTP boundary and your server is set up
      properly.<p>
      Sections 3.1, 4 thru 6, and 8 apply to all Fossil configurations,
      but setting up a server lets you address the risks
      in a single place. Once a given commit is
      sync'd to the server, you can be reasonably sure any client-side
      corruption can be fixed with a fresh clone. Ultimately, this
      is an argument for off-machine backups, which returns us to reason
      #4 above.<p>
      Sections 3.2 and the entirety of section 7 are no concern with
      Fossil at all, since it's primarily written by the creator and
      primary maintainer of SQLite, so you can be certain Fossil doesn't
      actively pursue coding strategies known to risk database corruption.<p>

  6.  <b>A server allows [../caps/ | Fossil's RBAC system] to work.</b><p>
      The role-based access control (RBAC) system in Fossil only works
      when the remote system is on the other side of an HTTP barrier.
      ([../caps/#webonly | Details].) If you want its benefits, you need
      a Fossil server setup of some kind.
