A Server That Forgets: Exploring Stateless Relays

Running Tor relays requires constant work against adversaries, private and state-backed, who try to undermine the network by attacking the nodes that make it up. On top of that, some operators have to deal with seizures, raids, and direct physical access to hardware. There are precedents in Austria, Germany, the United States, Russia, and likely many others. In those instances, the server can become a liability.

Tor exists because we want to shield internet users from unwanted surveillance. The network is designed so that no single operator or server can reconstruct who is talking to whom. Journalists, activists, and whistleblowers depend on that holding up. A relay that can be seized and its contents handed over erodes the very trust the system depends on. And that's a problem we want to solve.

In this post we explore how a stateless, diskless operating system can improve relay security, from firmware to user space, with a focus on software integrity and physical attack resistance. This work comes from the experience of Osservatorio Nessuno running exit relays in Italy. Managing relays varies greatly depending on context, technical capability, budget, and jurisdiction. We hope to stimulate discussion rather than propose a single model.

What stateless means

A stateless system doesn't store anything between reboots. Every time it starts, it begins from a known, fixed image, just like Tails does. The idea of running a Tor relay entirely in RAM isn't new. Tor-ramdisk, a uClibc-based micro Linux distribution built for exactly this purpose, dates back to at least 2015.

For relay operators, this approach raises the security bar by enforcing better behaviors by design:

Physical attack resistance. If the machine is seized or cloned, there is nothing to analyze. Depending on the setup, the extraction of relay keys might become infeasible.

Declarative configuration. The system is version controlled. A stateless system cannot drift from its declared configuration, since every boot is a fresh apply.

Immutable runtime. The filesystem is read-only. Even if an attacker gains code execution, they cannot persist anything across a reboot.

Reproducibility. A system that doesn't change between reboots is easier to verify and, eventually, to reproduce and audit.

Why Tor relays are hard to make stateless

Tor relays build reputation over time: a relay that has been running for months earns bandwidth flags that make it more useful to the network. That reputation is tied to a long-term cryptographic identity key. Lose those keys and the relay loses its identity, and as such is reputation in the network, starting from scratch.

Thus, the relay's identity must survive reboots without being extractable. A key stored on disk can be seized and copied; a key stored in a security chip such as the TPM might be more challenging for attackers.

Beyond the identity key, a relay accumulates a state file containing bandwidth history and other temporary information. Discarding it on every reboot degrades performance, and running entirely in RAM means the OS has to fit in memory, with no possibility of swapping to disk. Whenever processes exceed available memory, the kernel's OOM killer terminates them outright. In practice, replacing glibc's allocator with jemalloc or mimalloc reduces Tor's memory footprint significantly, from around 5.7 GB to under 1.2 GB on a busy guard relay, largely by avoiding fragmentation from high-churn directory cache objects.

The TPM as the primary tool

A TPM (Trusted Platform Module) is a dedicated hardware chip on the motherboard that stores cryptographic keys and performs operations with them without ever exposing the private key to the operating system. It can seal a secret: bind it to a specific measured state of the machine, so the key can only be used if the TPM sees the exact same software stack it saw when the key was created.

For a stateless relay, this means the identity key survives reboots, as it lives in the hardware, but can't be conventionally extracted even with physical access. TPMs also support remote attestation: the chip can prove to an external system what software the machine was started with, backed by a hardware-rooted signature. This makes it possible to verify what a node is running without trusting the operator.

The TPM doesn't solve everything. Tor's usage of ed25519-based keys are not supported by the TPM chips, so the key is encrypted by the TPM but still stored as a byte string in non-volatile memory, meaning it is still technically possible to export it.

Sealing also requires deciding upfront what software state the TPM will trust. When you update the kernel or bootloader, the measured state changes, and you have to re-seal the TPM by predicting what the next boot will look like.

Existing approaches

Different operators have tackled this problem at different points on the trade-off curve between simplicity and depth of security.

Minimal ramdisk. The simplest approach: run everything in RAM, manage keys manually. Tor-ramdisk has done this since 2015. Identity keys are exported and imported over SCP; rebooting without doing so means starting over. No TPM, no attestation, no verified boot — just the guarantee that RAM doesn't survive a power cut. It remains a meaningful improvement over a conventional disk-based setup.

VM-based ramdisk. Emerald Onion runs per-relay Alpine Linux images (66 MB each) on a Proxmox hypervisor. The VMs boot entirely into RAM with no persistent storage attached. Identity is managed with Tor's OfflineMasterKey feature: the long-term master key is generated offline and never touches the relay. Updates are image rebuilds, rollback is trivial, and no special hardware is required.

Bare metal with TPM-backed identity. Patela, our tool, takes a more hardware-focused approach. The relay boots via stboot, a bootloader that fetches and cryptographically verifies a signed OS image before handing off control. Once running, the node pulls its configuration from a central server over mTLS, though a potentially compromised server can deny service but cannot push credentials or extract keys from the node. The relay's identity key lives in TPM non-volatile memory, bound to the measured boot state. It survives reboots but can't be extracted even with physical access. The trade-off is operational complexity: bare metal is required and re-sealing is needed after updates.

Open problems

Some of these problems are specific to our setup; others affect any stateless relay deployment.

Re-sealing after updates. When the software stack changes, the TPM's measured state changes too. Automating this, which implies predicting what the boot measurements will look like after an update, is one of the harder unsolved problems. Tooling like systemd-pcrlock is moving in this direction, but it's not turnkey yet.

Stateless reboots versus upgrades. We use standard unattended upgrades for the Tor binary. But a reboot reverts to the OS image, which contains the previous version, a causing an involuntary downgrade. Reconciling automatic security updates with stateless images is something we haven't fully solved.

Memory constraints. No swap means processes that exceed available memory are killed without warning. Tor's memory usage is hard to predict at runtime. The allocator replacement described above helps enormously, but the fundamental constraint remains.

Network stability. Persistent updates can only be applied rebuilding the images and booting it again. A relay that restarts frequently risks losing its Stable flag, which affects how much traffic the network sends to it.

Future directions

Remote attestation. Sealing binds a key to a machine state. Attestation lets the node prove that state to an external party. A verifier, suach as a configuration server or eventually the Tor directory authorities, can issue a cryptographic challenge that only a node running the expected software stack can answer correctly. This turns boot integrity from a local property into something verifiable remotely, reducing operator trust.

Transparency logs. Once you have a measured boot chain, you can publish it. A relay operator provides a recipe for a reproducible build; anyone can recompute the expected hash and verify it matches what the TPM reports. An append-only transparency log can make these attestations publicly auditable. The Tor community could run an independent monitor to track this across the relay fleet.

Confidential computing. The VM-based approach can be extended with technologies like AMD SEV-SNP, which isolate a guest VM's memory from the hypervisor itself. This too, is useful to reduce operator trust, and can reduce the security gap between the VM and bare-metal approaches.

Smaller hardware. Walking onions, a proposed Tor protocol extension, would remove the need for nodes to hold an entire view of the network locally. Getting arti and related tools to run on smaller hardware would open up possibilities for devices that currently can't afford the resource cost.

Conclusion

For applications like Tor, being stateless can bring multiple benefits: helps both prevent attacks and operator errors, and with further research and work could improve the overall network trustworthiness.

Stateless systems come with real operational costs and genuinely hard unsolved problems, even for project and organizations with more resources. But they can serve as a foundation for improving privacy infrastructure, and similar concepts and frameworks could be applied to other parts of the stack.

This work started at the Tor Community Gathering in 2025, and it's ongoing. If you run relays, work on Tor tooling, or have thought about any of these open problems, we'd like to hear from you.

References

• Stateless Tor Relay – Tor Community Gathering 2025
• Patela v1: A Basement Full of Amnesic Servers
• Patela v2: From Certificates to Hardware
• stboot System Documentation – System Transparency
• Tor-ramdisk 20150714 Release Announcement
• Evolving Our Tor Relay Security Architecture – Emerald Onion
• Tor Memory Optimizations: What Actually Works – 1AEO