The TigerGate Agent is one binary per platform. On a server it is installed with the server profile (--profile infra), which reports to Infra Vulnerabilities and skips the developer-workstation collectors (IDEs, browser extensions, AI tools, credentials). The console generates the exact command for your organization at Integrations → Overview → Server & Infrastructure. The commands below are the same.

​
Before you start

  • An organization API key (tg_…) from Settings → Organization → API Keys. The installer uses it once to enrol the server; it is never written to disk.
  • Outbound HTTPS (443) from the server to releases.tigergate.dev and your region’s API host.
  • Your region code. Pass --region unless your organization is in us1.

​
Install

Run as a normal user, not as root; the installer refuses root. With sudo the binary goes to /usr/local/bin, without it to ~/.local/bin. The agent itself always runs as this account.
export TIGERGATE_API_KEY='<your organization key>'
wget -qO install-tigergate-agent-linux.sh https://releases.tigergate.dev/scripts/install-tigergate-agent-linux.sh && chmod +x install-tigergate-agent-linux.sh
./install-tigergate-agent-linux.sh --api-key "$TIGERGATE_API_KEY" --region us1 --profile infra
sudo loginctl enable-linger "$(id -un)"
The schedule is a systemd user timer, or a cron entry where systemd --user is not available. The last line keeps the timer running after this account logs out. Without it, a server nobody stays logged in to stops scanning. The agent does not enable linger itself because that needs root.
The key is read from the environment so it stays out of your shell history. The installer verifies the binary’s SHA-256 checksum before installing it.

​
Installer options

Linux / macOSWindowsPurpose
--api-key-ApiKeyOrganization key, used once to enrol. Or set TIGERGATE_API_KEY.
--region-Regionus1, eu1 or in. Default us1.
--api-url-ApiUrlA staging or self-hosted backend URL. Wins over the region.
--profile infra-AgentProfile infraThe server profile. Required on servers.
--app-path <dir>-AppPath <dir>Another directory to search for deployed applications. Repeatable.
--runtime-home <kind>=<path>-RuntimeHome <kind>=<path>A runtime installed where the defaults and discovery do not reach. Repeatable.
--version <x.y.z>-Version <x.y.z>Pin a release. Default: the latest release.
--interval <duration>-Interval <duration>How often the agent wakes to ask whether a scan is due. Default 15m, allowed 15m to 168h. This is not the scan interval.
--no-schedule-NoScheduleInstall and enrol without a schedule, for example when your MDM runs the agent.
--privileged-PrivilegedRun the scheduled scan as root or SYSTEM. The installer then needs sudo or an elevated prompt. See Privileged mode.
--update-UpdateUpdate an agent that is already installed: no key and no other option, the stored settings are kept. See Update an existing agent.
--app-path and --runtime-home apply only to the server profile. Both are remembered, so scheduled scans use them; running the installer again without them keeps the stored values.

​
Application directories and runtime locations

You usually do not need either option. The agent searches the whole local disk outside the operating system’s own directories, so a JDK unpacked into /u01 is found even when nothing is running from it. It also follows what the server runs: running processes, systemd units, Windows services and launchd daemons, including Java -jar, -cp and -Dcatalina.home arguments and variables such as JAVA_HOME and CATALINA_HOME. See What the agent collects. Add an option when software is somewhere the agent does not search, such as an NFS share or inside /usr or /var/lib, or when a directory must be searched first: 
# A directory with deployed applications
./install-tigergate-agent-linux.sh --api-key "$TIGERGATE_API_KEY" --region us1 --profile infra \
  --app-path /data/apps --app-path /u01/app

# A JDK and a Tomcat installed in non-standard locations
./install-tigergate-agent-linux.sh --api-key "$TIGERGATE_API_KEY" --region us1 --profile infra \
  --runtime-home java=/u01/jdk1.8.0_202 --runtime-home tomcat=/u01/apache-tomcat-9
Runtime kinds: java, tomcat, node, python, php, nginx, httpd, postgresql, mariadb, mysql, redis, openssl, wildfly, dotnet, weblogic, oracle-db, websphere, liberty, jboss, and app (a directory to search, the same as --app-path). A named runtime is identified even when the files a directory search relies on are missing, for example a JDK 8 without a release file, or a Node.js install without headers. The application server and database kinds name the install root:
KindPath
weblogicThe Oracle Home that holds wlserver, or wlserver itself (MW_HOME, ORACLE_HOME)
oracle-dbAn Oracle Database server’s ORACLE_HOME
websphereThe WebSphere Application Server traditional install root (WAS_HOME)
libertyThe Liberty install root, the directory with bin/server (WLP_INSTALL_DIR)
jbossA Red Hat JBoss EAP install (JBOSS_HOME). wildfly reads the same layout.
./install-tigergate-agent-linux.sh --api-key "$TIGERGATE_API_KEY" --region us1 --profile infra \
  --runtime-home weblogic=/u01/app/oracle/middleware --runtime-home oracle-db=/u01/app/oracle/product/19.0.0/dbhome_1
For these products the agent reads the install’s patch records, not only its version, and needs read access to the Oracle Home’s inventory directory. It does not connect to a database. If it cannot read the patch level, the server is reported as patch level unknown and is not assessed; see Application servers and databases. To change the options later without reinstalling, run configure as the same account: 
tigergate-agent configure --app-path /data/apps,/u01/app --runtime-home java=/u01/jdk1.8.0_202
tigergate-agent configure --app-path= --runtime-home=   # clear both lists

​
Which account the agent runs as

By default the schedule runs the agent as the account that installed it, never as root or SYSTEM. On Linux this matters for two things:
  • Files only root can read are not read: /etc/shadow, /etc/sudoers, and on some distributions the GRUB configuration. The hardening checks that need them report Not assessed, never Pass.
  • Directories the account cannot open, such as /root or another user’s home, are skipped and counted in the server’s coverage details. They do not stop findings from closing.
Install with an account that can read the application directories you care about, or use privileged mode.

​
Privileged mode

Privileged mode runs the scheduled scan as root (Linux and macOS) or SYSTEM (Windows), so every hardening check can be assessed and every directory searched. It is opt-in and applies to the server profile only. 
export TIGERGATE_API_KEY='<your organization key>'
wget -qO install-tigergate-agent-linux.sh https://releases.tigergate.dev/scripts/install-tigergate-agent-linux.sh && chmod +x install-tigergate-agent-linux.sh
sudo ./install-tigergate-agent-linux.sh --api-key "$TIGERGATE_API_KEY" --region us1 --profile infra --privileged
Your shell expands "$TIGERGATE_API_KEY" before sudo runs, so the key reaches the installer. The schedule is a system systemd timer (tigergate-agent.timer) on Linux and a LaunchDaemon on macOS, still at low priority. Linger is not needed.
  • Where it keeps its state. The configuration and device credential live in a directory only root or Administrators can read: /var/lib/tigergate-agent on Linux, /Library/Application Support/TigerGate/Agent on macOS, %ProgramData%\TigerGate\Agent on Windows.
  • Switching keeps the device. A machine moving from a standard install to privileged keeps its device record and history. Moving back to a standard install enrols it as a new device.
  • Running commands. Agent commands on a privileged install need the same rights: sudo tigergate-agent status on Linux and macOS, an elevated PowerShell on Windows.
  • What it does not change. The agent still runs a scan, reports and exits, and still never sends a secret. A proxy that needs a Windows sign-in refuses a SYSTEM task, because SYSTEM has no network credentials.

​
Resource use

A server scan is built to run in the background without being noticed:
  • Low priority. The scan lowers its own priority, whatever started it: nice 10 and idle disk I/O on Linux, the background band on macOS, background mode on Windows. Other work on the server always goes first.
  • CPU share. The scan holds itself to 30% of one CPU core, even on an idle server. A large disk takes longer to scan rather than using more CPU. A server scan may take up to 30 minutes.
  • Memory. Memory grows with the number of packages found, not with disk size, and is released when the scan exits. The report is uploaded in chunks of up to 4 MiB, compressed with zstd, so the upload never holds the whole report in memory.
  • No package limit. Every package found is reported. TigerGate assesses up to 500,000 packages per server.

​
Verify

tigergate-agent status    # enrolment, region, schedule and last run
tigergate-agent version
tigergate-agent scan --dry-run --pretty   # what would be collected, contacting nothing
The server appears under Infra Vulnerabilities → Hosts after its first scan. Scans then follow your organization’s scan interval (default 6 hours), set in Endpoint → Devices → Device settings → Change scan interval.

​
Troubleshooting

SymptomCheck
The server is not listedtigergate-agent status, then the log: ~/.local/state/tigergate/agent/agent.log (Linux), ~/Library/Logs/TigerGate/Agent/agent.log (macOS), %LOCALAPPDATA%\TigerGate\Agent\logs\agent.log (Windows)
The server stopped reporting after you logged out (Linux)Linger is not enabled: sudo loginctl enable-linger <account>. tigergate-agent install prints a note when it is off.
Listed, but no application packagesThe agent is older than the application collector, or was installed without --profile infra. See Update an existing agent. tigergate-agent scan --dry-run --pretty lists packages_app under coverage with its status and reason.
Hardening tab is empty for a serverThe benchmark covers Linux only. On Linux, check the host_config entry under coverage in tigergate-agent scan --dry-run --pretty.
An application is missingAdd its directory with --app-path, or its runtime with --runtime-home, then run tigergate-agent scan.