Zero-Log Architecture for Tor Hidden Services: 2026 Guide

Logs serve legitimate operational purposes: debugging failures, detecting attacks, monitoring performance. For privacy-focused hidden services, logs also create risks: a server seizure yields user behavior data from access logs, error logs may reveal user-provided data (email addresses, usernames in error messages), and timing logs can correlate with Tor circuit timing analysis. The approach: minimize what is logged, shorten retention windows, and anonymize what must be retained. Do not eliminate all logging - blind operation without any monitoring leads to undetected failures. Calibrate retention to the minimum operationally useful period.

Standard Nginx access logs record: client IP (useless for .onion, all are local loopback), timestamp, request line (URL path, query string), response code, bytes transferred, referrer, and user agent. For .onion services, the client IP is always 127.0.0.1 (Tor routes locally), making IP logging meaningless. Disable access logging entirely: access_log off; in the Nginx server block. Alternatively, log only non-identifying data: log_format privacy '$request_time $status $body_bytes_sent'; access_log /var/log/nginx/access.log privacy; This retains timing and status (useful for performance monitoring and error detection) without URLs (which may contain user-identifiable query parameters) or user agents (fingerprinting vector). Error logging: error_log /var/log/nginx/error.log warn; logs only warnings and above (not verbose debug information).

Tor logs at multiple verbosity levels. For production hidden services: Log warn file /var/log/tor/log minimizes logging to warnings and errors only. This hides: circuit establishment timing, introduction point selection details, relay connection events, and normal operational messages. What remains: actual errors (configuration problems, key issues, network failures) - necessary for operational awareness. Log rotation: configure logrotate for /var/log/tor/log with daily rotation and 7-day retention. Avoid logging to RAM (tmpfs /var/log) for Tor - if the service crashes, logs written to RAM are lost, making post-crash debugging impossible. Keep a minimal rotating log on disk, purge after 7 days.

Application logs are the highest-risk category for user data exposure. Audit all log statements in your application code. Remove: logs that record email addresses or usernames, logs that record user-provided content, logs that record IP addresses (useless for .onion anyway), and verbose debugging logs left from development. Keep: error logs (exceptions, unhandled errors), performance metrics (response time percentiles), and aggregate statistics (total requests per minute, not per-user). Framework-level: Django: configure LOGGING in settings to exclude user data from log formatters. Express/Node.js: disable morgan access logging or use a custom format that omits paths with user data. PHP: log_errors=On but error_log=/var/log/php/errors.log with scrubbed output. Structured logging: if using a structured logging framework (Pino, Structlog), define explicit field allowlists and reject all fields not in the allowlist.

Retention policy: establish explicit maximum retention windows for each log type. Recommendation: Nginx error logs - 7 days. Tor logs - 7 days. Application error logs - 30 days. Security/audit logs (authentication events, privilege escalation) - 90 days (balance privacy vs security audit need). Authentication failure logs - 30 days (needed for fail2ban and security monitoring). Automated purging: cron jobs enforce retention. Example: 0 3 * * * find /var/log/nginx/ -name '*.log.*' -mtime +7 -delete for 7-day Nginx log retention. Tmpfs for short-lived logs: if a specific log type is needed only for same-day debugging, mount /var/log/volatile as tmpfs (logs in RAM, automatically purged on reboot). Incident response: if a security incident requires post-hoc analysis, document what logs existed and their content within the retention window, then securely purge after the analysis is complete.