Forwarder Performance Tuning

Steady-state impact is close to nothing. The forwarder reacts to new and modified files, and that is cheap.

The cost is the one-time backscan, which walks the file system on first install and uploads what Stairwell has not seen in your environment before. Nearly everything on this page is about that phase, and the single most effective lever is not a setting at all: it is the order you deploy in.

What does a backscan actually cost?

• CPU stays low. The forwarder is I/O-bound rather than CPU-bound, which is why lowering CPULIMIT mostly extends the backscan rather than relieving the machine. See Windows Install Parameters.
• Disk read is elevated for the duration. A standard endpoint takes 2 to 8 hours. A dense file server takes longer.
• Upload depends on novelty, not disk size. Stairwell deduplicates across your environment, so a machine whose files are already known uploads very little. This is why the tenth machine of a given type costs far less than the first.
• Then it stops. Usage drops to near zero once the backscan finishes.

The practical version: your first few installs are expensive and every later one is cheaper, so the way to make a rollout feel light is to sequence it rather than to throttle it.

Deploy in this order

The sequence below minimizes total upload and makes each wave cheaper than the last.

1. A golden image or lab machine. This teaches Stairwell your standard software stack, and every subsequent deployment skips uploading anything already known from it. Doing this first is the highest-leverage step on this page.
2. File servers and shared drives. They cover a lot of file variety quickly. Instrument them directly: the forwarder ignores mapped network drives on individual endpoints, so a file server reached only through mappings is not covered by the machines that mount it.
3. Similar endpoints in cohorts. All finance workstations, then all engineering workstations. Machines that resemble each other share most of their files, so each batch reduces the burden of the next.
4. High-churn and sensitive systems last, with exclusions already configured.

See Asset Deployment Strategy for the same sequence with more on communicating it.

Excluding directories

Excluding a path stops collection there entirely: nothing uploaded, nothing scanned. Reasonable candidates:

• Build output directories, node_modules, Maven and Gradle caches
• Media and asset libraries
• Backup staging directories
• Virtual machine disk images
• Log directories holding only text

An exclusion is a permanent blind spot, so be specific. A file that was never collected has no verdict, no variants, and can never match a YARA rule written later, including one written next year about something nobody has heard of yet. Exclude directories where you are confident no security-relevant executable will be written, and resist broad strokes.

Configure these under Settings → Policies → Exclusions and apply them by policy. See Exclusions and Recommended Exclusions.

Developer machines

These are the hard case, for two reasons that compound. They generate new files continuously, and their owners notice anything that makes builds slower.

1. Agree the exclusions before you deploy, with the development team. Build output directories and package caches, in a developer-specific policy.
2. Pilot with two or three volunteers who will tell you honestly what they observe, and adjust before the wider rollout.
3. Say what to expect. A developer machine with years of accumulated build artifacts takes longer to backscan than a standard endpoint. Communicated in advance this is a fact; discovered on the day it is a complaint.
4. Package manager caches (npm, pip, Maven, NuGet, Cargo) are usually safe to exclude, since they hold known upstream packages rather than anything built internally. Check with your security team rather than assuming.

Worth noting what you give up in step 4. A compromised package in a cache is exactly the sort of thing a supply chain investigation looks for. See A Vendor in Your Supply Chain Got Breached before excluding caches on machines that build shipping software.

Watching a rollout

Three indicators, all in the platform:

• Check-in rate. Every deployed asset should show a recent last-seen. A stale one is a connectivity or service problem, not a slow backscan. See What to Check First.
• Sighting volume. Elevated during backscan, tapering to a baseline afterwards. That taper is how you know a wave has finished.
• Backscan status, per asset, in the platform or from the local state file on the machine. See Linux Troubleshooting or Windows Troubleshooting.

What should I read next?

• Antivirus Exclusions, which is the first thing to check on a loaded Windows fleet.
• Forwarder Throttles, for capping resource use directly.
• Asset Deployment Strategy, for the rollout sequence in full.