How to Make Your VPS Keep No Logs (Hardening Guide)

Difficulty: Intermediate 8 min read Updated: 18.07.2026 13
How to Make Your VPS Keep No Logs (Hardening Guide)
When you run your own VPN, the privacy win is that no company logs your traffic. But a default Linux server still keeps its own records - system logs, SSH login history, shell history. This guide trims a VPS down to a genuine no-logs setup, step by step, and stays honest about the limits.

What actually gets logged on a server

The appeal of running your own VPN is simple: no company is sitting between you and the internet writing down what you do. But a stock Linux server still keeps records of its own, and if you want a genuine no-logs setup you need to know what those are:

  • WireGuard itself keeps no traffic log. By default it writes nothing about your connections to disk. It only holds the latest handshake time and your current endpoint in memory, which you see with wg show - and that is wiped on reboot. So the VPN layer is already clean.
  • The operating system is the noisy part. systemd's journal (journald) records service events. If rsyslog is installed it also writes plain-text files like /var/log/syslog and /var/log/auth.log - and auth.log records every single SSH login. Separate files (wtmp, btmp, lastlog) track who logged in and when, and your shell keeps a ~/.bash_history.
  • And a few quieter paths to disk. If the server has swap turned on, the kernel can spill pages of RAM - keys included - onto the disk. A crashing program can leave a core dump of its memory. And the package manager writes update logs under /var/log/apt. A thorough setup closes these too.
This guide assumes a fresh Ubuntu 22.04 or 24.04 server, and that you already set up WireGuard (see our guide How to set up your own WireGuard VPN on a VPS). Run everything below as root.

The honest limit: what no-logs can and cannot do

Before touching anything, be clear about what you are actually buying. Turning off logs stops your own server from keeping records - so if the disk is ever seized, imaged, or read by someone who gets in, there is far less to find. That is a real, worthwhile gain.

What it does not do is hide you from the company that rents you the server. Your VPS provider always knows a machine exists at that IP, can see how much bandwidth it moves, and could in principle observe traffic at the network or hypervisor level - no setting inside your server changes that. No-logs is about minimizing your own footprint, not about becoming invisible to the host. Choose a provider you are comfortable with, and treat the steps below as reducing risk, not erasing it.

No-logs is not a guarantee of anonymity. Two limits no server setting can change:

  • Your provider sees the connecting IPs. The content is encrypted, but they can see that your home IP reached the WireGuard port, and when.
  • Your provider can snapshot the RAM. A VPS is a virtual machine; the host controls the hypervisor and can capture live memory (the active WireGuard keys and connected peers) and can be compelled to hand it to the police on a valid legal request.

Bottom line: you own the software, not the machine. No-logs lowers your risk, it does not erase it.

What about a dedicated (bare-metal) server? It removes the hypervisor, so there is no silent one-command memory dump - a genuine improvement. But it is still not a guarantee: the provider owns the physical machine and the network. It still sees the connecting IPs, and because it has physical access plus out-of-band management (IPMI / BMC, a separate controller with its own network link), the running RAM can still be reached - for example through a cold-boot or DMA attack. A dedicated server raises the effort, it does not remove the need to trust your host.

Step 1: Move the systemd journal into RAM

First, tell journald to keep its journal in memory only, so it never lands on the disk and disappears on every reboot. Open its config:

nano /etc/systemd/journald.conf

Under the [Journal] section, set these two lines (remove the leading # if present):

[Journal]
Storage=volatile
RuntimeMaxUse=16M

Apply it and the journal now lives in /run (RAM), capped at 16 MB and gone on reboot:

systemctl restart systemd-journald

Step 2: Put all of /var/log in RAM

The journal is now in memory, but several tools still drop plain-text files into /var/log - rsyslog, the auth.log that records SSH logins, the apt update logs, and the wtmp/btmp/lastlog login records (which keep being rewritten on every login, so simply deleting them does nothing). The clean, catch-all fix is to mount the whole /var/log directory as a tmpfs - a RAM-backed filesystem that is wiped on every reboot. Add one line to /etc/fstab:

echo "tmpfs /var/log tmpfs defaults,noatime,nosuid,nodev,mode=0755,size=50M 0 0" >> /etc/fstab

Now everything under /var/log lives in memory and empties on every reboot. Reboot once so running services reopen their log files inside the new RAM disk:

reboot
One caveat: because /var/log is wiped on reboot, any software you add later that expects its own log subfolder (a web server, for example) may need that folder recreated. For a machine that only runs your VPN this is not an issue.

Step 3: Turn off swap

If the server has swap enabled, the kernel can push pages of RAM - possibly including live keys - onto the disk when memory runs low. On a no-logs box you want memory to stay in memory. Turn swap off now and keep it off across reboots:

swapoff -a
sed -i.bak '/\sswap\s/s/^/#/' /etc/fstab

Many small VPS ship without any swap at all - in that case swapoff -a simply does nothing, which is fine.

Step 4: Turn off core dumps

If a program crashes, systemd-coredump can write a core dump - a snapshot of that program's memory - to disk under /var/lib/systemd/coredump/. Switch it off:

mkdir -p /etc/systemd/coredump.conf.d
printf '[Coredump]Storage=none' > /etc/systemd/coredump.conf.d/99-nolog.conf
systemctl daemon-reload

Step 5: Turn off shell and editor history

Your shell saves every command to ~/.bash_history, and editors leave their own trails (~/.viminfo, ~/.lesshst). Point them all at /dev/null so nothing is ever written. For the current user:

ln -sf /dev/null ~/.bash_history
ln -sf /dev/null ~/.viminfo
ln -sf /dev/null ~/.lesshst

Then stop bash from keeping a history file for every login shell on the system, so other accounts are covered too:

printf 'unset HISTFILEexport HISTSIZE=0' > /etc/profile.d/00-nohistory.sh

If you have other user accounts, repeat the three ln -sf lines for each of their home directories as well.

Step 6: Keep intrusion protection on - you are not blind

A common myth is that turning off logs leaves you defenceless. It does not have to. fail2ban - the tool that bans an IP after repeated failed logins - can read straight from the systemd journal, which now lives in RAM. So you keep automatic brute-force protection while still writing nothing to disk. Install it:

apt install fail2ban -y

Point it at the journal by creating /etc/fail2ban/jail.local with:

[DEFAULT]
backend = systemd

Then restart it and, on top of that, close the obvious doors:

systemctl restart fail2ban
  • SSH keys only. Disable password login in /etc/ssh/sshd_config (PasswordAuthentication no) and restart ssh. A key cannot be guessed the way a password can.
  • Firewall closed by default. Keep ufw allowing only SSH and your WireGuard port (51820/udp), everything else denied.
  • Automatic security updates. Install unattended-upgrades; its logs now live in the RAM-backed /var/log, so they vanish on reboot too.
Order matters: get key-based SSH working and tested in a second terminal before you tighten anything. If you lock yourself out, you now have very few logs to debug with.

Step 7: Verify nothing persists

Reboot one more time, log back in, and check the four things you changed:

mount | grep /var/log
swapon --show
journalctl --no-pager | wc -l
ls -lh /var/log

You should see /var/log mounted as tmpfs, no active swap, a nearly empty journal, and a fresh, almost empty /var/log. From here on the server keeps essentially nothing on disk about what passes through it.

When you might want to keep some logs

No-logs is not automatically right for everyone. If the server does more than run your personal VPN - hosts a site, handles other people's traffic - you may want a little history to spot problems. Good news: the setup above already keeps short-term logs in RAM (in the journal and the tmpfs /var/log), so you get same-session visibility while still writing nothing permanent to disk. If you need more, raise RuntimeMaxUse in Step 1 or the tmpfs size in Step 2. Match the aggressiveness to how you actually use the box.

Tags: vps no logs privacy hardening self-hosted wireguard linux anonymity