Most "privacy hosting" marketing is noise. Providers slap a padlock icon on their landing page, mention GDPR once or twice, and call it a day. The server you get is identical to what you would get from any commodity provider — same default configurations, same unencrypted DNS resolution through upstream resolvers, same email stack that leaks metadata to anyone watching the wire. The privacy claim evaporates the moment you look at the actual infrastructure.

Real privacy hosting is not a product you buy. It is an architecture you build. The hosting provider gives you the foundation — the jurisdiction, the network, the hardware — but the surveillance resistance comes from how you configure every layer of the stack, from disk encryption at the bottom to DNS resolution at the top. Get one layer wrong and you have created a privacy theatre that protects nothing.

This guide covers how to build a genuinely surveillance-resistant server stack on Swiss infrastructure. Not theoretical. Not aspirational. The actual configurations, the actual trade-offs, and the honest limitations. We will start with why Switzerland specifically — not because we are a Swiss host trying to sell you something (although we are, and we are honest about that), but because the jurisdictional choice is the single most consequential decision you will make for a privacy-focused project, and getting it wrong undermines everything you build on top of it.

Why Swiss Jurisdiction Is the Foundation, Not a Feature

Privacy infrastructure without jurisdictional protection is a sandcastle. You can build the most encrypted, hardened, locked-down server stack in existence, and a single court order from a jurisdiction with weak privacy protections can compel your provider to hand over the keys, image the disks, or install monitoring equipment. The technical controls only matter if the legal framework around them holds.

Switzerland is not in the European Union. It is not a member of the Five Eyes, Nine Eyes, or Fourteen Eyes intelligence-sharing alliances. It has its own surveillance laws — the Federal Intelligence Service Act (Nachrichtendienstgesetz, NDG) — but those laws operate under constraints that are structurally different from those in the US, UK, or most EU member states.

Here is what matters at the operational level:

• No mass surveillance mandate: Swiss law does not require hosting providers to implement blanket data retention or install surveillance capabilities. The NDG allows targeted surveillance, but only with authorisation from the Federal Administrative Court and oversight by an independent authority. There is no Swiss equivalent of FISA Section 702 or the UK's Investigatory Powers Act that compels providers to enable bulk collection.
• Judicial oversight for data requests: Law enforcement access to hosted data requires a court order. Swiss courts apply proportionality analysis — the intrusion into privacy must be proportionate to the severity of the alleged offence. Fishing expeditions do not survive Swiss judicial scrutiny the way they might in jurisdictions with more permissive warrant standards.
• Constitutional privacy protection: Article 13 of the Swiss Federal Constitution guarantees the right to privacy in private life, correspondence, and telecommunications. This is not a statutory right that can be legislated away with a simple parliamentary majority — it is a constitutional guarantee that constrains what the legislature can authorise.
• No foreign government compulsion: A US National Security Letter, a UK Technical Capability Notice, or an EU Production Order cannot compel a Swiss hosting provider to hand over data. Foreign requests must go through Mutual Legal Assistance Treaties (MLATs), which require Swiss judicial approval and are subject to the same proportionality and dual-criminality requirements as domestic requests.

This matters for Swiss VPS and dedicated server customers in a practical way: the legal envelope around your server is not easily pierced by foreign governments, and domestic access requires meaningful judicial process. Compare this to a server in the US, where a National Security Letter can compel disclosure with a gag order preventing the provider from telling you, or a server in the UK, where the Investigatory Powers Act gives agencies sweeping technical access powers.

None of this makes Swiss hosting legally impenetrable. Swiss authorities can and do issue lawful data requests for serious criminal investigations. But the threshold is higher, the oversight is real, and the scope is constrained. For privacy-focused projects operating within the law, this is the strongest jurisdictional foundation available in the Western world.

Layer 1: Full-Disk Encryption with Remote Unlock

The first layer of a surveillance-resistant stack is ensuring that the data on disk is unreadable without your key. If someone physically removes the drive — whether a burglar, a rogue data centre employee, or law enforcement executing an overly broad seizure — they get encrypted blocks. Nothing more.

On a swiss dedicated server, you control the hardware, which means you can implement LUKS full-disk encryption with a remote unlock mechanism that keeps the encryption key off the server entirely:

# Initial setup: encrypt the data partition
cryptsetup luksFormat /dev/sda2 \
  --cipher aes-xts-plain64 \
  --key-size 512 \
  --hash sha512 \
  --iter-time 5000

# Add a key slot for remote unlock via SSH during boot
cryptsetup luksAddKey /dev/sda2

# Configure dropbear SSH in initramfs for remote unlock
apt install dropbear-initramfs

# /etc/dropbear/initramfs/dropbear.conf
DROPBEAR_OPTIONS="-p 2222 -s -j -k"

# /etc/initramfs-tools/initramfs.conf
IP=::::::off

# Rebuild initramfs
update-initramfs -u

With this configuration, when the server boots, it starts a minimal SSH server (dropbear) before the root filesystem is mounted. You SSH in on port 2222, provide the LUKS passphrase, and the boot process continues. The passphrase never touches the disk in plaintext. If the server is powered off — whether intentionally or due to a seizure — the data is encrypted and the key exists only in your head (or your key manager).

The trade-off is obvious: the server cannot boot unattended. Every reboot requires your manual intervention to provide the unlock key. For a privacy-critical service, this is a feature, not a bug. Unattended boot with a locally stored key means anyone who can reboot the server can access the data.

For a swiss VPS, full-disk encryption is trickier because you typically do not control the hypervisor layer. The hosting provider can potentially image your virtual disk. This is where jurisdiction matters again — Swiss law constrains when and how a provider can access your data — but the technical limitation is real. On a VPS, you can still encrypt data partitions (not the boot partition) and use application-layer encryption for sensitive data:

# Encrypt a data partition on a VPS
cryptsetup luksFormat /dev/vdb \
  --cipher aes-xts-plain64 \
  --key-size 256

cryptsetup luksOpen /dev/vdb encrypted_data
mkfs.ext4 /dev/mapper/encrypted_data
mount /dev/mapper/encrypted_data /srv/private

# Store application data, databases, and logs here
# The boot partition remains unencrypted but contains
# no sensitive data

If your threat model includes the hosting provider as a potential adversary, you need dedicated hardware, not a VPS. Be honest with yourself about your actual threat model — most privacy projects are protecting against mass surveillance and casual snooping, not a determined state-level actor with physical access to data centre hardware. For that threat model, an encrypted VPS partition with a remote unlock key is adequate.

Layer 2: Encrypted DNS — Stop Leaking Every Query to Upstream

DNS is the most overlooked privacy leak in server infrastructure. Every time your server resolves a domain name — for outbound API calls, package updates, certificate validation, NTP synchronisation — it sends a plaintext DNS query to an upstream resolver. That resolver (typically your hosting provider's, or Google's 8.8.8.8, or Cloudflare's 1.1.1.1) sees every domain your server communicates with. This is metadata, and metadata is surveillance gold.

Running your own recursive DNS resolver eliminates the upstream leak. Your server talks directly to authoritative nameservers, and no single third party sees the full picture of your resolution patterns.

# Install Unbound as a local recursive resolver
apt install unbound unbound-anchor

# /etc/unbound/unbound.conf
server:
    interface: 127.0.0.1
    port: 53
    access-control: 127.0.0.0/8 allow
    access-control: ::1/128 allow

    # Privacy settings
    hide-identity: yes
    hide-version: yes
    harden-glue: yes
    harden-dnssec-stripped: yes
    use-caps-for-id: yes
    qname-minimisation: yes

    # DNSSEC validation
    auto-trust-anchor-file: "/var/lib/unbound/root.key"

    # Performance
    num-threads: 2
    msg-cache-size: 64m
    rrset-cache-size: 128m
    cache-min-ttl: 300
    cache-max-ttl: 86400
    prefetch: yes
    prefetch-key: yes

    # Deny ANY queries (amplification prevention)
    deny-any: yes

    # Logging — minimal for privacy
    verbosity: 0
    log-queries: no
    log-replies: no
    log-local-actions: no

    # Root hints
    root-hints: "/usr/share/dns/root.hints"

Key configuration details that matter for privacy:

• qname-minimisation: Instead of sending the full domain name (mail.example.com) to each nameserver in the resolution chain, Unbound sends only the minimum necessary labels. The root server sees only "com?", the .com TLD server sees only "example.com?", and only the authoritative server for example.com sees the full query. This is RFC 7816 and it dramatically reduces the metadata visible to each nameserver in the chain.
• use-caps-for-id: Randomises the capitalisation of the query name (DNS 0x20 encoding) to make spoofing responses harder. A spoofed response must match the random capitalisation exactly.
• log-queries: no: Your own resolver should not log your own queries. The point is to eliminate the query log, not move it from an upstream provider to your own disk where it can be seized.

Point your server's resolution at the local Unbound instance:

# /etc/resolv.conf (or via systemd-resolved / resolvconf)
nameserver 127.0.0.1

# Prevent NetworkManager or DHCP from overwriting
chattr +i /etc/resolv.conf

For services you expose to the public — a privacy-focused DNS resolver, for example — you can add DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH) frontends:

# Unbound DoT listener
server:
    interface: 0.0.0.0@853
    tls-service-key: "/etc/letsencrypt/live/dns.example.com/privkey.pem"
    tls-service-pem: "/etc/letsencrypt/live/dns.example.com/fullchain.pem"
    tls-port: 853

    # Access control for public DoT
    access-control: 0.0.0.0/0 allow

Running a public DNS resolver is a commitment — you need to handle abuse, rate limiting, and the operational load of serving external queries. But for your own server's resolution, a local Unbound instance is straightforward and eliminates one of the most persistent privacy leaks in any server stack.

Layer 3: Hardened Email — Metadata Protection Is the Hard Part

Self-hosted email on Swiss infrastructure solves the content privacy problem: your emails are stored on disks you control, in a jurisdiction with strong privacy protections, encrypted at rest. What self-hosted email does not solve is the metadata problem — and metadata is often more revealing than content.

Every email you send generates metadata that is visible to the network: sender address, recipient address, timestamp, subject line (in the SMTP envelope headers), originating IP address, and the full chain of mail servers the message passed through. Even with TLS between mail servers (STARTTLS), the metadata is visible to each relay in the chain and to anyone who can observe DNS queries for MX records.

Start with a hardened Postfix configuration that minimises metadata leakage:

# /etc/postfix/main.cf

# TLS — mandatory for outbound, opportunistic for inbound
smtp_tls_security_level = dane
smtp_tls_mandatory_ciphers = high
smtp_dns_support_level = dnssec

smtpd_tls_security_level = may
smtpd_tls_mandatory_ciphers = high
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem
smtpd_tls_mandatory_protocols = >=TLSv1.2
smtpd_tls_protocols = >=TLSv1.2

# Strip internal headers that leak infrastructure details
header_checks = regexp:/etc/postfix/header_checks

# Disable VRFY and EXPN (information disclosure)
disable_vrfy_command = yes

# Rate limiting and abuse prevention
smtpd_client_connection_rate_limit = 10
smtpd_client_message_rate_limit = 30
anvil_rate_time_unit = 60s

# Reject unauthenticated relay
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

# Authentication via Dovecot SASL
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes

# MTA-STS for outbound (enforce TLS with verified certificates)
smtp_tls_policy_maps = socketmap:unix:/var/run/mta-sts/socket:query

The header stripping is critical. By default, Postfix includes Received headers that reveal the internal IP address of the sending client, which client software was used, and the internal hostname of your mail server. Strip these:

# /etc/postfix/header_checks
/^Received:.*with ESMTPSA/    IGNORE
/^X-Originating-IP:/           IGNORE
/^X-Mailer:/                   IGNORE
/^User-Agent:/                 IGNORE
/^Mime-Version:/               IGNORE

Be careful with the Received header stripping — you want to remove headers that reveal your internal infrastructure, but stripping all Received headers can cause deliverability problems because receiving mail servers use them for spam analysis. The regex above targets only the initial submission header (with ESMTPSA) that reveals the client's IP.

For DANE (DNS-based Authentication of Named Entities), you need DNSSEC on your domain and TLSA records that pin the certificate used by your mail server:

# Generate TLSA record for your mail server certificate
# Using selector 1 (SubjectPublicKeyInfo) and matching type 1 (SHA-256)
openssl x509 -in /etc/letsencrypt/live/mail.example.com/cert.pem \
  -noout -pubkey | openssl pkey -pubin -outform DER | sha256sum

# Add to DNS:
# _25._tcp.mail.example.com. IN TLSA 3 1 1 

DANE ensures that outbound email connections verify the receiving server's TLS certificate against a DNSSEC-signed DNS record, preventing man-in-the-middle attacks that strip STARTTLS (the STRIPTLS attack). This is meaningfully stronger than opportunistic TLS, where an attacker can simply downgrade the connection to plaintext by interfering with the STARTTLS negotiation.

The honest limitation: email is fundamentally a federated protocol with metadata exposure baked into its design. You cannot hide who you are emailing or when, because the receiving mail server sees your IP and the sender/recipient addresses. For truly metadata-resistant communication, email is the wrong tool — use Signal, Matrix with Tor routing, or other purpose-built protocols. Self-hosted email on Swiss infrastructure protects your stored emails and gives you jurisdictional protection over your mail server, but it does not solve email's structural metadata problem.

Layer 4: Tor Relay or Exit Node Hosting

Running a Tor relay on Swiss infrastructure is one of the most direct contributions you can make to global privacy infrastructure. Switzerland's legal framework makes it one of the safest jurisdictions for Tor relay operators — Swiss courts have established that operating a Tor relay is not illegal, and the liability framework for infrastructure operators is more favourable than in many other jurisdictions.

There are three types of Tor nodes, each with different risk profiles:

• Guard/middle relays: Forward encrypted Tor traffic between other relays. Your server never sees the content or the destination. The risk profile is very low — you are just forwarding encrypted packets.
• Exit relays: Decrypt the final layer and connect to the destination on behalf of the Tor user. Your server's IP address appears as the source of the connection. This means abuse complaints, copyright notices, and law enforcement requests land on you. The risk is significantly higher.
• Bridge relays: Unlisted entry points that help users in censored countries connect to Tor. Moderate risk — you may draw attention from the censoring government, but your role is limited to relaying encrypted traffic.

For a guard/middle relay on a Swiss dedicated server or high-bandwidth server:

# Install Tor
apt install tor

# /etc/tor/torrc — Middle/Guard Relay Configuration
ORPort 443
ORPort [::]:443

# Relay identification
Nickname YourRelayName
ContactInfo privacy-relay@example.com

# Bandwidth — donate what you can spare
RelayBandwidthRate 50 MBytes
RelayBandwidthBurst 75 MBytes
AccountingStart month 1 00:00
AccountingMax 10 TBytes

# Do NOT run as exit
ExitRelay 0

# Reduced directory connection overload
DirPort 0

# Control port for monitoring (nyx)
ControlPort 9051
HashedControlPassword 

# IPv6 support
ORPort [your-ipv6-address]:443

# Logging
Log notice file /var/log/tor/notices.log

For an exit relay, you need additional precautions:

# /etc/tor/torrc — Exit Relay Configuration
ORPort 443
ExitRelay 1

# Reduced exit policy — avoid common abuse ports
ExitPolicy reject *:25        # SMTP — spam source
ExitPolicy reject *:119       # NNTP
ExitPolicy reject *:135-139   # Windows services
ExitPolicy reject *:445       # Windows SMB
ExitPolicy reject *:563       # NNTP over TLS
ExitPolicy reject *:1214      # P2P
ExitPolicy reject *:4661-4666 # P2P
ExitPolicy reject *:6346-6429 # P2P
ExitPolicy reject *:6699      # P2P
ExitPolicy reject *:6881-6999 # BitTorrent
ExitPolicy accept *:*         # Allow everything else

# DNS caching for exit traffic
DNSPort 5353
AutomapHostsSuffixes .exit,.onion

If you run an exit relay, you need a separate IP address for it — do not share the exit IP with your web server, mail server, or any other service. Abuse complaints will target that IP, and you do not want collateral damage. Set up a dedicated reverse DNS entry that identifies the IP as a Tor exit, and host an informational page explaining what a Tor exit relay is. This reduces the frequency of confused abuse complaints.

Swiss offshore hosting is particularly well-suited for Tor relays because of the legal clarity. In the US, exit relay operators have faced law enforcement pressure despite no clear legal liability. In Germany, police have seized relay operator hardware during investigations. In Switzerland, the legal framework is clearer and the judicial threshold for hardware seizure is higher. This does not make Swiss exit operation risk-free — it makes it the least risky option in a context where some risk is inherent.

Layer 5: Firewall Hardening — Default Deny, Minimal Surface

A surveillance-resistant server has the smallest possible attack surface. Every open port is a potential entry point for exploitation, and every running service is code that might have vulnerabilities. The firewall configuration should enforce a simple principle: deny everything, then explicitly allow only what is needed.

# nftables configuration — /etc/nftables.conf
#!/usr/sbin/nft -f
flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;

        # Allow established/related connections
        ct state established,related accept
        ct state invalid drop

        # Loopback
        iif "lo" accept

        # ICMPv4 — rate limited
        ip protocol icmp icmp type echo-request \
            limit rate 5/second burst 10 packets accept

        # ICMPv6 — required for IPv6 operation
        ip6 nexthdr icmpv6 accept

        # SSH — restricted to management IPs
        tcp dport 22 ip saddr { 198.51.100.0/24 } accept

        # HTTPS (web services)
        tcp dport 443 accept

        # DNS (if running public resolver)
        # tcp dport 853 accept  # DoT
        # udp dport 53 accept   # Standard DNS

        # Mail (if running mail server)
        tcp dport { 25, 465, 993 } accept

        # Tor OR port (if running relay)
        # tcp dport 9001 accept

        # Log and drop everything else
        limit rate 5/minute log prefix "nft-drop: " drop
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;

        # Optional: restrict outbound to prevent
        # data exfiltration if server is compromised
        # ct state new tcp dport { 80, 443, 25, 53, 853, 123 } accept
        # ct state new reject
    }
}

# Anti-spoofing for the public interface
table inet raw {
    chain prerouting {
        type filter hook prerouting priority -300; policy accept;

        # Drop packets with private source IPs on public interface
        iif "eth0" ip saddr { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 } drop

        # Drop invalid TCP flags
        tcp flags & (fin|syn|rst|ack) == 0 drop
        tcp flags & (fin|syn) == fin|syn drop
        tcp flags & (syn|rst) == syn|rst drop
    }
}

Critical details for privacy-focused hardening:

• SSH restricted by source IP: Do not expose SSH to the entire internet. Restrict it to your known management IPs. If you need flexible access, use a VPN or WireGuard tunnel (covered in our WireGuard VPN deployment guide) and restrict SSH to the WireGuard interface.
• Outbound restrictions: Most servers have a permissive outbound policy (allow all). For a privacy-critical server, consider restricting outbound connections to only the ports and destinations your services actually need. If the server is compromised, restrictive outbound rules limit the attacker's ability to exfiltrate data or establish reverse shells.
• Logging the drops: The rate-limited log line at the end of the input chain gives you visibility into what is hitting your firewall without filling your logs with noise. Review these logs regularly — patterns in dropped traffic can indicate reconnaissance or targeted scanning.

Layer 6: Kernel Hardening and System Configuration

The Linux kernel has numerous tunables that affect privacy and security. Most distributions ship with permissive defaults optimised for compatibility, not privacy. Harden these:

# /etc/sysctl.d/99-privacy-hardening.conf

# Network — prevent information leaks and common attacks
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.all.log_martians = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_timestamps = 0

# IPv6 — same treatment
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv6.conf.default.accept_source_route = 0

# Kernel — restrict information disclosure
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
kernel.sysrq = 0
kernel.core_uses_pid = 1
kernel.yama.ptrace_scope = 2

# Filesystem hardening
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
fs.suid_dumpable = 0

# Memory — ASLR
kernel.randomize_va_space = 2

One setting deserves special attention: net.ipv4.tcp_timestamps = 0. TCP timestamps encode the system uptime with millisecond precision, which can be used for OS fingerprinting and to correlate traffic across different connections to the same server. Disabling them eliminates this side-channel at the cost of slightly reduced TCP performance on high-latency, lossy connections. For a privacy-focused server, this is an acceptable trade-off.

Additional system hardening:

# Disable core dumps (prevent memory contents from being written to disk)
echo '* hard core 0' >> /etc/security/limits.conf
echo 'fs.suid_dumpable = 0' >> /etc/sysctl.d/99-privacy-hardening.conf

# Restrict /proc visibility (hide other users' processes)
# /etc/fstab
proc    /proc    proc    defaults,hidepid=2,gid=adm    0    0

# Secure shared memory
# /etc/fstab
tmpfs   /run/shm   tmpfs   defaults,noexec,nosuid,nodev   0   0

# Disable USB storage (if not needed — prevents physical exfiltration)
echo "install usb-storage /bin/true" > /etc/modprobe.d/disable-usb-storage.conf

# AppArmor — enforce on all profiles
aa-enforce /etc/apparmor.d/*

The hidepid=2 mount option for /proc is underappreciated. Without it, any user on the system can see every running process, including command-line arguments that might contain API keys, file paths, or other sensitive information. With hidepid=2, users can only see their own processes. This matters on multi-user systems, but it is good hygiene even on single-purpose servers — if an attacker gains access as an unprivileged user, they should learn as little as possible about what else is running.

Layer 7: Secure Remote Access — WireGuard and SSH Hardening

Your administrative access to the server is the highest-value target for any attacker. If they compromise your SSH session, they own everything. The access channel must be as hardened as the services it manages.

# /etc/ssh/sshd_config — hardened for privacy server

Port 22
AddressFamily inet
ListenAddress 10.0.0.1  # Only listen on WireGuard interface

# Authentication
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
AuthenticationMethods publickey
MaxAuthTries 3
MaxSessions 2
LoginGraceTime 30

# Cryptography — restrict to modern algorithms
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com

# Disable unnecessary features
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no
PermitUserEnvironment no
PrintMotd no

# Session security
ClientAliveInterval 300
ClientAliveCountMax 2

# Logging
LogLevel VERBOSE

The key line is ListenAddress 10.0.0.1 — SSH is not exposed on the public interface at all. You access it through a WireGuard VPN tunnel, which means an attacker cannot even attempt SSH authentication unless they first compromise the WireGuard connection. WireGuard's authenticated encryption (using Noise protocol framework) and minimal attack surface make it an excellent access layer.

For the cryptography choices: sntrup761x25519-sha512 is a hybrid post-quantum key exchange that combines classical elliptic-curve Diffie-Hellman with a post-quantum lattice-based algorithm. This provides protection against a future quantum computer that could break the elliptic-curve portion. Whether quantum computers will threaten current cryptography in our lifetimes is debatable, but the performance cost of the hybrid key exchange is negligible, so there is no reason not to use it.

Layer 8: Logging Strategy — Know What Happened Without Creating a Liability

This is where privacy infrastructure gets philosophically interesting. You need logs to detect intrusion, diagnose problems, and maintain your systems. But logs are also evidence — they can be seized, subpoenaed, or compelled through court orders. Every log entry you keep is a potential data point that could be used against your users.

The surveillance-resistant approach is minimal, need-to-know logging:

# /etc/rsyslog.d/50-minimal.conf

# Keep system logs for operational needs, but minimise retention
# Auth logs — needed for intrusion detection
auth,authpriv.*         /var/log/auth.log

# Kernel messages — needed for hardware/security issues
kern.*                  /var/log/kern.log

# Critical system messages only
*.emerg                 /var/log/emergency.log

# Drop everything else
*.*                     ~

# Retention — automatic deletion
# /etc/logrotate.d/privacy
/var/log/auth.log
/var/log/kern.log
/var/log/emergency.log
{
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 0640 root adm
    sharedscripts
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

Seven days of retention. After that, logs are overwritten. This gives you enough operational history to detect and investigate intrusions while limiting the historical record available to anyone who gains access to the server — whether an attacker or a government agency with a court order.

For web server logs, the same principle applies — log enough to detect attacks, but do not log identifying information about legitimate users:

# Nginx — privacy-focused logging
# Anonymise IP addresses by zeroing the last octet
map $remote_addr $anonymised_addr {
    ~(?P\d+\.\d+\.\d+)\.\d+    $ip.0;
    ~(?P[^:]+:[^:]+):          $ip::;
    default                         0.0.0.0;
}

# Minimal log format — no user agent, no referrer
log_format privacy '$anonymised_addr - [$time_local] '
                   '"$request" $status $body_bytes_sent';

access_log /var/log/nginx/access.log privacy;

# Alternatively, disable access logging entirely
# access_log off;

The IP anonymisation replaces the last octet with zero (192.168.1.42 becomes 192.168.1.0), which retains enough information to identify attack patterns from a /24 subnet without recording specific client IPs. For maximum privacy, disable access logging entirely — but this makes web application debugging and abuse detection significantly harder.

Layer 9: Automated Security Updates and Integrity Monitoring

A hardened server that is not updated is a time bomb. Vulnerabilities are discovered constantly, and a privacy-focused server running six-month-old packages is easier to compromise than an unhardened server running yesterday's patches.

# Unattended security updates — Debian/Ubuntu
apt install unattended-upgrades

# /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::AutoFixInterruptedDpkg "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Automatic-Reboot "false";
# Manual reboot — you want to unlock LUKS manually after reboot

# Verify unattended-upgrades is active
systemctl enable unattended-upgrades
systemctl start unattended-upgrades

Notice Automatic-Reboot "false". On a server with LUKS full-disk encryption and remote unlock, an automatic reboot means the server goes down and stays down until you manually provide the unlock key. Automatic reboots in the middle of the night would create availability holes. Schedule reboots manually during your maintenance windows, and unlock immediately after.

For integrity monitoring, AIDE (Advanced Intrusion Detection Environment) creates a baseline database of file checksums and alerts you when files change unexpectedly:

# Install and initialise AIDE
apt install aide

# Create initial database
aideinit

# Move the new database into place
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# /etc/aide/aide.conf — key directories to monitor
/etc        Full
/bin        Full
/sbin       Full
/usr/bin    Full
/usr/sbin   Full
/lib        Full
/boot       Full

# Exclude directories with expected changes
!/var/log
!/var/cache
!/var/spool
!/tmp
!/run

# Run daily check
# /etc/cron.daily/aide-check
#!/bin/bash
aide --check 2>&1 | mail -s "AIDE integrity report" admin@example.com

If AIDE reports unexpected changes to system binaries, configuration files, or boot components, someone or something has modified your system. Investigate immediately — it could be a legitimate update (check the timing against your unattended-upgrades log) or an indicator of compromise.

Putting It All Together: The Complete Stack

A surveillance-resistant server stack on Swiss infrastructure looks like this, from bottom to top:

• Jurisdiction: Swiss law, constitutional privacy protections, no mass surveillance mandates, judicial oversight for data access, no foreign government compulsion
• Hardware: Dedicated server (for full hardware control) or VPS (acceptable for lower threat models), preferably with ECC memory and hardware entropy sources
• Disk: LUKS full-disk encryption with remote unlock via dropbear-initramfs. Encryption key never stored on disk.
• Kernel: Hardened sysctl settings. TCP timestamps disabled. ASLR enabled. ptrace restricted. dmesg restricted. /proc hidepid=2.
• Network: nftables with default-deny policy. SSH on WireGuard interface only. Outbound restrictions where practical.
• DNS: Local Unbound recursive resolver with QNAME minimisation and DNSSEC. No upstream resolver leaks.
• Email: Postfix with mandatory TLS (DANE), header stripping, MTA-STS. Honest about metadata limitations.
• Access: SSH via WireGuard only. Key-based auth. Post-quantum key exchange. No root login.
• Monitoring: AIDE file integrity monitoring. Minimal logging with 7-day retention. IP anonymisation in web logs.
• Updates: Unattended security updates. No automatic reboot (LUKS manual unlock required).

The Honest Limitations

No infrastructure is perfectly surveillance-resistant. Here are the honest limitations of this approach:

• Traffic analysis: Even with encrypted connections, an observer at the network level can see the volume, timing, and destination IPs of your traffic. Tor mitigates this for traffic that passes through the Tor network, but your server's non-Tor traffic (updates, DNS to authoritative servers, direct SMTP connections) is visible at the network layer.
• Provider trust: On a VPS, the hypervisor has technical access to your VM's memory and virtual disks. On a dedicated server, the provider has physical access to the hardware. Swiss law constrains when and how they can exercise this access, but the technical capability exists. Zero-trust hosting — where even the provider cannot access your data — requires homomorphic encryption or secure enclaves, and those technologies are not production-ready for general server workloads.
• Endpoint compromise: If your local machine — the one you use to SSH into the server — is compromised, your server is compromised. All the server hardening in the world does not matter if the attacker is watching your SSH session from your own laptop.
• Swiss law enforcement: Swiss authorities can, with proper judicial authorisation, compel disclosure of data for serious criminal investigations. The threshold is higher than in many jurisdictions, but it exists. Switzerland is not a lawless zone — it is a jurisdiction with strong rule of law that includes meaningful privacy protections within that legal framework.
• Supply chain: Your server runs on hardware and software built by third parties. Firmware-level compromises, hardware implants, or compiler backdoors are theoretical threats that no server configuration can mitigate. These are state-level threats that only a small number of targets need to worry about, but intellectual honesty requires acknowledging they exist.

The goal of a surveillance-resistant stack is not perfection. It is raising the cost and difficulty of surveillance to the point where mass collection is infeasible, targeted collection requires meaningful judicial oversight, and the technical controls provide genuine protection against the most common threat models: bulk metadata collection, opportunistic snooping, and data seizure without proper legal process.

Swiss privacy hosting combined with disciplined operational security gives you the strongest available foundation for that goal. The jurisdiction provides the legal shield. The technical stack provides the engineering. Together, they create infrastructure where privacy is not a marketing claim — it is an architecture you can verify, audit, and defend.

If you are evaluating Swiss VPS or GPU-equipped infrastructure for a privacy-sensitive project, the jurisdiction is the part you cannot replicate with configuration files. Everything else in this guide can be built on any Linux server. The Swiss legal framework around it is what makes the difference between a hardened server and a genuinely privacy-protected one.