RAM-only servers: what they actually protect against

Full-disk encryption answers the question "what if someone takes the drive?" with "they get ciphertext." That is a good answer, and it depends on a chain of assumptions: that the key was strong, that the key was not in memory when the machine was taken, that the implementation has no flaw, that the passphrase was not obtained some other way.

A RAM-only server answers the same question differently: there is no drive. That removes the assumption chain rather than strengthening it, which is a categorically better kind of security property.

How a diskless server actually boots

There is no local storage device in the chassis at all — or if there is, it is not attached to your instance. The boot sequence is:

1. The NIC's PXE ROM requests an address and a boot file over DHCP.
2. It fetches iPXE, which fetches a kernel and an initramfs over HTTPS from a provisioning host.
3. The initramfs verifies a detached signature over the root image. On our platform this is a minisign signature; if it does not verify, the boot halts rather than continuing.
4. The root filesystem is unpacked into tmpfs — a filesystem that exists only in the kernel's page cache and has no backing store.
5. switch_root hands control to the real init, and cloud-init applies your configuration.

Two details matter. Swap is disabled and cannot be enabled, because a swap file would be exactly the persistent artefact the design exists to eliminate. And the image is fetched fresh every boot, so an attacker who compromises a running instance cannot leave anything behind that survives a reboot — the persistence mechanism they would normally use does not exist.

The consequence you have to design around: your RAM is also your disk. A GHOST M instance has 16 GB, and if your working set plus your filesystem exceeds it, the OOM killer arrives. In practice a Debian minimal root is about 900 MB in tmpfs, so you have most of it.

What it genuinely defeats

Physical seizure

This is the headline case and it is not marketing. When hardware is removed from a rack, it is powered down. DRAM cells are capacitors that leak; without refresh they decay in seconds at room temperature. What arrives at a forensics lab is a chassis with no storage device.

Forensic recovery of deleted data

On an SSD, "deleting" a file removes a pointer. The blocks remain until the controller's garbage collector reclaims them, and because of wear levelling and over-provisioning, copies may exist in physical blocks the OS cannot address and TRIM never reaches. Every serious forensic toolkit exploits this. On tmpfs there is no controller, no wear levelling, no over-provisioning and no unreachable spare area.

Persistent compromise

A rootkit that survives reboot needs somewhere to write. A signature-verified image fetched fresh over HTTPS every boot means rebooting is a genuine remediation rather than a hopeful gesture — which is why reboot is the first step in our incident runbook for GHOST instances.

Accidental retention

This one is underrated. Systemd journals, shell history, package caches, temp files, core dumps, log rotation — the accumulated sediment of a running system. On a normal server you have to actively hunt it down. On tmpfs it evaporates.

What it does not protect against

Being precise here matters more than the sales pitch:

• An adversary with live access. If someone has root on the running machine, the data is in memory and they can read it. RAM-only changes nothing about this.
• Traffic interception. Data leaving the box is on the wire regardless of how it was stored. Use TLS; consider forcing egress through Tor.
• A compromised provisioning chain. You are trusting the signed image. The builds are reproducible, but the image hashes and the signing key are not published yet, so there is nothing for you to check them against today. Until that changes, this is trust rather than verification, and you should treat it as trust.
• Your own carelessness. Mounting an off-node volume and writing plaintext to it recreates every problem the architecture removed.
• Hypervisor-level memory access. On any virtualised platform, the host can in principle read guest memory. This is true of every VPS everywhere. If your threat model includes the hypervisor operator, you need genuinely dedicated hardware, and we do not sell it — our VOID tier is bare-metal-class but still virtualised. Several offshore providers offer real dedicated hardware in more locations than we have; buy it from them.

Cold boot attacks: the honest caveat

DRAM does not decay instantly. Halderman et al., Lest We Remember: Cold Boot Attacks on Encryption Keys (USENIX Security, 2008), demonstrated that memory contents persist for seconds at room temperature and for minutes when the modules are chilled — long enough for a prepared attacker to cut power, transplant the DIMMs, and image them.

What this means in practice for a rack-mounted server in a controlled facility:

• The attack requires physical presence at the moment of seizure, with liquid-nitrogen or canned-air cooling ready. It is not something that can be done after the hardware has been transported.
• Modern DDR4 and DDR5 decay substantially faster than the DDR1/DDR2 modules used in the original research, and memory scrambling — enabled on the Xeon Scalable and EPYC platforms we run — means recovered contents require additional work to interpret.
• We enable memory clearing on reset in firmware, so a warm reboot overwrites rather than preserves.

The honest summary: RAM-only defeats the seizure-then-analyse workflow that describes essentially all real-world hosting seizures. It does not defeat a well-prepared adversary standing at the rack with cooling equipment at the moment power is cut. If that is your threat model, no hosting product solves it and you should not be renting servers.

Running real workloads on amnesiac hardware

The obvious objection: most software expects to keep things. Four patterns that work:

Declarative configuration

Boot with a cloud-init or NixOS configuration that fully describes the machine. Nothing needs to persist because everything is reconstructed. NixOS is exceptionally good at this — the configuration is the machine — which is why it is our default image on GHOST.

Off-node encrypted state

Keep the small amount that genuinely must survive — a database, a keyring, a config bundle — in an encrypted blob in a second jurisdiction, pulled and decrypted at boot with a key you supply. Our state vault add-on is exactly this: we hold ciphertext and a byte count.

Stateless-by-architecture services

Tor relays, VPN endpoints, reverse proxies, mail relays, CDN edges, build workers and load balancers are all naturally stateless. These are ideal GHOST workloads and require no adaptation at all.

Streaming persistence elsewhere

Write to a durable store over the network — an encrypted object store, a database on a disk-backed instance in another region. The RAM-only node becomes compute and never a system of record.

When to use it, and when not to

Use RAM-only when your threat model centres on the hardware being taken; when the workload is naturally stateless; when you want a reboot to be a real remediation; or when you need to be able to say truthfully that no copy exists.

Do not use RAM-only when you need a large working set on a budget — RAM is roughly forty times the cost per gigabyte of NVMe, and a 500 GB dataset in RAM is not a sensible purchase; when your software cannot tolerate losing local state on reboot and you are not prepared to change it; or when the real risk is network-level rather than physical, in which case you are paying a premium for the wrong control.

A pattern we see often and endorse: a GHOST instance handling the sensitive front-half of a workload, and a cheap disk-backed instance in a second jurisdiction holding encrypted state. You get amnesia where it matters and cost-effective durability where it does not.

Our GHOST series starts at €16.90/month for 2 vCPU and 8 GB. Image hashes and the minisign public key are not published yet; /ram-only says what is still missing.