Low-tech Lab usually documents objects, techniques and ways of making things with fewer resources.
In 2026, the organisation applied the same logic to something much less photogenic: its own computing infrastructure.1
For three months, from January to March, the team experimented with self-hosting in its premises in Brittany. Its stated goal was twofold: move away from hosting at OVH and replace Google's suite, including Drive and email, with free and open tools it considered more consistent with its approach.1
By the end of June, Low-tech Lab says it had left Google.1
The interesting question is not whether a server in a building suddenly became “low-tech.”
It is that the organisation treated the migration as a skill worth documenting.
Self-hosting becomes a project, not a preference
The summary page divides the experiment into four chapters: understanding data issues, regaining control over hosting, installing a server in a community organisation, then migrating the data.1
That structure is almost boring.
That is exactly why it is useful.
Conversations about digital sovereignty easily turn into lists of principles: reduce dependence on a large provider, keep control of data, use free software, avoid centralised services. Those principles say very little about the moment somebody has to move years of files, accounts, calendars and email without stopping the organisation from working.
Low-tech Lab brings that part back into view.
The page explains, for example, that moving from Google Drive to Nextcloud used rclone, a tool for synchronising and transferring data between storage systems.1 That detail is more instructive than another manifesto. Leaving a service is not a matter of choosing a new icon. Somebody has to build a path between the old system and the new one.
Dependence does not disappear, it changes shape
Self-hosting is often described as the opposite of dependence.
In practice, it replaces some dependencies with others.
An organisation becomes less directly dependent on the provider hosting its files or office suite. In exchange, it needs access to skills for installation, backups, upgrades, monitoring and recovery.
Low-tech Lab's summary does not publish a quantified comparison showing that its new system is cheaper, lower-energy or more secure. Those claims should not be added on its behalf.1
What it does publish is a process of appropriation.
That fits surprisingly well with how low-tech already approaches physical objects. A device is meaningfully appropriable only when its operation can be understood, maintained and transmitted by more people than its original manufacturer.
With a server, the principle becomes more abstract but the constraint remains.
Infrastructure that nobody on the team can restore after a failure is not very autonomous, even if the hardware is sitting in the next room.
Documentation is part of the infrastructure
Low-tech Lab says the documentation is published under CC BY-SA.1
That turns an internal experiment into reusable material.
The same principle appears in open-source and maker communities: a reproducible system is not just the machine that happens to work today. It also requires instructions, choices, migration steps and enough reasoning for somebody else to rebuild the path.
For a physical object, that can mean a drawing, bill of materials or tutorial.
For software infrastructure, it means documenting accounts, services, backups, dependencies and recovery procedures. The material is less visible, but it ages just as reliably.
The server is therefore only half of the project.
The other half is the possibility that another collective can read what was done and decide what to reuse, modify or avoid.
Digital low-tech may begin by making exits practical
It would be easy to summarise the experiment as “Low-tech Lab leaves Google.”
That is true, but incomplete.
The transferable part lies in the opposite direction: how do you make leaving a central service practical?
The organisation spent three months testing the infrastructure before announcing the migration. It then published the path instead of only publishing the result.1
That is a fairly concrete definition of autonomy.
Not the absence of dependence. Not a promise that a small local server will beat global cloud infrastructure on every criterion.
The ability to understand a dependency well enough to change it.
In that frame, rclone, a backup procedure or a migration chapter are low-tech objects in the same sense as a repairable joint: they prevent a past decision from becoming a permanent lock.
Digital services have spent years hiding that problem behind “export your data” buttons.
Low-tech Lab puts it back on the workbench.