How to automate PCAP analysis with a watched folder

A watched folder turns “someone should upload this capture” into a repeatable handoff: a new PCAP or PCAPNG file appears in a mounted directory and is queued for analysis automatically.

1. Decide what the folder means

Use the watched directory as an intake boundary, not as your only archive. Give files names that preserve source and time, for example branch-07-wan-20260925T140000Z.pcapng. Keep the original capture and collection metadata according to your retention policy.

The watcher responds to new .pcap and .pcapng files in one directory. It is not a recursive evidence-management system, packet sensor or scheduled capture service. Another tool still has to create or deliver each capture.

2. Bind-mount a host directory into the container

Create an intake directory on the Docker host and restrict who can write to it:

sudo mkdir -p /srv/pcap-intake
sudo chown root:root /srv/pcap-intake
sudo chmod 750 /srv/pcap-intake

Add the bind mount to the pcapng-analyzer service in your Compose file:

services:
  pcapng-analyzer:
    image: smathieson/pcapng-analyzer:latest
    volumes:
      - pcap-data:/data
      - /srv/pcap-intake:/watch

Recreate the service after editing Compose:

docker compose up -d

The application sees the directory as /watch. Enter the container path, not /srv/pcap-intake, in the application settings.

3. Enable the folder monitor

1. Open Settings → Detection Rules → Folder Monitor.
2. Enable auto-analysis.
3. Set the watch folder path to /watch.
4. Select Apply and confirm the status shows Watching.
5. Copy a small test capture into /srv/pcap-intake and confirm it appears in History.

The application waits for a new file to stop changing before it queues analysis. That protects against ordinary copy operations, but producers should still use a clean handoff pattern.

4. Use a safe producer pattern

Write or transfer the capture outside the watched directory, close it, then move the completed file into the intake directory. A rename on the same local filesystem is usually atomic:

dumpcap -i eth0 -a duration:300 -w /srv/pcap-staging/capture.pcapng
mv /srv/pcap-staging/capture.pcapng /srv/pcap-intake/

Operational checks matter more than the happy path:

• Monitor available space for both the intake directory and the persistent /data volume.
• Set file-size, packet-count, parse-time and disk-usage limits appropriate to the host.
• Watch container logs for rejected, unreadable or oversized captures.
• Define when original intake files are archived or removed. The app's stored copy is not a substitute for an evidence policy.
• Test the workflow after container, filesystem or permissions changes.

5. Control load and retention

Automation can create resource pressure faster than manual upload. A burst of large files competes for parsing workers and storage. PCAPNG Analyzer applies configured file-size, batch, disk, packet and parse-time limits, plus a process-wide analysis-worker ceiling. Tune these to the server instead of assuming defaults fit every capture source.

Pro keeps unlimited analysis history, but disk remains finite. Decide whether History is an operational queue, a short-term library or a long-term record, then align backups and deletion with that purpose.

When a watched folder is the wrong tool

• Use manual upload for occasional captures where an analyst should review sensitivity first.
• Use batch upload when a person has a known set of up to 20 files.
• Use tshark or a dedicated pipeline when you need arbitrary scripted fields, streaming processing or integration with a message queue.
• Use a packet sensor or capture appliance when you need continuous collection. PCAPNG Analyzer does not capture traffic itself.

Manual handoff vs watched folder