Key Concepts

This page explains the AlloyScan concepts you encounter most often. Each concept appears in the Glossary with a one-line definition; here you will find the longer story and how each concept relates to others.

Scan vs Audit

A Scan is a quick discovery pass on a Segment. A scan collects basic identification — name, IP address, MAC address, operating system — and reports which devices on the segment are ready for a full audit. A scan does not consume your audit quota.

An Audit is a detailed collection performed against a specific device. An audit gathers hardware, software, and configuration data and produces an Audit Snapshot — a JSON file capturing the device's full state at a point in time. Each audit consumes one unit of your monthly Audits quota.

The practical consequence:

• Scans are cheap. You schedule them broadly to keep discovery current and to spot new devices on a segment.
• Audits are deeper but billed. You schedule them for the devices that matter and you can trigger them ad-hoc when you need a fresh snapshot.
• A scan does not consume license quota; an audit does.

For agentless inventory, scan and audit are separate stages. Run a scan first to discover what is in scope, then audit selected devices manually or enable Automatically audit discovered devices on the Segment when you need details immediately after discovery.

For agent-based inventory, there is no separate scanning stage. After the Audit Agent is installed, the computer is audited directly and sends audit data to AlloyScan over outbound HTTPS.

If a scheduled audit cannot collect new data (for example because credentials are wrong, or the host is offline), the device's previous snapshot values are retained rather than blanked. Investigate the failure through the Audit log.

Site vs Instance

An Instance is a running AlloyScan deployment, either SaaS at *.alloyservice.com or on-premise. Each instance hosts one License and many Sites.

A Site is a tenant within an instance. A Site is the logical container for one organization's inventory data, audit results, and related configuration. A Site has its own URL slug (for example agent in /agent/dashboard), time zone, avatar, users, segments, inventory, schedules, reports, and logs.

This separation is what makes AlloyScan suitable for managed service providers and other multi-tenant deployments. Each tenant lives in its own Site; an MSP administrator switches between Sites using the site switcher in the header.

The instance scope and the site scope each have their own administration surface in the Admin Center — App management for the instance, Site Settings for the current Site.

Credentials pool

The credentials pool is the collection of Credential records attached to an Audit Service. Each Credential is a typed secret — there are seven types: Windows, Linux and macOS, Hypervisor, SNMP (v1, v2c, or v3), AWS, Azure, and Google. The Audit Service uses these credentials to talk to the devices it scans and audits.

How AlloyScan handles credentials is shaped by two design principles:

• Local custody. Per the public documentation, credentials are stored encrypted on the customer network — on the Audit Service host — and never leave it. Alloy's SaaS side never sees plaintext secrets.
• Write-only secrets. Once a password is saved, the form shows Has password or Not set. You cannot reveal the stored value; you replace it by entering a new one.

Note: The exact mechanism that links a specific Segment to specific records in the pool can vary by deployment. Treat the Service's credentials pool as the source of truth.

Segment

A Segment defines what AlloyScan should discover. Choose the Segment type based on the target source:

Cloud Segments are in Preview. If you are setting up AlloyScan for the first time, see Choose your first inventory path before creating the Segment.

Device types

AlloyScan organises every audited device into a type taxonomy, and the Inventory reflects the same taxonomy as a hierarchical browse:

• Computers — Windows, macOS, and Linux endpoints.
• Hypervisors — VMware ESXi is fully supported end to end. Microsoft Hyper-V, Citrix XenServer, and Xen appear in the documented taxonomy.

  Note: Details may vary by deployment.

• Hosted hypervisors — VMware Workstation and Oracle VirtualBox appear in the taxonomy.
• SNMP devices — Printers (with a dedicated Printer supplies tab), Switches, and Others.
• Cloud resources — AWS resources observed include EC2 instances; the broader taxonomy covers AMIs, Subnets, Zones, RDS, Key pairs, Network interfaces, Load balancers, S3 buckets, VPCs, and Security groups. Azure and Google segments are configured separately.

  Preview: Cloud segments (AWS, Azure, Google) are in preview and subject to change.

The device type matters at three points: it dictates which credential type the Audit Service uses, it determines the form layout you see (computers have General / Details / Audit / Change history; SNMP printers replace Details with Printer supplies; cloud devices have cloud-specific sections), and it controls which Custom audit fields apply.

Inventory

The Inventory is the collection of all audited devices for a Site. It is the place you go to find a device, inspect its current state, prepare a remote action, or run an ad-hoc audit. The Inventory landing page shows a sectioned card view with counters per device type; each card drills into a grid for that type.

Two practical points worth knowing up front:

• Inventory grids cap at the top 1000 records by default. A banner appears when the cap is in effect; Load all lifts it but is performance-heavy.
• Custom views are personal by default. Administrators can elect a shared visibility to expose a custom view to everyone in the Site.
• After a device is added to Inventory, you can assign a regular audit schedule from the device's Audit tab.

The Inventory is fed by Scan results (which discover devices) and Audit operations (which populate the device record with detail). A device that has been scanned but not yet audited shows Ready for audit in the Segment Open view; once audited, it appears in Inventory with full data.

Tag

A Tag is a Site-scoped label applied to a device. Tags display as coloured pills on the device row and on the device form. They give you a way to group devices by role, location, project, owner, or any axis your operations care about, and then filter the Inventory grid by tag.

There are three ways a tag is applied:

• Manually. A User or Administrator picks a tag from the device form's Credentials and tags panel on the Audit tab. The tag must already exist in the Site catalog.
• Automatically by Segment. A Segment's Auto tag option applies a tag to every device discovered on that Segment.
• Automatically by Audit Agent. A site-level setting on Audit Agents auto-applies a tag to every computer audited by an agent.

Only Administrators create tags in the catalog (Admin Center > Site Settings > Customization > Tag management). Once a tag exists, Users can apply it.

Related

• Welcome to AlloyScan
• Choose your first inventory path
• Run your first scan and audit
• Glossary