Security & privacy

PCAPNG Analyzer processes and stores packet captures on the server you control. Capture data and analysis results are not uploaded to us.

What stays on your server

Uploads, decoded packet data, aggregate reports, annotations and exports are handled by your own instance. By default, persistent application data lives under PCAP_DATA_DIR—/data in the container image—including:

• The SQLite analysis database
• Stored capture files in the uploads directory
• Application logs
• Local authentication and configuration data

You control the host, Docker volume, backups, retention and access to that storage. PCAPNG Analyzer does not copy this data to a hosted analysis service.

Network activity at a glance

The license-status check

A Free instance can run without a license key. When licensing is not configured, the background license-validation task does not run.

If you enter a Pro key, the application contacts the configured Keygen licensing service:

• When the key is first entered
• During periodic revalidation—every 24 hours by default
• When an administrator selects Recheck now

The request contains the license key and a product/version identifier. It does not contain the capture filename, capture contents, decoded packets, report data or user annotations. As with any outbound HTTPS connection, the remote service receives ordinary connection metadata such as the connecting server's IP address.

If the licensing service is temporarily unreachable, a valid Pro instance keeps its entitlements during the configured offline grace period—14 days by default. Operators with restricted egress can route the request through an HTTPS proxy.

Authentication

Single-instance mode

A new deployment requires an administrator-supplied bootstrap password of at least 12 characters and forces a change at first sign-in. Passwords are hashed with Argon2. Sessions use cryptographically random identifiers stored in HttpOnly, SameSite cookies. Changing or administratively resetting the password revokes existing sessions.

Multi-user proxy mode

Pro can delegate authentication to a trusted reverse proxy. In this mode, the proxy supplies the authenticated username and the app scopes user-owned uploads and results accordingly. The application port must remain unreachable to untrusted clients so they cannot forge identity headers. An additional shared proxy secret is available as defence in depth.

HTTPS and network exposure

The application serves HTTP inside the deployment and does not terminate TLS itself. Use a trusted reverse proxy such as Caddy or nginx for HTTPS, expose only ports 80 and 443, and keep the application port on an internal Docker network. The self-hosting guide provides a Caddy configuration that follows this layout.

Storage, backups and encryption

Self-hosting gives you control of storage, but it also makes storage protection your responsibility. Use host or volume encryption if you require encryption at rest. Restrict access to the Docker host and backup destination, and protect backups as carefully as the live capture volume.

Packet captures may contain internal addresses, hostnames, credentials or application payloads. Only give instance and backup access to people who are authorised to inspect that traffic.

Operational safeguards

The application supports upload-rate limits, login-rate limits, file-size and batch limits, disk-usage limits, packet-count limits, parse timeouts and a global analysis-worker ceiling. These controls reduce accidental or malicious resource exhaustion, but they do not replace host monitoring, firewalling, patching and capacity planning.

Security questions

To report a security concern or ask about a deployment, email [email protected]. Do not include packet captures, credentials or sensitive payloads in an initial email.