Fossil-Pages
(1) By netrunner (netizen001) on 2025-03-24 19:09:29 [link] [source]
Has anyone here attempted to host static websites via Fossil (or Chisel) Just like you would in case of Github-pages.
I was wondering for a while, because I have a desire to use Fossil as a drop-in replacement for Github-pages & the fact that Fossil is a Github-In-A-Box is a big plus.
So if anyone of you have done that, then can you lead to the repo or if not then at least some advice ??
(2) By Richard Hipp (drh) on 2025-03-24 19:21:46 in reply to 1 [link] [source]
I'm not sure what you mean by "static website". Are you aware that the the https://fossil-scm.org/home website (including all of the documentation and the Download page) is just a Fossil invoked via CGI. There are actually two Fossil repositories involved - one for the Fossil source code, including the documentation, and another for this Forum. So two CGIs. The CGI script that covers the source code, documentation, and the download page looks like the following, and the Forum CGI script is similar:
#!/usr/bin/fossil repository: /fossil/fossil.fossil errorlog: /logs/errors.txt
Is there something more beyond that you are looking for?
Other projects:
SQLite uses Fossil, but most of the http://sqlite.org/ website is static pages served by an ordinary web server. Probably not what you are looking for.
https://pikchr.org/ is entirely a single running Fossil instance. (Or, more precisely, a CGI that invokes Fossil whenever it is called.)
https://wapp.tcl.tk is entirely a single Fossil CGI.
https://sqlite.org/althttpd is the site devoted to the custom web-server that SQLite uses, and that site is entirely a single Fossil CGI.
(3.1) By Joel Dueck (joeld) on 2025-03-25 16:19:09 edited from 3.0 in reply to 1 [link] [source]
GitHub pages usually works by running your Markdown files through a static site generator (like Jekyll or Hugo) with some kind of CI workflow, to get the HTML files and other assets (the static site).
Fossil on the other hand will happily just serve up any Markdown files that are checked into the repo, without requiring the HTML generation step (or any CI at all). See Embedded Documentation.
I used to publish my personal website using a Fossil repo behind a 2-line CGI script — you can still see it running here: https://joeldueck.com/code/jdcom-old/
PS: Is a Fossil-served website “static” or “dynamic”? I would say “yes, probably” and also “how is that a useful distinction anymore”
(4) By Stephan Beal (stephan) on 2025-03-25 16:37:41 in reply to 3.1 [link] [source]
“how is that a useful distinction anymore”
My internal Devil's Advocate says..
It's still a distinction for folks running on shared hosters, where they might not have the ability to run native CGI binaries, or where they might be able to run them but not build them on that exact machine, which introduces the complication of building fully static binaries (something glibc can't do for some libraries, most notably networking libs).
(5) By matt w. (maphew) on 2025-04-02 20:45:21 in reply to 3.1 [link] [source]
I used to publish my personal website using a Fossil repo behind a 2-line CGI script — you can still see it running here: https://joeldueck.com/code/jdcom-old/
...just jumping in to say: thank you Joel for this aesthetically pleasing (mis)use of fossil as personal web site. And addtional thank you for keeping it alive as a showcase even though you've moved on to something else. It was a great help in some of my own similar efforts. (Also discontinued, but I'm happy for what I learned in the course of it.)
(6) By Warren Young (wyoung) on 2025-04-03 14:39:38 in reply to 3.1 [source]
Is a Fossil-served website “static” or “dynamic”?
If you have your front-end web server's caching set up properly, it's effectively static from the perspective of each client because the server-side generation is done only once after each page is changed, per-client.
The next step along the "simplest thing that could possibly work" axis would be to extend the cache
command to work with all URLs, not just "expensive" ones. This would allow Fossil to skip the Markdown processing when it sees it has a pre-rendered version of the page in its cache already and serve it directly.
After that, the next step would be to write a script looping over test-markdown-render
to produce actually-static-on-disk files which you could then stand up behind your static HTTP file server of choice. If nothing else, this permits optimizations like sendfile(2)
.