Chapter 2a: Server Issues: Platform Infrastructure

Ambulant Infrastructure

Figure 2.1: The ServPub mobile server

Wiki4print, the collective writing software for this book, runs on a Raspberry Pi that hosts https://wiki4print.servpub.net/ and travels with us (see figure 2.1). We have physically constructed our own network of servers, keeping the hardware close as we use, teach, experiment, and activate it with others. This chapter examines the materiality of our network, our infrastructure choices, and what it means to navigate the world with these objects. As we consider our movement we begin to understand how an ambulant server allows us to locate the boundaries of software processes, hardware quirks, building and estate issues, and ways in which we fit into larger networked infrastructures. We examine departures, arrivals, and transience, exposing the bounds of access, permission, visibility, precarity, and luck. Proximity to the server fosters an affective relationship, or what Lauren Berlant referred to as affective infrastructure – a need for the commons, building solidarity through social relations and learning together. These precarious objects demand responsibility and care, allowing us to engage critically with the physicality of digital platforms and infrastructures, entangled with emotional, social, and material dimensions. Unlike vast, impersonal cloud systems, our mobile server emphasises flexibility, rhythm, and scale – offering a bodily, hands-on experience that challenges dominant, efficiency-driven industrial models that prioritise automation, speed, and large-scale resource consumption.

Thus chapter discusses our choice to make physical infrastructure mobile and visible. Understanding material realities of cloud infrastructure requires more than computational hardware and software: one needs to consider physical architecture, cooling systems, power supply, national and spatial politics, and labour required to run a server farm. Discussing technofeminism, artist-researcher Cornelia Sollfrank referred to Brian Larkin's essay on "The Politics and Poetics of Infrastructure." Larkin defines infrastructure as “matter that enables the movement of other matter,” such as electricity grids and water pipes sustaining servers or micro-computers. What then is the material body or shape of an ambulant infrastructure that moves between spaces? To reveal this materiality we map our collective experiences through stacks of space. These reflect our relative positions as artists/technologists/activists/academics:  

• THE PUB / PUBLIC SPACES
• INSTITUTIONAL SPACES
• SUITCASES AS SPACE
• WORKSHOPS AS SPACE
• CULTURAL / SEMI-PUBLIC SPACES
• DOMESTIC / PRIVATE SPACES
• NATIONS / TRAVEL

By situating our mobile server within these diverse spatial contexts, we illuminate the complex interplay between technology, place, social relations, and embodied experience, advancing a critical discussion of infrastructure that foregrounds the materiality of data, software, social-technical processes, and tangible hardware. This leads to an essential question: why does server mobility matter?

Traveling server space: why does it matter?

Many precedents have contributed to the exploration of feminist servers. While there is significant focus on care, labor conditions, and maintenance, technical infrastructure remains largely hidden as servers are fixed in locations remote from working groups. We often perceive them as distant, large-scale entities – especially in the current technological landscape dominated by terms such as "server farms."

Figure 2.2: rosa, a feminist server, in ATNOFS.

Rosa – part of the ATNOFS project – is a feminist travelling server. It travels between sites, enabling collaborative documentation and notetaking (in 2022, meetings and workshops took place across 5 different locations). Rosa is also part of self-hosted and self-organised infrastructures, engaging "with questions of autonomy, community and sovereignty in relation to network services, data storage and computational infrastructure." Naming is important in male-dominated tech discourse: "We’ve been calling rosa ‘they’ to think in multiples instead of one determined thing/person. We want to rethink how we want to relate to rosa." In this way, rosa/server performs identity, reflecting feminist values: acting not as a neutral or passive machine, but as a situated, relational agent of care and resistance. This "situated technology" echoes Donna Haraway’s "situated knowledge" – it emerges from particular bodies, contexts, and relations of power. The descriptors become significant:

Is it about self definition? – I am a feminist server. Or is it enough if they support feminist content? It is not only about identifying, but also whether their ways of doing or practice are feminist.

Describing a server as feminist is not merely to identify who builds it or uses it, but to consider how it is produced, maintained, and engaged with – in opposition to the patriarchal and extractive logic of mainstream computing. However, without careful qualification, the idea of a feminist server risks defaulting to white, ableist, and cis-normative assumptions, potentially obscuring interconnected systems of oppression. An intersectional approach is needed to account for the distributed forms of power in operation. In the publication, for instance, ATNOFS argue that a focus on resources can connect issues related to "labour, time, energy, sustainability, intersectionality, decoloniality, feminism, embodied and situated knowledges. This means that, even in situations focusing on one specific struggle, we can’t forget the others, these struggles are all linked."

The travelling rosa server is highly influential as it encourages ServPub members to rethink infrastructure – not as something remote and distant, but as something tangible, self-sustained, and collective. It also highlights the possibility of operating and learning otherwise, without reliance on big tech corporations which are often opaque and inaccessible. While most feminist server and self-hosting initiatives have emerged outside of London, we are curious about how the concept of travelling physical servers could shape a vastly different landscape defined by critical educational pedagogies, limited funding, and the pressures of UK's highly competitive art and cultural industry. The first consideration is skills transfer – fostering an environment where technical knowledge, caring atmosphere, and open-minded thinking are recognised and encouraged, enabling deeper exploration of infrastructure. This is also where the London-based collective In-grid comes into the picture of ServPub.

THE PUB / PUBLIC SPACES: Networking space

Figure 2.3: The poster of the International Trans★Feminist Digital Depletion Strike

On 8 March 2023 (8M), an international strike called for a "hyperscaledown of extractive digital services." The strike was convened by Europe-based collectives including In-grid, Systerserver, Hackers and Designers, Varia, The Institute for Technology in the Public Interest, NEoN, and others. This day prompted reflection on our dependency on Big Tech Cloud infrastructure (Amazon, Google, and Microsoft) and resisting dominant computational paradigms through experimentation, imagination, and self-hosted collaborative server infrastructures.

Louise Amoore's Cloud Ethics frames such actions as encounters with algorithmic infrastructures' "cloudy" opacity, where responsibility emerges in partial, distributed relations across platforms, data centres, and human actors, rather than transparent code or fixed moral rules. The Strike's Webrings-hosted website – technically a 1990s-style network of networks – is a decentralised, community-driven structure that cycles content across 19 server nodes in different locations (including In-grid). Users automatically cycle through nodes displaying identical content. Webrings – typically created and maintained by individuals or small groups rather than corporations – form a social-technical infrastructure that decentralises control, distributes relations, and resists extractive digital ecosystems and support the Counter Cloud Action Day.

That evening, London-based individuals and collectives gathered at a pub in Peckham, near University of the Arts London, where some of us worked. What began as an online network of networks transformed into an onsite network of networks, as we engaged in discussions about our positionality and shared interests. This in-person meeting brought together In-grid, Systerserver, and noNames collectives, forging a collaborative alliance around local hosting, small-scale research infrastructure, community building, and collective learning.

INSTITUTIONAL SPACES

Within this context of decentralised and community-driven digital infrastructures, educational institutions provide a stark contrast. Many ServPub participants are affiliated with universities, where working this way proves challenging – infrastructures remain locked down, outsourced to third parties, and often reliant on big tech. For example, Microsoft 365 dominates organising daily tasks, meetings, routines, and documents through SharePoint, a cloud-based platform handling team collaboration, document storage, and intranet services. Similarly, the institutional networked infrastructure Eduroam (short for Education Roaming) offers global, secure access and convenience but comes with limitations and challenges, including IT control and network restrictions, such as port blocking to prevent unauthorised or high-bandwidth usage, and traffic monitoring under strict privacy policies. This protective environment inevitably trades users' agency and autonomy for efficiency, limiting infrastructural engagement beyond mere convenience.

Figure 2.4: A screenshot of the CTP Server

The CTP (critical-technical practice) server at Aarhus University (see Figure 2.4) represents an ongoing attempt to build and maintain alternatives outside institutional constraints. It was a response to the challenges of outside collaboration (allowing access) and running software deemed a security threat, thus requiring careful negotiation with IT procedures and policy-makers. In 2022, the CTP project invited a member of Systerserver to deliver a workshop titled "Hello Terminal" – a hands-on introduction to system administration. However, remote access ports were blocked, preventing anyone without a university account and VPN from participating and limiting what participants could do with the servers.

Understanding infrastructure raises fundamental questions: what is a server? and how do you configure one? Answering these requires computer terminal access and specific user permissions for configuration or installation – traditionally managed by IT departments. Most universities provide only "clean" preconfigured server environments or rely on easy-to-maintain big tech solutions, limiting hands-on exposure to setup and infrastructure. This issue is explored further in Chapter 3. Standardised, enclosed systems leave little or no room for alternative approaches to learning. For researchers, teachers, and students viewing infrastructures as research objects – rather than merely tools for consumption – opportunities to engage with it remain scarce. This lack of flexibility makes it difficult to understand the black box of technology in ways that go beyond theoretical study. How then can we create legitimate spaces for study, exploration and experimentation with local-host servers and small-scale infrastructure within institutions?

Creating such spaces proves challenging. University IT may not always recognise that software's profound influence on how we see, think, and work – a point Wendy Chun emphasises when she argues that software is not neutral, but deeply influences cognition, perception, and work. This is a crucial aspect of teaching and learning that goes beyond simply adopting readily available tools. Our request to implement Etherpad – a free open-source real-time collaborative writing tool widely used by grassroots communities for internal operations and workshop-based learning – exemplifies this challenge. Unlike mainstream tools, Etherpad facilitates shared authorship and co-learning, aligning with our pedagogical values.

In advocating for its use, we found ourselves strongly defending both our choice of tools and the reasons why Microsoft Word was insufficient. IT initially questioned the need for Etherpad, comparing it to other collaborative platforms such as Padlet, Miro, and Figma. Their priority, as we learned, was easy Microsoft integration – driven by centralised management concerns and administrative efficiency rather than pedagogical or experimental value. When we highlighted Etherpad’s open-source nature and opportunities it offers for adaptation, customisation, and community-driven development, we also pointed to how this reflects our teaching ethos of fostering critical engagement and giving students agency in shaping the tools they use. Despite this, IT still demanded further justifications; we demonstrated how Etherpad supports teaching in ways that for example Google Docs do not. It took nearly a year to establish it as a legitimate option. The broader point is that introducing non-mainstream, non-corporate software into institutional settings demands substantial labour – not only in time, but also justification, negotiation, and communication.

The ServPub project began with a simple desire to make space for engaging software and infrastructure differently, through emphasising self-hosting and small-scale systems that enable greater autonomy for (un)learning. One of our goals is to explore what becomes possible when we move away from centralised platforms and servers, offering direct access to knowledge embedded in infrastructure and technology. Developing alternative approaches requires a deeper understanding of technology – beyond well-defined, packaged, and standardised solutions.

Our first ServPub workshop took place at a university in London in 2023. As we configured a server using a Raspberry Pi, we encountered such constraints firsthand: the university’s Eduroam network blocked ServPub's VPN access. Institutional security policies often restrict VPN and local network traffic as "insecure" – VPNs obscure user activity, bypass filters, and introduce potential security risks. Network administrators block VPN ports and protocols and ports to maintain control. These restrictions create significant challenges for experimental, self-hosted projects such as ours.

How do we enable device-to-device communication when VPNs are considered risky by Eduroam? A disconnected router allows local communication within a classroom or workshop, but public internet access requires the use of a VPN and mobile data. VPNs, accessible online via a static IP address, need stable servers – within ServPub, one server permanently runs in Austria (mur.at), routing public traffic through our ambulant server network. Two of our servers are ambulant Raspberry Pis. They host wiki4print.servpub.net and servpub.net; when offline these sites are inaccessible. During some institutional workshops – in order to facilitate local device-to-device communication and access to the ServPub VPN – we resorted to sharing the organisers’ personal hotspot connections (using a mobile data network limited to 15 users), stepping outside of Eduroam to bring in our networked ambulant servers. While this is not ideal, this is necessary.

Eduroam’s technical architecture embed institutional control into network access. While designed to provide secure and seamless global connectivity through standardised authentication protocols, it enforces user dependency on institutional credentials and policies that limit experimentation and autonomous use of infrastructure. Our experience with Eduroam exemplifies these tensions between institutional infrastructures and the desire for self-determined, flexible technological practices.

This experience of navigating institutional constraints points to the significance of mobility and portability. Carrying our server with us enables a form of technological autonomy that challenges fixed infrastructures and their limitations. This brings us to consider the physical and conceptual implications of portability: what it means to live and work with servers in suitcases, transforming these objects into ambulant spaces in their own right.

SUITCASES AS SPACES

We have referenced the fact that our server can be brought with us to visit other places; the server runs on a computer. In practice, this means a repeated unplugging and packing away of various objects. We unplug the computer – literally and figuratively – from the network. In the case of wiki4print, the node unplugged, sans-electricity and network, consists of:

• Raspberry Pi (the computer)
• SD memory card
• 4G dongle and SIM card (pay-as-you-go)
• Touch screen
• Mini cooling fan
• Heat sink
• Other useful bits and pieces (mouse, keyboard, power/ethernet/HDMI cables)

Figure 2.5: The back side of the wiki4print server. The Raspberry Pi with cooling fan, back of the touch screen and board that controls the screen.

These items have been variously bought, begged, and borrowed from retailers, friends, and employers. We have avoided buying new items where possible, opting to reuse or recycle hardware. We try to use recycled or borrowed items for two primary reasons. First, we are conscious of the environmental impact of buying new equipment and are keen to limit the extent to which we contribute to emissions from the manufacturing, transportation, and disposal of tech hardware. Secondly, we are a group working with small budgets, often coming from limited pots of funding within our respective institutions. These amounts of funding are most often connected to a particular project, workshop, or conference and do not typically cover the labour costs of those activities. Any additional hardware purchases, therefore, eat into the funds which can be used to compensate the work of those involved. Avoiding buying new is not always an option, however, when travel comes into play, as new circumstances require new gear, such as region specific SIM cards, adapters, and cables accidentally left unpacked or forgotten.

It should be noted that packing and handling these items comes with a certain element of risk. The Raspberry Pi is exposed to the rigours of travel and public transport, making it easy to crush or contaminate. We know that as a sensitive piece of technology, it should be treated delicately, but the reality of picking up and moving it from one place to another – often on short notice – leads to us being less careful than we ought to be. The items constituting wiki4print have been placed in backpacks, wrapped in canvas bags, shoved into pockets, and held in teeth. So far, nothing has broken irreparably, but we live in anticipation of this changing.

Raspberry Pis are small single-board computers built on a single circuit board, with the microprocessors, ports, and other hardware features visible. Single-board computers use relatively small amounts of energy, particularly in comparison to server farms. However, they are fragile. The operating system of our Raspberry Pis runs off SD cards, and without extra housing, these are easy to break. They are by no means a standard choice for reliable or large-scale server solutions. Nevertheless, their size, portability, and educational potential are the reasons we chose to host servpub.net websites on them.

The Raspberry Pis that host servpub.net and wiki4print.servpub.net were second-hand. In many ways, we used Raspberry Pis because they are ubiquitous within the educational and DIY maker contexts in which many of us work. There are other open-source hardware alternatives available today – such as Libre Computer – and if we were to consider buying a new computer, we would examine our choices around using a closed-source hardware option such as a Raspberry Pi. The fact that our second-hand Raspberry Pis were readily available within academic contexts reflects the educational practices and concerns within ServPub.

The Raspberry Pi Foundation’s mission is largely educational. Although Raspberry Pis are comparatively not as cheap anymore (compared to some PCs), making computing physical can make computing concepts more accessible and engaging. In his book Mindstorms, Seymour Papert (the creator of the educational programming language Logo) writes that “gears served as an ‘object-to-think-with.’” He explains how he could use his body to think about gears by imagining how his body turned to find a way into understanding the mathematical aspects of how gears worked. Raspberry Pis, microcontrollers such as Arduino, and other small physical computing objects within educational contexts serve as objects-to-think-with. In examinations of Papert’s ideas of construction kits in the context of network technologies, Stevens, Gunnar, et al. investigate the concept of “’objects-to-think-with-together’ in the context of using computers as tool and social medium at the same time.” The desire to bring the server as an object-to-think-with-together into a workshop space aligns with this wider tradition of making computing physical and visible for educational purposes.

A common conceptualisation of the internet is as a remote, untouchable entity – a server farm or, in the worst case, some nebulous cloud concept. Being able to point at an object helps us materialise the network. Using a small-scale computer allows us to bring the server into proximity with bodies during workshops. The visibility of the machine's components, such as exposed ethernet ports, enables a different type of relational attention to the hardware of the server.

LOCAL WORKSHOP SPACE

By physically bringing the server to teaching moments, we can discuss ideas around the physicality of a server. Once the computer is plugged in, we start to approach server as software.

One way to interact with the computer is by using a screen, mouse ,and keyboard. How do we access this computer from another device over a network? In early workshops, when we set up the first servpub.net Pi, we went through the process of creating a Local Area Network (LAN). Accessing devices within a LAN requires participants to be on the same network, usually in the same physical location. All computers need access to the same internet network, via an Ethernet cable or wirelessly through Wi-Fi or a mobile network. As mentioned in different sections of this chapter, this simple act of getting online differs from context to context. In this section, we will focus on what happens once the Pi and everyone in the room has access to the same internet network.

On a Raspberry Pi, we run a Linux operating system. There are various network protocols that will allow other computers to access the Raspberry Pi. We will focus on two: Secure Shell (SSH) and Hypertext Transfer Protocol (HTTP). SSH is a protocol that allows remote access from another computer, enabling system administration tasks such as installing software. HTTP allows us to access the Pi from the web browser of another computer – in other words, to serve up websites. In order to use either of these protocols you need to know the Internet Protocol address (IP address) of the Raspberry Pi, which is the address of the machine on the shared network.

In early workshops, Systerserver shared their approaches to system administration. Using the command line via the computer terminal on our own devices, we are able to SSH into the Raspberry Pi and work together to set up the machine. Systerserver shared their practice of using a terminal multiplexer, allowing multiple people to collaborate during system administration – one command line session runs on the Raspberry Pi, and people take turns typing commands on their own computer. We used this practice once the Pi was connected to the VPN, allowing us to do remote work from different countries. However, in an early workshop in London, we were all in the same room, working on the command line together. Being in the same room allowed us to learn and form habits for remote system administration.

Accessing the Pi through a web browser requires installing server software on the computer. The Apache HTTP Server Project is an example of open-source server software that you can install. On one Pi we installed a simple Nginx static web server, which serves up simple websites. During workshops when participants are in the same room on a local network, entering the IP address of the Raspberry Pi into the URL bar on another computer's web browser requests website files and displays them in the browser.

All this is before we begin to touch on topics such as automation and accessing other computers over the public internet using a VPN. During a workshop at LSBU, which was open to a wider public, we guided participants through the steps of connecting locally to a Raspberry Pi, before connecting the wiki4print server to the ServPub VPN for the first time. The session was a public co-working opportunity that revealed the hardware, processes such as local access to a server, and acts of system administration.

CULTURAL / SEMI-PUBLIC SPACES

Up to the point of writing, our wiki4print Pi has been a physical presence at several public workshops and events/interventions. Although in many – if not all – cases, it would be more practical and require less effort to leave the hardware at home, we opt to bring it with us, for the reasons outlined above. By dint of our artist/sysadmin/academic situations, the Pi has visited several of what we are defining as cultural spaces. We use this term to describe spaces that primarily support or present the work of creative practitioners: museums, galleries, artist studios, and libraries. This definition is not perfect and obscures many factors pertinent to this discussion. We are conflating publicly funded institutions with privately rented spaces, and spaces that are free to enter with others that have partial barriers such as membership or ticketing. However, we feel that for our purposes here, these comparisons – though imperfect – allow us to see common issues. As with our entrances and exits from institutional spaces (universities), domestic locations, and moments in transit, we need to spend some time feeling out the material conditions of the space and the customary practices and idiosyncrasies that define it. No two cultural spaces are built the same – just as no two homes are the same.

Below, we describe two spaces to explain what we mean.

1. SET Studios (London, UK)

An arts space run by a charity, based in a meanwhile-use building. The building contained rented studios used by individual artists and small businesses, a café and performance space, and a gallery space open to the public. The longevity of the space was always precarious due to the conditions of a meanwhile-use tenancy, and indeed the site has since been vacated to allow for redevelopment. The building itself was only partially maintained, as it was intended for demolition by the developers who owned it. Plumbing issues, faulty lifts, and non-functional Ethernet ports and sockets we common.

Wiki4print was originally housed at SET Studios in Woolwich, where several members of In-grid had artist studios. Before being maintained by the arts charity SET – which emerged out of London squat culture – it had been occupied by the HMRC. The use of meanwhile spaces within the London arts sector is closely tied to wider property development crises, where more and more artists are reliant on institutions that exist in the margins.

The reality of maintaining a studio within a meanwhile space is that much of the infrastructure is crumbling. When In-grid first set up the Raspberry Pis, the hope was to host them there indefinitely, but it quickly became apparent that it was not viable – the Ethernet ports in the room were non-functional, the Wi-Wi was unreliable, and the team maintaining the building were primarily artists rather than professional service providers, so estate support was sporadic.

2. Haus der Kulturen der Welt (Berlin, Germany)

HKW is a centre for contemporary arts, publicly funded by the federal government. The space hosts art exhibitions, theatre and performance, film screenings, and academic conferences. It also contains cafés and shops, and is generally open to the public, with some ticketed events.

We presented in this space as part of the Transmediale Festival, which serves as a "platform for critical reflection on cultural transformation from a post-digital perspective." We brought the Pi to Berlin as part of Content/Form, a research workshop culminating in a publication of a peer-reviewed newspaper, including contributions exploring the idea that content is entangled with – and inseparable from – the forms and formats in which it is rendered.

These spaces are demonstrably quite different in terms of scale, security, and publicness. That being said, there are common experiences when arriving in cultural spaces with a mobile server. We need to feel out the location every time, understand levels of access, the policies and politics of these spaces, and the duty of care or legislative duties that each institution must respect – which may also change depending on geography. We may have developed our protocols of working, but these cannot be imposed on other spaces indiscriminately. We need to acknowledge that we are sharing the space with its caretakers, with other creative groups (who have their own needs and working practices), and with the wider public – who may be impacted by or interested in our presence, or who may not even be aware we are sharing the space at all.

In our experience, cultural spaces are more personal and negotiable than educational institutions, despite the possibility of equal levels of government oversight and private interests. Crucially, we have found that cultural spaces have become intrinsic to our ability to experiment publicly and accessibly.

The most profound difference we have observed is the ability to establish a personal connection with individuals in order to make something happen – or to adjust or remove a factor which is impeding us (physical locked doors, virtual firewalls, and so on). In short, in cultural spaces it is easier to find people, whereas we have found that (at least in the UK) universities tend to adopt more detached processes. We have found it increasingly difficult to find faces on campuses, whereas in cultural spaces it was easier to locate technical staff, other tenants, communities of users or visitor coordinators. Indeed, while at HKW we were unable to identify which Ethernet port worked, we were able to work with people on site to configure or change some network settings to allow us to use their internet. If we wanted to do something similar in a UK university, we would be unlikely to find someone on hand, instead we would probably encounter help-desk ticketing systems and would need to wait for an email response after filling a form with a description, screenshots, and credentials. This is, of course, a generalisation, and is not a reflection on the people labouring behind those ticketing systems. Rather, it is a comment on the changing nature of work and the neoliberalisation of higher education systems.

We have found that while working within cultural spaces can occasionally be challenging – particularly in more precarious spaces where there may not be someone dedicated to sysadmin, for example – they tend to be more flexible. We are less likely to have to justify our choices or working methods; there is an understanding that we might try something unusual or even arguably needlessly convoluted (such as bringing a server to an arts conference) in order to deliver something we believe can be meaningful.

DOMESTIC / PRIVATE SPACES

Our wiki4print Pi ended up living in a house of an In-grid member in South London. How it got there was a result of the needs of caring for a temperamental Raspberry Pi in a temperamental meanwhile space (SET Studios). However, its particular journey through London – and where it has landed – was as much to do with the material constraints of internet access as with the needs of working in a collective. Passing hardware from hand to hand across London became a force that determined the material shape of the network: last-minute plans, emergencies, the demands of work schedules, holidays, illness, and commute times all played a part in the movement of the hardware.

On one occasion In-grid, NoNames and CC were engaging in an online working session to resolve an important functionality of wiki4print. The Pi kept going offline and needed someone on hand to physically reset the device or reconnect to the internet. We had to pause the workshop while the Pi was physically moved from SET Studios to the house of an In-grid member. Why to that person's house in particular? It was the closest to the studio and on the way to work for the other In-grid member. While others took a tea break, the server was passed from hand to hand at a doorstep in East London on a rainy grey day, stress was shared, the Pi was re-booted, and the workshop continued. Moreover, the server was about to travel to Germany for a conference, and this necessitated it being physically accessible to a member of In-grid who was travelling there.

We thought the Pi kept going offline because the SET Wi-Fi was bad – this was one of the problems, but it was also a red herring. We discovered there was another issue while the Pi was in its new home in East London (temporarily living under a bed so the Ethernet cable could reach it). Through the process of being able to debug at any hour (lying on the floor beside the bed), we were able to discover that the access problems were due to the Raspberry Pi overheating, freezing, and shutting down processes – which would take it offline. We bought a heat sink and fan for the Pi, and from then on it worked reliably in all locations.

Maintaining server hardware in a domestic space or outside the context of a server farm (small or large) becomes an act of providing care at odd hours. Maintenance invites the rhythms and bodies of others into the material realities of the network: cleaning cat hair out of the cooling fan, or plugging it back in because a guest did some hoovering and didn't realise what they were unplugging. When someone from the wider ServPub group reports that wiki4print is down on our mailing list, an In-grid member replies back with the latest anecdote about what has happened, providing a remote window into the lives and rhythms of bodies and hardware in domestic spaces.

NATIONS / TRAVEL

So far, this text has detailed the cultural, educational, and domestic spaces that have housed the server at different times and for different reasons. Sometimes out of convenience, sometimes as an educational tool, sometimes as evidence that indeed a server can indeed be built outside its farm – and frankly, we sometimes brought the server along just in case. Cutting through all these spaces was the core attribute of this server being ambulant, a need highlighted and inspired by the Rosa project, to which a significant portion of ServPub is owed. This need for mobility and reachability revealed the seams between what would otherwise be seamless transitions across different spaces with different politics. Perhaps most glaring of these seams were none other than the European borders themselves.

Although travelling with the hardware did little more than raise eyebrows from airport security staff, it was the crossing of a less ambulant person that almost prevented us from taking one of the servers to Amsterdam in the summer of 2024 for the EASSSST/4S conference. A small sub-group of the ServPub team was set to attend in order to present the project and host a hands-on workshop through the server. A member who was part of this sub-group had packed the hardware in their bag after retrieving it for the purpose of this trip. At the time of writing, they were holding refugee status in the UK and were allowed to travel within Europe with a UK-issued travel document, but there were exceptions.

The conference was in Amsterdam, to which they were allowed to travel, and the group were taking the Eurostar straight to their destination without making any stops. However, they were about to traverse a particularly absurd part of the French law pertaining to visas and freedom of movement. As the officers at the Eurostar terminal explained, because the train would cross French territory – for which the In-grid member would need a visa – they could not be allowed on the train. The fact the the destination was not in France and that the train was not due to make any stops in France did not matter. In fact, that argument only prompted the more absurd speculation that in the case of an emergency stop or breakdown of the train in France, they would be in breach of visa law – which was the justification for refusing them entry to the train. Four hours later, other In-grid members were on their way, and the server was still stuck in London.

The solution was to take a direct flight to Amsterdam the next day (and hope that it wouldn't emergency-land or break-down over France). But having had no funding for this trip, and not being able to refund the train ticket, this was perhaps the most jarring spatial transition during this project. Not only did it lay bare the limits of mobility and access; it also revealed the limits of collectivity and radical infrastructures. There was only so much infrastructure to radicalise when the political structures themselves are oppressive and only getting worse.

EXPOSING THE AMBULANT INFRASTRUCTURE

Using small, mobile, or DIY servers makes tangible something that is normally abstract and distant. While we use servers almost constantly, they rarely feel materially real. In contrast, our modest – and often fragile – setup reveals the seams of infrastructure, exposing the typically invisible dynamics of access, permission, and agency that shape how we move through institutions and shared spaces. Their scale and fallibility can at times be frustrating, but they are also embodied: downtime or glitches often trace back not to impersonal systems failures but to the social realities of care, memory, or negotiation – such as losing a password or deciding whether something is worth fixing at all.

Working with such infrastructures invites collaboration, responsibility, and stewardship, giving us a sense of proximity and empowerment: we can point to the device, understand its workings, and intervene directly. In workshops, they serve as access points to otherwise abstract network infrastructures, unsettling the seamless veneer of cloud computing and revealing the boundaries between hardware and software. Their mobility also highlights questions of access and borders, showing how technologies move differently from the people who maintain them. By exposing the fragility and contingency of networks, these servers make visible the social, affective, and political conditions of technological maintenance – reminding us that technology is not floating somewhere in the air, but is grounded in material forms of labour, collaboration, and care.

index.php?title=Category:ServPub