By Luis Landa

Nearly a year ago, I embarked on a journey to build, document, and deploy a solar powered website and server. This idea was born out of a desire to explore the intersection between ecology and technology to engage with sustainable computing and low-tech both materially and conceptually. This post serves as a continuation and evolution of my previous blogpost, where I presented why I wanted to create a web environment as detached as possible from the extractivist essence of today’s cloud.

Across the many excellent resources I encountered, I noticed that none of them provided a personal account on how the project developed or the many smaller challenges that can arise. Inspired by and ecological limits, I will in this blogpost share experiences and reflections upon the technical approach and specificities.

My hope is that this post will help someone in the future that decides to embark on a project like this or perhaps decides to build on it. So, while this post may have more technicalities attached to it, I aim to present in a way that will convey the human aspect of engaging with sustainable IT and the inner realisations/epiphanies that occur when dealing hands-on with the materiality of websites and servers.


Bit by Bit, the Best Way to Learn About Computer Hardware 💻

Going straight to where the last blogpost left off, the status was that I had a renewable energy source to power our server, and it was time to find a suitable computer to serve for the server. The computer’s power requirements must keep in mind the limits attached to obtaining solar energy in the climate conditions of Copenhagen and the battery size of the power module.

The limits rule out most ‘normal’ sized computers and servers as the total power draw of these would allow them to be powered for a few hours. This led me to look into Systems on a Chip (SoC’s) which, as their name implies, are computers whose components all fit within a small chip. You may already be very familiar with SoCs, as you can find them in mobile phones and most portable computing devices. The most famous SoC that can act as a computer (and my initial choice) is the Raspberry Pi. As I continued to research the different hardware configuration for a SoC server, I ran across Open-source hardware. Due to its commitment to transparency and community sharing, I thought selecting an SoC from the extensive list would be better choice.

How does one usually choose a computer? This question varies depending on the person, some that require more computing power may want a speced up computer. Others may be happy with any of the existing configuration offered by manufacturers.

Ideally, the server will be powered as long as possible within the estimated charging cycle of the battery. In real life terms, we want the website/server combo to be accessible as much as the weather allows us to. It is important to mention here, that an incredibly simple website in a low power SoC computer would theoretically be able to maintain itself up 100% of the time. That is only if enough optimisations are done to the hardware and software. However, since the desired website is a little more than very simple, a decision had to be made as to a goal for a minimum ‘up-time’ for the website.

This little insight presents an interesting yet obvious aspect of digital technology. It implies that there is always some form of agency on how the goal of our technologies can be shaped by its limits. Furthermore, it also points towards what type of work would replace the larger part of the never-ending search for ever more computers. Most of that effort would now be dedicated to shaping, optimising, and testing existing hardware within its biosphere friendly limits. Due to the general lack of sun in Copenhagen and the relative limited time for this project, I decided that the up-time goal for the website should be 252 days which is around 70% of a year. This does not take into account winter but more on that later.

With the target of 70% of a year, I set out to scour through the thousands of open-source hardware SoC and asked questions in the many forums full of passionate people willing to help. I ultimately ended up choosing an A20-OLinXino-LIME. On top of having the specs to function as a server, it hosts a specialised chip for power management and the ability of attaching a battery for fail-safe purposes.

The power management chip is particularly interesting since the whole module is Open Hardware. It allows the user to access every single configuration providing further ability to tweak it according to the goal and to obtain data that can help assess whether the goal was reached. This made me realise how the locality and geography of these projects affects the goals and work around them.

In a different timeline where digital technologies evolved alongside an ecologically friendly society. Our digital services and their material counterparts would follow and be shaped by the environmental features around them. Returning to the point about winter, in the case of Scandinavia and large part of the north solar power would be an awful choice.  Rather wind-power would be the preferred option, particularly if one would decide to scale this endeavour for larger populations and services. The case may be different closer to the equator. This touches upon a theme explored in the previous blogpost, the perceived limitlessness of digital technology. Assuming an equal global development of these technologies, geographical context would have shaped them in a similar way they have shaped architecture or urban planning specific to an area.


Figure 1: The A20 SoC that hosts the website


Operating System and Accessibility of DIY IT Projects

Once I had the chip in my hands and I began researching how to install a power-efficient server operating system (OS), something became quite clear to me. Independent of the existing specialised knowledge those in IT and hardware manufacture have. The accessibility of DIY computing and unorthodox projects such as mine is sadly quite low. There are many factors to this, though I consider the main one the investment most major tech companies make into making their products consumer-friendly.

From this perspective, control is foregone for the sake of convenience. While this is not entirely undesirable, to me it showcases how centralised forms of knowledge stand as barriers to thinking differently about digital technologies. This further extends to software. While many may argue that installing an OS on an SD card through the terminal or command line is not particularly difficult, it is nevertheless quite intimidating for most digital technology users. The commitment of this project to use open-source and the boundaries of the solar power also extends to software. As such the OS must follow the initial goal of being able to host the website 70% of the year.


Figure 2: The terminal can be intimidating though most installers are streamlined and easy to follow


As for the OS chosen for the project, the hardware compatible version of Armbian OS proved to be the most convenient. On one hand extensive documentation and tried-and-tested examples of low energy projects have used the software, including low-tech magazine. Additionally, it is specially built to be light weight and is open source.

At this time of writing, the OS and the server are currently installed on the SoC and some local tests have been made for the website. Due to time constraints, however, I have been unable to fully deploy it. This means that the website is not fully accessible to the public, however, thanks to the magic of the internet I hope to update this blogpost with a link to it once its live.  Many reasons made it hard to fully go ahead with deploying the project, some personal and some circumstantial. For example, the 5V power input for the SoC was damaged when I received it and replacing it was harder than expected. Furthermore, since the set-up is hooked up to a solar panel, some modifications are needed for the cables. Nevertheless, the server not being fully deployed hasn’t stopped me from continuing with other areas of the project. Namely, the front-end and the website itself. 

Sustainable Practices in Web Design

Though I am generally unexperienced in nearly every are of this project, the topic that I was the most unfamiliar with was web design. I understand how they work at a glance, however, I never had to design a website from scratch. Let alone think about how I could incorporate sustainable design practices into its core. Luckily an excellent book regarding these topics exists, Designing for Sustainability by Tim Frick, and while I have only scanned for my needs I can recommend it to anyone willing to go deeper into the subject. In the book, an argument is made as to how the front-end of a website comprises the majority of the load time needed to access it. In energy terms, the longer a website takes to load, the higher the power used by the server. Thus, as with the 70% accessibility goal, the front-end goal was to make the website as low weight and intensity as possible.

As with most websites, one can choose to either take up any of the thousands of existing themes and platforms that offer ready-made websites, create your own from scratch, or a mix of both where one would build their website on top of an existing solution. I decided for the latter, since it would be the best choice for the limited time I had. For this, I googled for already existing solutions to see what was there, but first I had to familiarise myself with how websites work and how some of their implementations may be more sustainable than others. I had to always keep in mind the limits of the hardware and software when going through these solutions.

Among the first things I learned about websites was their dynamicity. There is a big difference between the earlier internet (pre-2000s) and today and it is mostly focused on how dynamic a website can be. Previously websites were static, meaning that the user would access a unique and unchanging version of the site. The best example for this would be the ability to comment on a website. The ability to comment itself does not translate to anything dynamic, but the ability to display them in real-time does.

Take any blog that allows users to post comments, once a comment is made it is immediately shown in the webpage. The fetching of the comment and updating it for everyone is what makes the website dynamic. This process implies energy consumption as depending on our configuration, the website will continuously look for new input and update it for everyone to see. Nowadays websites are very dynamic, something that is ubiquitous even though some may not necessarily need to be. This is another example of how centralised existing solutions can reproduce unnecessary energy consuming tasks. No one is necessarily at fault here, the internet and digital technology are not immune to the overall trend of being taxing on ecosystems. This is simply how it is manifested in a small part of web design.

Figure 3: The frontpage of My playground for web design while parallelly working on the hardware


As websites have become more complex, so have the designs and styles they exhibit. Chiefly among these is the ability to display animated objects, pictures, and videos. These increase the overall size of a website and therefore increase the energy needed to load them. While in absolute terms this energy might not be enough to say power a household, the fact it has become expected and ever-present speak more to the aesthetic essence of webpages today.

While designing the website with all of these considerations in mind, I was thinking of the aesthetic of it. How would I convey the idea that the website is solar powered? The way that Low-Tech Magazine does it is impressive but technically far out of my reach. Their overall aesthetic in many ways commands the back-end development of image filters and widgets that display the battery charge. This serves as another example as to how ecological limits can fundamentally steer every aspect of an IT project. As for my website and going the choice to build on something already existing, this blogpost by Jack Lennox provided me with an excellent solution.

The current state of this experiments and design can be accessed here. Due to it being a static website, the power draw inflicted on the server is minimal. The lack of any particular font ensures that no outside service is connected to fetch them, while at the same time further reducing the load on the server and thus energy draw. 


Conclusions of an Unfinished Project

As stated earlier, while I am still working on deploying the server and battling with aspects that I still need to figure out, I can still provide some insight into my journey. First, committing to a DIY solution necessitates a journey through all aspects of modern IT management, development, design, and research. So if you’re planning on doing it, best be ready to really immerse yourself into this world.

Second, this journey is sadly not accessible to all, despite documentation being abundant, it is usually far removed from the ease of access digital technology we are used to. Third, communities centred around open-source hardware and software are vibrant and full of helpful people. While not all of them may focus on ecology or sustainability their commitment to openness and developing various uses for existing hardware align make them very open to projects such as this. Fourth, balancing IT Project Management, research of hardware and software, installation of these and ensuring that they run correctly, web design, implementation, deployment of sites has been far harder than I thought.

I hope that this blogpost serves at least as a preview of what is to come, and I would recommend doing it with some company! Finally, the path is wide open and ready to be explored, however you ought to be patient and take it one step at a time.

I wish I could convey much more of what I learned but I still feel like these concepts are being absorbed into my brain, so until the next time I would be happy to answer any questions or comments you have.