Anyone who runs a web agency inevitably also runs internally used infrastructure. Servers that provide development environments for application development, test deployments, and handle build processes. These servers run continuously, not because they’re constantly needed, but because they have to be available at all times.
Idling infrastructure
This leads to a peculiarity that’s rarely discussed in the industry: development servers are structurally underused. A dev server waits for requests that arrive irregularly: a developer carries out a deployment, tests a function, starts a build process. In between: nothing. The CPU sits idle, the memory is reserved, the server runs all the same. This isn’t a sign that the team is underworked, but rather the result of normal operations: capacity has to be available before it’s needed, not only once demand arises.
On our development server, actual CPU use from regular work processes averages to less than ten percent of total capacity. The remaining ninety percent is technically available, and until now has simply gone unused.
Computing power with a purpose
At some point this got us thinking, because the obvious follow-up question is: how can we use this capacity for something meaningful, without endangering operations?
The answer we came across is called BOINC (Berkeley Open Infrastructure for Network Computing), a system originally developed at the University of California, Berkeley, and used today by millions of computers worldwide. The basic principle is technically simple: BOINC runs in the background, uses computing capacity that isn’t otherwise needed at the moment, and automatically sends the results back to serve research projects. As soon as the server takes on regular load, BOINC takes a step back. There’s no manual coordination, no interference with normal operations.
Green electricity as a prerequisite
What mattered to us here was the question of power consumption: additional computing load also means additional energy demand. Our servers run at the professional hosting provider Hetzner in Germany, and Hetzner sources its electricity 100% from renewable hydropower. The ecological footprint of the additional computing load is therefore acceptable to us: we consume somewhat more electricity, but no fossil fuels are used in the process.
The chosen projects in detail
When it came to selecting research projects, we focused on thematic priorities. There are three at the moment:
Climate Prediction is a joint project of several European universities, including Oxford and Reading. It computes climate models; specifically, simulations of how various scenarios affect the global climate. Climate modeling is computationally intensive and benefits directly from distributed computing capacity, because more simulations can run simultaneously and can thus increase the statistical basis for the research.
World Community Grid is operated by IBM and pools computing capacity for a broader range of scientific projects: medical research, projects developing climate-resistant crops, analyses of neglected tropical diseases. The approach is more generalist than Climate Prediction, but the quality of the affiliated projects is high and the selection of research fields is transparently documented.
Einstein@home evaluates measurement data from gravitational-wave detectors and radio telescopes, searching for as-yet-undiscovered pulsars and other astrophysical phenomena. This isn’t applied research in the narrower sense, but basic research of this kind has historically led time and again to insights whose practical relevance only became apparent years later.
Our conclusion
What convinces us about this setup is that it isn’t a symbolic gesture. The computing capacity of the hardware would otherwise genuinely sit unused, the electricity is renewable, and the projects have real scientific value. We’re writing about this because sustainability isn’t an add-on for us, but a lived part of our values. We also hope that other agencies with similar infrastructure will ask the same question. The answer is more straightforward than it sounds.
If you’d like to implement this yourself on your own server, you can find a short guide in the second part of this series for setting it up on an Ubuntu server with sensible resource limits for production operation.
