Written by Rodrigo Arias Mello on 2025-11-30
I would like to move the Dillo project away from GitHub to a new home that is more friendly to use with Dillo and addresses some of its problems. This page summarizes the current situation with GitHub and why I decided to move away from it to a self-hosted server with multiple mirrors in another Forge.
background
Before we get into the details, I would like to briefly explain what happened to the old site. The original Dillo website was at dillo.org, with Dillo’s source code also in a Mercurial repository at hg.dillo.org. But it also included a mail server used to reach developers, a bug tracker, and an archive for the mailing list. However, in 2022 the domain was lost and someone else decided to buy it to put up a similar site, but punned with AI generated ads. The original developers are no longer active, but luckily I had a copy of the Mercurial repository and with some help I was able to recover a lot of the content from the original server (some parts are still missing today).
I want to avoid this situation as much as possible, so we can’t rely on any one site that could go down and the whole project could become useless. Initially, I uploaded the Dillo source and website to a Git repository on GitHub, but now I don’t think that’s a good idea.
Status with GitHub
GitHub has been useful for storing all the repositories of the Dillo project, as well as running CI workflows for platforms in which I don’t have a machine available (like Windows, Mac OS or some BSDs).
However, it has several problems that make Dillo less suitable for development now. The most annoying problem is that the frontend barely works without JavaScript, so we can’t open issues, make requests, log source code or CI in Dillo itself, despite them being mostly plain HTML, which I don’t think is acceptable. In the past, it would degrade decently without invoking JavaScript, but this no longer does. Additionally, the page is very short on resources, which I don’t think is necessary to render mostly static text.
Another big problem is that it is a single point of failure. I do not mean that GitHub is stored in the same machine, but that it is controlled by an entity that can unilaterally ban our repository or account and we will lose the ability to notify in that URL what happened. If we do not have a local copy of all the data it can lead to data loss.
In terms of usability, the platform has become more slow over time, which is affecting the development process. It also requires you to have a fast internet connection all the time, which is sometimes not the case for me. Additionally, GitHub seems to encourage a “push model” in which you are notified when there is a new event in your project, but I don’t want to work with that model. Instead, I like it to work as a “pull model”, so I get updates only when I specifically look for them. This model will allow me to work easily even offline. Unfortunately, I noticed that the same push model has been copied into an alternative forge.
On the social side, I think it doesn’t have the right tools to control users, especially for projects where the proportion of non-technical users and developers is high. This is especially problematic when active issues with developer notes begin to be filled with comments from users who have never contributed to the project and usually do more harm than good. This situation ultimately creates irritation among developers.
Finally, GitHub appears to follow the current trend of focusing more on AI and generative AI, which is destroying the open web (or what’s left of it), among other problems. This has a direct impact on us because sites protect themselves with JavaScript walls (or worse, browser fingerprinting) to prevent aggressive LLM crawler bots from overloading the site, but they also leave out Dillo users. So I would prefer not to encourage this trend. Despite my intentions, taking Dillo away won’t change much in their ability to train their models with our code, but at least I won’t be actively helping.
self-host dillo
After researching the available options, it seems that none of the existing Forges will allow us to have a redundant system that can prevent Forge from becoming a single point of failure and solve the rest of the problems with GitHub. So, I decided to host Dillo myself, move all important data to a Git repository, and keep them synchronized across multiple Git mirrors.
I decided to purchase the dilo-browser.org domain name and setup a very small VPS. Initially, I was very skeptical that it would be able to survive on today’s web, but it seems to be doing an acceptable job at handling it (mostly AI bot traffic disguised as users). The Dillo website is available at:
https://dello-browser.org/
I researched which Git frontend might suit our needs, and I found that most options are too complex to self-host and require a lot of server resources and JavaScript on the frontend. I ended up testing CGIT, which is written in C and it seems to be very light on both RAM and CPU usage. Also, the web frontend doesn’t require JS, so I can use it from Dillo (I modified the CGIT CSS a bit to work well on Dillo). It is available at this URL:
https://git.dillo-browser.org/
Regarding bug trackers, I also took a look at the options available. They are all too complex for what I want and seem to centralize data into one database that can get lost. The exact same case happened with the old Dillo bug tracker and we are still unable to recover the original bug entries.
To avoid this problem, I created my own bug tracker software, Buggy, which is a very simple C tool that parses plain Markdown files and creates a single HTML page for each bug. All bugs are stored in a git repository and a git hook regenerates the bug page and index on each new commit. Since it’s just plain text, I can edit the bugs locally and send them to the remote only when I have internet back, so it works well offline. Plus, since the output is just a static HTML site, I don’t have to worry about any vulnerabilities in my code, as it will only run at build time. You can see it live here with issues exported from GitHub:
https://bug.dillo-browser.org/
The mailing list records are stored by three independent external services, but I may also include a copy with our own records in the future.
mirror installation
Since all important data is now stored in a Git repository, we can mirror them in any Forge, without relying on their custom storage format for issues or other data. If a forge breaks down (or becomes defective) we can easily switch to another site with lower switching costs. For this purpose, I have created Git mirrors in Codeberg and Sourcehat that are synced with our Git server:
However, we still have one point of failure: the DNS entry of the dilo-browser.org domain. If we lose the DNS entry (such as with dilo.org) it will create a problem as all services will be inaccessible. We can recover from such a situation by relying on alternative methods of reaching users, such as mailing lists, fediverse or IRC, as well as by updating mirrors to reflect the current situation. This isn’t ideal, but I don’t think it will lead to catastrophic data loss (as it did in the past) because all data is now stored in Git and replicated to independent locations.
openpgp signature
To get this page to have some authority, the HTML file is signed with my GPG key (32E65EC501A1B6FDF8190D293EE6BA977EB2A253), which is the same one I use to sign the last release of Dillo and is also listed in my GitHub user. The signature is available here and linked to the page tag using rel=signature
Relationship. You can find more information and how to verify signatures in DILLO RFC-006.
Using OpenPGP signatures is robust against losing a DNS entry, because authorization is given not by the TLS certificate chain but by trust in the OpenPGP signature, so we can move the site elsewhere and still claim we own it. Additionally, since we can store signatures inside all Git mirrors, they are also resilient against data loss.
last words
Keep in mind that the migration process requires many moving parts and will take some time to stabilize (switching costs). GitHub repositories will not be deleted at any time and will continue to be updated until we complete the migration.When the migration process is complete, I will mark the Dillo repository as archived and transmit it properly to our site, It is important that we do not delete any commits or tarball releases that are still dependent on the GitHub URL to avoid breaking downstream builds,
In the end, I’m glad that we can have our own completely free and self-hosted site with relatively low expenses and very low energy costs (which is good for the environment, but probably not even noticeable on a large scale). With current DNS and server costs and our current donations I believe it is likely that we can continue to cover expenses for at least the next 3 years, even in a worst-case scenario. If you’re interested in keeping us afloat, you can help through LibrePay.
<a href