All credit goes here.
This page is intended as my personal infodump for sharing my insights into the incredible work of Deuxfleurs. The majority of the information below is pulled from various sources which I link back to. Several articles were only available in French, so please blame me for any inaccuracies due to machine translation. Please let me know if something should be improved or changed.
From “From research to Deuxfleurs and back again: towards digital service infrastructure as commons”:
Deuxfleurs is a French hosting collective created as an association in 2020. It aims at providing reliable digital services over the Internet, with a focus on services facilitating human-to-human communication. Currently, the main service is website hosting with more than 600 websites hosted, targeted at individuals and collectives. Other communication services are provided such as chat (Matrix) and email.
Deuxfleurs exists in a context of environmental and social crises, and starts from the realization that mainstream digital systems are, on the whole, mainly contributing to these crises rather than helping to solve them. However, Deuxfleurs believes it is still possible to provide digital services that are socially beneficial while keeping a low environmental impact. This is done by following a set of core principles.
First and foremost, Deuxfleurs promotes a radical form of sobriety or sufficiency: the infrastructure operates entirely without datacenters, and all hardware and services are hosted on small second-hand computers. This means that limits of the infrastructure are very quickly visible and this is intentional. Having direct visibility on the infrastructure and its limits helps users understand their own impact. For instance, websites have a very low storage quota by default (50 MB) and the current storage usage is shown in the administration interface. Users can increase the quota themselves up to a certain limit: this creates just enough friction to help generate discussion and positive actions from users. Despite these intentional limits, by carefully choosing services and making sure their implementation consumes a low amount of resources, Deuxfleurs can fit a lot of users on its small infrastructure: it estimates that it could easily host 10 000 to 50 000 web sites without significant changes to its operation model.
The second core value is reliability and robustness. Small service providers are sometimes not reliable enough to gain mainstream adoption and they remain forever in the ”alternative” category, never being able to seriously compete with established actors. Deuxfleurs has the ambition to promote its model and core values to a wide audience, and thus needs to be itself a credible and reliable service provider. This reliability is achieved through technical processes (redundancy, orchestration, simplicity, automation), through a collective human organization, and through understanding and controlling major dependencies. Deuxfleurs currently hosts more than 700 websites and has successfully gained the confidence of museums, trade unions, and even large metropolitan public authorities.
Third, Deuxfleurs adopts a critical approach to technology. In practice, it means designing and developing appropriate technology that embodies the values of the collective. It also means having a clear stance on dependencies and how to manage them. Some dependencies are easily avoided: having one’s own hardware and hosting it ”at home” avoids depending on a datacenter operator. Some dependencies are unavoidable, however it remains possible to control their impact: electricity, network connectivity, hardware chipsets. . . Taking dependencies in the more general socio-technical sense, relying on skilled members to create and maintain the infrastructure creates a dependency on society as a whole (for their training, available time etc.).
Note: “Mutual hosting” seems to be an emerging term whose definition is not exactly defined yet. It is also referred to as “Collective Hosting” or “Group Hosting”. I prefer the “Mutual” variant.
We can summarise “Mutual hosting” as “sharing copies of your data across multiple servers”. This is one of important social and technical innovations which Deuxfleurs applies in their work. It is not a new idea but it is hard to practically implement. From I don’t want to host services (but I do):
At TeDomum and Deuxfleurs, we develop the idea of « group-hosting » (« entre-hébergement » in French), as opposed to self-hosting (auto-hébergement). Due to e.g. the bus factor, we recommend against self-hosting, and in favor of collectives handling their digital hosting in common, and even as a commons. As you said, the collective’s structure and processes mustn’t be overlooked: several admins must be able to solve any kind of issue, a trust model must be defined, admins must understand their responsibilities, our limits (technical and organisational) must be clearly acknowledged, etc.
I don’t want to suggest that handmade hosting is inherently less reliable and so be it. Although, because we have a direct relationship with the people we host (and because they are generally politically curious at least), we stand on a good position to turn any technical failure into a fruitful debate on our societies’ reliance on complex, failure-prone, technocratic and ecologically unsound digital devices. In that regard, self/group-hosting is more than dissent, it’s a very fertile soil to collectively propose novel and modern lifestyles, societal models; under our control.
The basis of this approach is elaborated on in the excerpt below from Introducing Garage, our self-hosted distributed object storage solution. Garage is a software that Deuxfleurs developed and maintains.
Deuxfleurs is a non-profit based in France that aims to defend and promote individual freedom and rights on the Internet. In their quest to build a decentralized, resilient self-hosting infrastructure, they have found that currently, existing software is often ill-suited to such a particular deployment scenario. In the context of data storage, Garage was built to provide a highly available data store that exploits redundancy over different geographical locations, and does its best to not be too impacted by network latencies.
[…]
Self-hosting is a hard problem
As I said, self-hosting means running our own hardware at home, and providing 24/7 Internet services from there. We have many reasons for doing this. One is because this is the only way we can truly control who has access to our data. Another one is that it helps us be aware of the physical substrate of which the Internet is made: making the Internet run has an environmental cost that we want to evaluate and keep under control. The physical hardware also gives us a sense of community, calling to mind all of the people that could currently be connected and making use of our services, and reminding us of the purpose for which we are doing this.
If you have a home, you know that bad things can happen there too. The power grid is not infallible, and neither is your Internet connection. Fires and floods happen. And the computers we are running can themselves crash at any moment, for any number of reasons. Self-hosted solutions today are often not equipped to face such challenges and might suffer from unavailability or data loss as a consequence.
If we want to grow our communities, and attract more people that might be sympathetic to our vision of the world, we need a baseline of quality for the services we provide. Users can tolerate some flaws or imperfections, in the name of defending and promoting their ideals, but if the services are catastrophic, being unavailable at critical times, or losing users’ precious data, the compromise is much harder to make and people will be tempted to go back to a comfortable lifestyle bestowed by big tech companies.
Fixing availability, making services reliable even when hosted at unreliable locations or on unreliable hardware is one of the main objectives of Deuxfleurs, and in particular of the project Garage which we are building.
Distributed systems to the rescue
Distributed systems, or distributed computing, is a set of techniques that can be applied to make computer services more reliable, by making them run on several computers at once. It so happens that a few of us have studied distributed systems, which helps a lot (some of us even have PhDs!). The following concepts of distributed computing are particularly relevant to us:
Crash tolerance is when a service that runs on several computers at once can continue operating normally even when one (or a small number) of the computers stops working.
Geo-distribution is when the computers that make up a distributed system are not all located in the same facility. Ideally, they would even be spread over different cities, so that outages affecting one region do not prevent the rest of the system from working.
We set out to apply these concepts at Deuxfleurs to build our infrastructure, in order to provide services that are replicated over several machines in several geographical locations, so that we are able to provide good availability guarantees to our users. We try to use as most as possible software packages that already existed and are freely available, for example the Linux operating system and the HashiCorp suite (Nomad and Consul).
Unfortunately, in the domain of distributed data storage, the available options weren’t entirely satisfactory in our case, which is why we launched the development of our own solution: Garage. We will talk more in other blog posts about why Garage is better suited to us than alternative options. In this post, I will simply try to give a high-level overview of what Garage is.
What is Garage, exactly?
Garage is a distributed storage solution, that automatically replicates your data on several servers. Garage takes into account the geographical location of servers, and ensures that copies of your data are located at different locations when possible for maximal redundancy, a unique feature in the landscape of distributed storage systems.
Deuxfleurs runs “foundational” digital services for its users and members. From How to join the association:
Our association distinguishes between users and members . Users simply benefit from our services but do not participate in the association’s activities. Members, in addition to using our services, participate in discussions, decisions, and the direction taken by the association, notably through their right to vote at the general assembly (GA).
Here is a list of their services and relevant documentation.
There are other experimental services and tools under testing. Some of these are used to manage the infrastructure itself and therefore not relevant for users/members. The most up-to-date listing is available in their technical configuration repository.
It would be nearly impossible to summarise all the ins-and-outs of the technical decisions that Deuxfleurs have taken. However, some brief examples and a catalogue of tools are shared below.
They emphasise the idea of “redundancy at every level” which means specific technical decisions at each layer of the technical architecture. It means operating with constraints. To quote one of the Deuxfleurs maintainers:
The question we ask ourselves is « can people rely on us, even in situations where our machines break and our zones go down? » If the answer is « no », then we need to rework our architecture.
As a brief example, we can work backwards starting from the application layer. Most applications require a way to store data that is either suitable for a relational database (sqlite, PostgreSQL, etc.) or on a file system (files, audio, various media).
As mentioned above, Garage is a distributed object storage solution for the latter type of data. For relational databases, Deuxfleurs make use of PostgreSQL & Stolon.
If we upload a cat photo to our application, it can be stored in one Garage deployment and then is shared (or “replicated”, in distributed storage jargon) to the rest (shared copies in multiple places). The metadata that we uploaded a cat photo might be stored in PostgreSQL, which is then also replicated.
If one laptop goes down (electricity cut, heatwave, ISP block, failed hard drive, etc.), another will automatically take over, serving my cat photo. This forms a distributed data storage abstraction which can be relied upon.
There are many social and technical implications resulting from these architectural choices. For example, if we are serving multiple redundant versions of an application then the load can also be shared among them. If one goes down, the others can keep going. If we want to carry out maintenance work, we can do this for one version of the application and if it succeeds, bring the changes to every version.
However, we must also question the material limits of storage and whether it is truly necessary to implement a distributed storage abstraction. Isn’t storing multiple copies of everything wasteful? Can we justify this redundancy in relation to resource usage? A start is made at addressing this in the ethical considerations section below.
Alongside the data layer, Deuxfleurs have developed strategies for each layer. In some cases, specific software has been developed for this exact need.
Computing hardware (buy refurbished or 2nd/3rd hand computers for home): They have documented all their production home servers here.
Operating system (what runs on the computers): They are using NixOS and share their entire configuration publicly here. NixOS uses the concept of Generations to ensure the ability to “rollback” if something breaks while changing the system.
Distributed data cluster (share data between homes): They use PostreSQL & Stolon for their relational databases and Garage for NoSQL (Aerogramme will make use of this eventually) and object storage.
Distributed network plane (share network access between homes): They have created a series of tools which allow home servers to connect to each other in a mesh network (private connectivity) (wgautomesh), to be publicly accessible despite not having stable ipv4 addresses (D53), navigating port forwarding (diplomat) and to request certificates and serve web pages (tricot).
Backup and restore (share backup between homes): Garage, Rclone and Restic are used for backing up data.
User management (central log in and overview of services): They have developed a LDAP-based system (bottin) and users/members can log in and interact with their account using Guichet.
Observability (monitoring of what is going on): They are using Prometheus and Grafana.
Applications (apps which run on top of this distributed abstraction): As mentioned above, they are running several applications which user/members are using on a weekly basis. It is important to note that software development needs to focus specifically on enabling this kind of distributed architecture. From Crossing outside the clouds:
In our investigations, we began by looking behind the cloud, that is, at how cloud companies operate. It turns out that to overcome the limitations of individual computers, these companies no longer consider them as independent entities but as a whole, a set, which we will call a cluster. This concept is reflected in software development: the software is coded differently to take into account the specific characteristics of a server cluster.
From Our new old computers:
Moving away from data centers and the cloud has a very tangible consequence for Deuxfleurs and its members: we need to acquire our own servers to host our own services on the internet. Deuxfleurs’ recent acquisition of 35 machines provides an opportunity to review our strategy.
As a reminder, a server is simply a computer connected to the internet, like the one you’re reading this article from. The only difference is that specialized software is installed on it and it needs to stay powered on. It’s this computer that will host your website and serve it to visitors, receive and send your emails, manage your video conferencing, and so on! In industry, specialized computers have been created for these purposes for various reasons, but it’s not at all necessary: any computer will do the job.
For ecological, cost, and space reasons, Deuxfleurs chose to use old desktop computers rather than specialized machines. To help you visualize this, the photo below likely depicts one of these computers in its previous life. Indeed, our batch of 35 computers was used by statisticians at INSEE in Bordeaux, who have probably upgraded their IT equipment to more powerful machines and sold these old ones.
Today Google boasts of using 100% renewable energy (RES) in its data centers, making any alternative unnecessary? Not so fast, the comparison is not simple: renewable energies do not produce continuously, nuclear power is low carbon, wind turbines have a short lifespan and generate emissions during their manufacture, etc.
While lengthy comparisons could be made, we believe the real issues lie elsewhere: in the usage and replacement of equipment. Indeed, it takes 48 years for a computer to emit as much carbon through its electricity consumption in France as it did during its manufacture. And this also applies to smartphones and servers. Given that a phone is replaced on average every two years, a computer probably every five years or less, and that servers are often replaced in companies upon the expiration of their warranty (within five years), digital devices primarily pollute during their manufacturing process. Added to this are the numerous gadgets sold by the GAFAM companies, such as personal assistants, smartwatches, etc., which also generate pollution during their production and use.
We therefore chose to create our own infrastructure in response, to act effectively where it matters most: less hardware, replaced less frequently. We thus offer standard, streamlined services compatible with your existing devices. For our part, we use our second-hand servers for extended periods and minimize their number .
From How is Deuxfleurs doing in this heatwave?:
During the week of June 22-28, 2026, France experienced a widespread heatwave with temperatures exceeding 40°C in several regions. These extreme temperatures, compared to typical June conditions, had a significant impact on digital infrastructure. The question then arises: how well did Deuxfleurs cope? To answer this, we will review the status of Deuxfleurs’ infrastructure and services during this heatwave.
[…]
What can we learn from this experience? As expected, infrastructure is heavily impacted by such high temperatures and extreme weather conditions.
At Deuxfleurs, we see the benefit of maintaining a small, low-consumption infrastructure. Fundamentally, this is a matter of resource efficiency, the idea being to impose strict limits on our machines to emphasize the tangible nature of digital technology. This involves a deliberate compromise: we have to choose which services can run on this limited infrastructure. At Deuxfleurs, we can host our emails and static website, but there’s no unlimited storage, no WordPress, and no generative AI. But today, with this heatwave, we’re realizing that the simplicity of our infrastructure has another advantage: it’s much easier to keep it operational in a crisis! For example, if we had had to host very energy-intensive machines, whether at home or in a data center, heat dissipation would have been a problem this week.
The second lesson learned is that geographical replication of the infrastructure effectively mitigates the inevitable outages in individual areas. This replication obviously comes at a cost in terms of hardware resources , but it’s well worth it: we regularly use replication to manage fiber optic outages or maintenance work smoothly. We’ve observed that even an extreme and widespread heatwave across France – and even Europe – didn’t disrupt this strategy, even though we had limited room for maneuver and came close to experiencing a simultaneous outage in two areas.
Finally, we must consider how to organize ourselves while accepting that digital infrastructure and services can fail. This idea is notably found in Infogreen Factory’s white paper on robustness : for the authors, a social organization is robust if it is able to “maintain its essential functions in a stable and viable manner in the face of digital failures.” The paper offers some suggestions for achieving this: “heterogeneity of solutions, redundancy of resources, acceptance of relative slowness, and maintenance of low-tech alternatives.”
Finally, we are well aware that Deuxfleurs’ dependence on the electrical grid is an issue that needs further investigation, and we had already begun to consider possible solutions. This kind of weather event will push us to examine the matter even more seriously.
One implication of this distributed architecture is the need for so-called “digital sobriety”. If you try to upload you 250 GB torrent stash, it will be replicated multiple times. So, we need to actually reduce the amount of data we produce if we want to use this kind of system without draining our material resources. For example, we should delete our emails every month, limit our websites to max 50 MB and store our family photo catalogue on a hard drive at home (or print out the good ones!).
Wellbeing of system administrators is not ignored. The technical architecture is also about avoiding burnout and protecting its technical maintainers from urgencies which explode out of nowhere. It does not stop technical emergencies but it gives space: if your machine goes down on friday evening, another will take its place without intervention. You can fix your problem in a few days, not a few minutes.
From Crossing outside the clouds:
Because we do not intend to stay by our computers’ bedside (can you imagine not taking any more vacations?), to be in the anguish of breakdown (will I be able to fix it?) or to give a bad image of alternative hosting providers (“it never works!”), the technical team considered it a priority to find a solution to the problem of server failure before recruiting more users.
We are appalled engineers. Appalled by the dangers of the mines upon which our technological “modernity” depends. Appalled by the toxic waste and slave labor conditions in the factories that manufacture our phones, computers, and servers. Appalled by the power conferred upon multinational digital corporations under the guise of “optimization,” to the point that water and energy are redirected to their data centers rather than to local populations. Appalled by the redirection of these tools to promote a warlike, xenophobic, and consumerist agenda. Appalled by the electronic waste that poisons the soil and people, endlessly replaying that sad Brazilian short film, The Island of Flowers.
Of course, the idea of changing careers, of making a complete career change as they say, has crossed our minds. But could we escape digital technology for the rest of our lives? What about the rest of society? Who would we leave digital technology to? And why give up before even trying? We don’t know if a desirable and sustainable world is possible with digital technology, but we are convinced that, before democratically deciding whether we want to dismantle it, we must regain control of it.
To paraphrase Juan Pablo Gutierrez, a member of the Yupka indigenous people decimated by the Swiss mining company Glencore, we have embraced the rhetoric of the digital age (broad access to culture and knowledge, facilitated communication, etc.) but are equally devastated by its logic (extractivist, productivist, industrial). More than brutal and crude rhetoric, indigenous peoples, miners in the Congo, and workers in Southeast Asia expect concrete actions from us that will enable a dignified life for all human beings on Earth.
We are therefore choosing a radical but incomplete stance. Incomplete because we do not propose to solve all the problems of the digital age, but simply to chart a course to mitigate them and empower those who depend on it today. But radical, in the sense of addressing the root causes of the problems: extractivism, productivism, the exploitation of workers, industrial and capitalist logics, and the phenomena of power concentration.
Given that we, too, lack a satisfactory solution for the electrical grid—at least on our scale—we’re trying a different approach: what if we tried to leave the grid altogether? After all, projects like Solar Low-Tech Magazine and the Solar Protocol have done it; why not follow their example? The former relies on a small solar panel and an old lead-acid car battery, while the latter uses servers powered solely by solar panels but distributed across the globe in locations that are always sunny. Unfortunately, replicating these two models is impossible for us: our servers consume too much energy and would require a quantity of solar panels and batteries that would forever bury our principles of energy efficiency. The latter essentially shifts the burden of service availability onto the network connecting these servers: transferring data to the four corners of the world also requires electricity; we just don’t always realize it. In our deliberations, we crossed paths with entities like Énergie de Nantes and ECLAIRS , the Bréquigny self-consumption loop. But above all, a few years ago, we discovered the story of the Moulin Bleu and its turbine, which is waiting to be repaired, and that gave us some ideas…
A young, dynamic association is looking for old mills. This Tuesday, October 21st, Lucien and Baptiste met with millers at the 1st Millers’ Congress at La Filature d’Angreviers , near Nantes. And indeed, mills have been catching our eye ever since we learned that:
France has the highest number of watermills in Europe, with as many as 110,000 in operation around 1840. Today, there are only a few thousand. The Loire-Brittany basin has significant potential for electricity production.
And then it is completely in line with our approach of re-appropriating the means of production, the fact of putting a material dimension back on our electricity production, it facilitates self-limitation: we see the complexity and impact of energy production, we do not want to increase it, and so it gives meaning to the adaptation of our needs.
Lucien is still in the prospecting phase; to date, Deuxfleurs hasn’t found anyone to host its servers in a mill. So, if you have access to a mill, even one that produces a little electricity, in western France, northern France, the Paris region, or northern Burgundy, contact Lucien ( zuma@ deuxfleurs.fr) as soon as possible.
There are some not-entirely-unproblematic software choices living in the technical stack of Deuxfleurs (e.g. Nix governance scandal and Hashicorp IBM takeover and license rug pulling). While keeping in mind that Todays tech landscape is basically “the floor is lava” for trying to avoid fascism, I have rarely seen an IT collective so thoroughly catalogue its major dependencies and maintain them in a constrained manner over several years. The politics of the underlying technical choices remain a point of contention.
Technological choices are informed by ecological thinking. From Beyond Green Energy:
Let us begin with two observations:
A good or service has environmental consequences throughout its entire life cycle: manufacturing, transport, use and end of life. Climate is not the only planetary boundary that humanity is disrupting; we can also mention land-use change, the integrity of the biosphere, chemical pollution, water resources… From this, we observe that, concerning computer hardware, the manufacturing phase is by far the most significant in terms of carbon emissions, but also in terms of impact on abiotic resources, such as water, minerals, etc. This is also true for electricity production: manufacturing even wind turbines is polluting. Several of our choices stem from these observations:
- Focusing on technologies (email, websites) that do not contribute to the obsolescence of your devices or our servers,
- A choice of refurbished servers made from old desktop computers , which are cheaper to produce than dedicated machines .
- Custom software design to combat this obsolescence,
- And finally, a desire to follow our own technological trajectory by rejecting, for example, AI in favor of maintaining open internet protocols.
Facing recent events in the software-defined storage community, we would like to highlight that not all open-source projects choose an open-source license for the same reasons. Some open-source projects appear to be designed for “growth-hacking” with an “expensive license exit”, whereas others are designed as “commons” where all the stakeholders benefiting from the project are taking care of the software while protecting their business or activity. As the creators of Garage, we believe in the latter vision of a “commoning open-source”. We made sure, from the beginning, that any new development on Garage will always be released under the same license. Read more to understand our vision of the legal implications of software licensing.
Deuxfleurs runs a digital infrastructure without data centers which hundreds of users/members rely on. It emphasises a commitment to their needs (reliability, usability, simplicity etc. instead of purely technical priorities) and uses a paid membership model (a donation of 15 EUR a year per member is recommended but more or 0 EUR is also accepted).
The technical architecture articulates the motto of “redundancy at every level”, promising to allow system administrators to live their lives without fear of being called into a infra firefight emergency at any moment. Holidays remain a firm possibility. If one server goes down, another takes its place automatically.
Deuxfleurs appears to reject self-hosting for this purpose and promotes what they are calling “mutual hosting” or “collective hosting”. This is a technical approach based on the ideas of distributed computing, in which every computer keeps a copy of the data. They have reappropriated some of the ideas of the IT industry and Big Tech (more specifically, Google’s SRE practices and “Cloud Native” patterns) and put them in the service of community managed digital infrastructure.
It is a proven model which functions for 6 years already and is trusted by “non-technical” sections of society (trade unions, businesses and NGOs). It could be seen as a synthesis of self-hosting practices (such as homebrewserver.club) and the feminist server manifesto, e.g. striking an appropriate balance between “reliability” and “unreliability” (socially acceptable levels of uptime vs. downtime) and reconciling individual technical needs (providing foundational services) and service to a common cause (promoting broader digital solidarity and taking an ethical position). I believe it can be considered a form of Counter Cloud Action.
I have personally not seen such a model which can provide “foundational” digital services that most people need (email, websites, file storage etc.), to a broad public (and not just a subculture or niche) with the offer of reliability without sacrificing ethical considerations, causing burnout for its technical members or succumbing to “compromises of convenience”.
Deuxfleurs could be considered a platform for degrowth, with their work contributing to the formation of research papers and conferences.