RAM-Backed VPN Runtime Says Nothing About Logging

A VPN server booted from a read-only image with its runtime state on tmpfs is a real and useful design. It is also easy to describe as no logs, which the design does not establish. Storage location governs where a copy lives; collection and retention govern whether a record exists at all, and a reboot only affects the first. Keeping those apart is the entire review.

Start by listing every process that can write state: the daemon, the authentication service, the journal, any monitoring agent and the management tooling.

Storage and Collection Are Different Questions

Each writer has its own destination and its own policy. The VPN daemon writes status files, the authentication backend writes account events, the journal collects service output, and a monitoring agent ships metrics somewhere else entirely. A design that makes one of those disappear at reboot has said nothing about the other three. Follow each writer to its destination and note whether that destination is on the machine at all.

Application-specific files, uploaded diagnostics and external services need the same treatment. The absence of a familiar local log does not prove that connection or account records exist nowhere; it proves you have not yet found where they go.

tmpfs Is Not a Guarantee

Linux tmpfs is not a physical RAM disk. The kernel documentation is explicit that pages can be written to swap when the mount allows it, so a tmpfs file may reach a disk without the application ever copying it there. mount shows whether a swap-backed tmpfs is in play, and other memory filesystems behave differently again. Read the actual mount options rather than assuming a path under /run implies volatility.

Then inventory the things that outlive a reboot in ways people forget: a persistent overlay, attached storage, hibernation images, crash dumps and infrastructure snapshots of the whole VM. Each is a candidate destination for state you believed ephemeral. That list is something to check, not a claim that every host has all of them.

Journald Has Two Destinations and a Forwarder

Journald illustrates the split neatly. Volatile storage keeps entries under /run/log/journal, persistent storage under /var/log/journal, and the automatic mode chooses between them; the mode in force comes from the running system rather than from the image's description. Switching to volatile does not delete what was already written persistently. Forwarding is a separate channel too: even a storage setting that keeps nothing locally can hand messages to another target.

Read the effective mode from the journal itself or its configuration file, then check the forwarding targets separately, because one setting does not control the other.

What Must Survive a Reboot

A stateless runtime supports repeatable replacement, and it needs deliberate sources for the configuration, authorization and recovery material the service cannot invent. Losing the only working enrolment or revocation state in order to make local writes vanish is a bad trade, and a common one. Decide what must survive on purpose, then verify that it does.

The same reasoning applies to operational records. Decide which events security and service management genuinely require, with a justified scope and retention, and minimize the rest. Minimizing is not the same as disabling every diagnostic.

Compare the effective storage and forwarding configuration against a few harmless events, then reboot or replace the machine and check again what remained and where the service recovered its state.