Fossil does not require a central server, but a server can be very useful.
This article is a quick-reference guide for setting up your own Fossil server, with links to more detailed instructions specific to particular systems, should you want extra help.
There are basically four ways to set up a Fossil server:
All of these methods can serve either a single repository or a directory hierarchy containing many repositories with names ending in ".fossil".
You are not restricted to using a single method. The same Fossil repository can be served using two or more of the above techniques at the same time. You can also migrate from one method to another to accommodate changes in hosting providers or administrator preferences.
The idea behind the socket listener approach is that each incoming HTTP request is relayed to a new instance of the fossil http command. That command reads the HTTP request from its standard input, handles the request, and writes a complete and correct HTTP reply on standard output which is then returned to the client.
A stand-alone server uses the fossil server command to run a process that listens for incoming HTTP requests on a socket and then dispatches a copy of itself to deal with each incoming request. A stand-alone server can talk directly with the client, or the system can be configured with a reverse proxy in between the client and Fossil.
Fossil can also be run using CGI from ordinary web servers such as Apache, IIS, lighttpd, or althttpd. The Fossil server administrator places a short CGI script in the web server's document hierarchy, and when a client requests the appropriate URL, that script runs Fossil to generate the responce. CGI is a good choice for merging Fossil into an existing web site. The Fossil self-hosting repositories are implemented with CGI underneath althttpd.
For web servers such as nginx that do not support CGI, Fossil supports SCGI, a protocol that gives most of the simplicity of CGI with the efficiency of the stand-alone server option. With nginx, you use the fossil server --scgi command.
We've broken the configuration for each method out into a series of sub-articles. Some of these are generic, while others depend on particular operating systems or front-end software:
| Fossil Front-End Program | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Host OS | none | inetd | xinetd | stunnel | CGI | SCGI | althttpd | nginx | Apache | IIS | OS service |
| Any | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| Debian/Ubuntu | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ |
| Windows | ❌ | ❌ | ❌ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ |
Where there is a check mark in the "Any" row, the method for that is generic enough that it works across OSes that Fossil is known to work on. The check marks below that usually just link to this generic documentation.
There are several widely-deployed socket listener schemes besides the inetd, xinetd, and stunnel schemes with documents linked above: Apple’s launchd, Linux’s systemd, Solaris’ SMF, etc. We would welcome contributions to cover these as well. We also welcome contributions to fill gaps () in the table above.