I don't want to host services (but I do)

Hello folks,

I am self-hosting enthusiast, I’ve been following Framasoft for a long while and I think the CHATONS initiative is fundamental to keep a healthy Internet and digital life.

I have been self-hosting services for a few years now, and I decided to list all the things I screwed up and others might fail at too, so CHATONS and enthusiasts can avoid doing the same mistakes when offering alternatives to hegemonic services.

The key takeaways from the article are in the conclusion:

My recommendation to most people putting services online would be: either do it for yourself only, or do it as a team with proper structure and processes. What sounds like an initiative to emancipate people could actually alienate them to you, and that is a huge responsibility.

I believe it’s important to be able to self-host, even if only to prove it’s possible to do without hegemonic services. But we need to figure out how to do decentralise services and data storage for individuals at scale. This is not just a technical problem, and while E2EE is a good starting point it’s not a silver bullet. I will expand in a further post about the role of E2EE, where it falls short, and what I think we should do as a society to improve the situation.

I’m particularly looking forward to reading your feedback regarding your experience, and I’m interested in ideas you might have when it comes to the non-technical solutions worth exploring to push back against hegemonic services.



Hi Thib, welcome around :blush:

I’ve stumbled on your blog post in my Mastodon feed, and I feel like you’re hitting the point, especially on the matter of high availability and the bus factor. Thank you for sharing your thoughts :slight_smile:

The first issue that CHATONS addresses pretty well in my opinion is the scaling: having dozens of hosters serving different services sounds effective to me, when it comes to split the burden of maintaining services though multiple entities with their own governance.
Hosting all services required to satisfy one’s need (let’s say: mailing, PeerTube, Mastodon, Nextcloud and various other tools) sounds very hard when there’s only a few people working on it.
With CHATONS, our organization (as a CHATONS member) can host some services depending on our capabilities and our available time (mailing, Nextcloud…) and when someone asks us a service we don’t have, we’re happy to redirect them to another hoster we trust (another CHATONS member).
The main caveat: the end user needs to create an account per CHATONS they are using. This could be solved with inter-CHATONS SSO, but we’re not there yet.

The second issue CHATONS may address on the long term is the sharing and pooling of resources : for off-site monitoring, shared cache between Mastodon instances, off-site (encrypted) backups, which lowers the technical and economic requirements to set up a « production-grade » environment with redundancy and backup. Software solutions and protocols (Garage, S3, or even NFS) helps in achieving this challenge, but we still lack of global cooperation between CHATONS to make it happen.

Finally, it seems like you are emphasizing on high availability and downtime during updates, which is indeed a great issue we have with small hosters. Google and co. does have a great uptime, because they have the means to, which sets very high expectations on the service quality.
We often tell our users that they have to accept we can’t give them the same level of availability than Google’s : we’ll have downtimes from time to time, and if it happens unexpectedly during the night, the service may not be restored until noon the next day. And actually, they’re pretty much fine with it. They know we’re small and trying our best, and most of them seems to accept to lower their expectations in order to regain control over their data.
If we were hosting critical infrastructure such as medical records, we certainly would have enough money to pay someone to ensure night shifts. But it isn’t the case, and it’s okay.

I’d add another point: you wrote about sustainability of the software dependencies of the hoster, though the hoster’s sustainability itself is a big deal too. We have self hosters in CHATONS throwing in the towel every year, by lacking of time and/or motivation, and thus asking their users to switch to another host before closing their services. Hopefully, some members the collective can take over some of their services by achieving data migration, as it was the case when Framasoft closed half of their services.


Hi Thib,

Your point on the responsibility of self-hosters is of the utmost importance. We do more harm to the causes we value by letting people down with ethical hosting, than letting them on hegemonic services in the first place. Most of us have learnt it the hard way.

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.


Hi Thib,

You might be interested in this text entitled « The art of co-hosting » written during a course at School For Poetic Computation (SFPC) named « Solidarity Infrastructure ». I think it echoes nicely to your article and motivations.

The course description:

How do we cultivate infrastructures of solidarity with each other, especially under conditions of crisis, protest, and systemic inequity? Beyond corporate data clouds and monopolistic service providers, this class offered critical space to reframe technology from a grassroots perspective in relation to other components of day-to-day societal infrastructure.

We explored concepts like the slow web, organic Internet, right-to-repair, data sovereignty, minimal computing and anti-computing, in context of the intersectional Just Transition movement. We learned how community tech and cultural organizing go hand-in-hand through real-world case studies. We learned about the creative applications and underlying ideologies of various open source tools and network topologies. We tuned into signals of radical communication beyond colonialist legibility. Along the way, we aimed to challenge the technocapitalist worldview, breaking the dichotomy of « high » and « low » tech in favor of a needs-based approach that centers collectivist values and the Earth.

Over the course of the class, participants developed technical skills for running a situated server practice and learn from each others’ experiences. Each participant was encouraged to apply the idea of « computing in place » to their own locale through a creative project which ranged from a small poetic experiment, to archiving personal and familial stories, to collaborating with the neighborhood library, community garden, elderly home, or mutual aid coalition. As creative practitioners, we directed our imaginative power toward experimenting with refusal, repair, responsibility, and reconnection in order to dream into practice the relational infrastructures we need.

The conclusion of the article:

During my interview series, Alice asked me how can we « reframe server hosting as a community endeavor, as an extension of radical organizing and care-based artistic practices? » We both found that « hosting » is a loose yet productive term that bridges community tech and conviviality. Hosting with and for others — online or IRL — is a slow and relational practice of (digital) attunement. Perhaps a digital intervention may not even be necessary (Architect Sandi Hilal’s project Al Madhafah, where « guest » and « host » are subverted in a public living room configuration, was a solidarity infrastructure case study). Co-hosting is a dialogic practice of mutual designation rather than top-down managerial capital. Solidarity infrastructures shows us that the relational infrastructures of a community can be just as important as the servers and circuits. If a web server is a hammer, not every need in the community will be a nail. We started by listening to the needs of our communities. ⚘

(FR): Esther de Deuxfleurs a contacté l’auteur de l’article, et nous prévoyons d’en publier une traduction prochainement.

1 Like