Forwarder Deployment

The Stairwell forwarder is a service you install on a machine so that machine's executables and scripts are collected into Stairwell and kept. It registers with your environment, inventories what is already on disk, then watches for new file activity and reports what it sees. It collects and uploads. It does not block, quarantine, or sit in the path of anything, so a forwarder cannot break an application by refusing it.

This section is the rollout, in the order the work actually happens: check the network, decide what you are collecting and what you are not, set up the groups that will carry those decisions, then install.

What does the forwarder collect?

Executables and scripts, not every file. The default collection list is roughly 65 file formats, in two categories you can see in the product: Executables and Binary Code (.exe, .dll, .sys, .drv, .efi, .so, .dylib, .elf, .msi, .pkg, .dmg, .lnk, the Java .war and .ear packages, browser extensions, and more) and Scripts and Bytecode (.ps1, .bat, .cmd, .sh, .zsh, .py, .rb, .pl, .lua, .php, .jar, .vbs, .wsf, the ASP.NET and JSP families, WebAssembly, and Node modules).

That set is a default, not a fixed policy. You tune it in three ways, and all three are covered in this section:

• Add file types. A policy has a Custom extension category for formats you want collected that are not in the default list.
• Exclude by path. Exclusions tell the forwarder to skip files matching a path glob.
• Exclude by filename or path expression on the server. Intake filters reject a file at upload no matter which forwarder, API call, or manual upload sent it.

Documents, images, spreadsheets, and media are not on the default list. If you are trying to work out what a given machine will contribute, the useful mental model is "the software on it", not "the files on it".

What happens when I install one?

Four things, in this order. Knowing the order is what makes the first week predictable.

1. Registration. The forwarder authenticates with the environment ID and token you gave the installer, and the machine appears in Stairwell as an asset. See Assets.
2. The initial backscan. The forwarder walks the disk and reports every collectible file it finds. This is the resource-intensive part of a deployment, and it happens once per machine.
3. Real-time collection. From then on the forwarder reports files as they are created, modified, or executed, rather than rescanning.
4. Deduplication. Before uploading a file, the forwarder asks whether Stairwell already holds it. If it does, no upload happens and Stairwell records a sighting instead: this file, on this asset, at this path, at this time.

Point four is why deployment order matters, and it is the single biggest lever you have over how much a rollout costs you.

In what order should I deploy?

From the machine that teaches Stairwell the most about your software, outward to the machines that will then have almost nothing new to say.

1. A golden image or a lab machine. Your standard build. This one upload covers the operating system, the approved applications, and the common frameworks that every other machine in your fleet also has. Every deployment after it finds fewer unique files.
2. File servers. Wide file coverage, and files that live on shared storage rather than on any endpoint. Deploy on the server itself. A forwarder on a client machine is not the way to collect what is on a share that client mounts.
3. Cohorts of similar machines. All the finance workstations, then all the legal workstations, then all the engineering workstations. Machines in a cohort share most of their software, so the first few in each cohort do the work and the rest are cheap. Batching this way also means that if one cohort has a connectivity or policy problem, you find it while it is still one cohort.
4. High-churn and sensitive systems last. Developer workstations, build servers, and container hosts. Before you install on these, sit with the team that owns them and identify the build output directories and package caches worth excluding. Recommended Exclusions is the starting list, and Exclusions explains how to keep those exclusions narrow enough that you are not also excluding the place an attacker would stage a payload.

Upload volume is heaviest at the start and falls as you go. If you deploy in a random order you pay the same total, spread unpredictably across the fleet and across your change windows.

What do I do before the first install?

Three things, and skipping any of them is how a rollout turns into a support ticket.

• Run the network checks. Pre-Deployment Check takes two commands on one machine and catches the failure that looks like success: an install that completes, a forwarder that registers, and no file data arriving because something in the middle is terminating TLS. Connectivity Requirements is the list of what has to be reachable.
• Decide what you are not collecting. For a general workstation fleet the default is usually right and you can move on. For developer machines, build systems, container hosts, and database servers, decide before the install rather than after, because the initial backscan is the moment those paths cost the most.
• Create the group and the policy first. A policy is attached to a group, and a group is what lets you change collection for a set of machines in one edit instead of per host. See Groups and Policies.

How do I know a deployment worked?

An install that reports success proves the installer ran. It does not prove collection is happening. Check, in this order:

1. The machine appears under Assets with a recent check-in.
2. Sightings start arriving for it. This is the step that proves the intake path is being used and not merely reachable.
3. The asset is in the environment you intended. See Environments.
4. The policy you meant to apply is the one applied, and the backscan status is progressing rather than failed.

If the asset registers and no sightings follow, that is a network result rather than an install result almost every time, and Pre-Deployment Check run from that machine's network will say which one.

What should I read next?

• Connectivity Requirements, for the hostnames and ports to allow before you touch a host.
• Groups and Policies, for how collection decisions are carried to a set of machines.
• Forwarder Downloads, for the current package for each operating system and its compatibility.
• How Stairwell Works, if you inherited this rollout and want to know what the files you are about to collect are for.