Online Help

About Sites

A Site is the unit of multi-tenancy in AlloyScan. Each Site is an isolated tenant on the instance: its own users, devices, segments, audit services, schedules, notification templates, logs, and quotas. An AlloyScan instance can host many Sites — the test instance documented during product baselining hosts 78 Sites, for example.

How Sites work

Note: This page covers instance-level administration in App Management. It is used by Global Administrators.

Each Site is identified by:

  • A Title — the human-readable name of the Site, shown in the Site switcher and on the avatar.
  • A Slug — the URL identifier. The Slug appears in the path component of every URL for the Site (https://<instance>.alloyservice.com/<slug>).
  • A Time zone — set per-Site. AlloyScan uses this time zone when displaying log timestamps, schedule "next execution" times, and the recharge day for monthly quotas.

When a Global Administrator creates a new Site, AlloyScan seeds it from the current instance Site Template. The Site Template carries default notification templates, default reports, default change-tracking categories and sub-attributes, default tools, and default snapshot storage settings. Seeding is one-shot — the template is copied into the new Site at creation time. Subsequent changes to the Site Template do not retroactively update Sites that already exist.

Per-Site quotas and configuration

Each Site has its own per-Site Max caps for users, audited devices ("nodes"), audits per month, and API transactions per month. A Max value of 0 means "no per-Site cap — inherit from the instance license". The instance-level license sets the upper bound, and per-Site caps allow the Global Administrator to delegate consumption to individual tenants.

Within a Site, an Administrator owns all Site-scoped configuration: IAM, schedules, segments, credentials, change tracking, snapshot storage, notifications, and so on. Site-scoped configuration never crosses tenant boundaries — credentials in one Site's Audit Service pool do not leak to another Site.

Why this design

Multi-tenancy as a first-class concept supports both single-organization deployments and Managed Service Provider (MSP) operations from the same product. Per-Site Slug, Time zone, and Site Template give each tenant a distinct identity while keeping the operational stack shared. Per-Site quotas let the instance owner enforce contractual limits without rebuilding tenant boundaries in business logic.

Key distinctions

  • Site vs Instance — a Site is a tenant; the Instance is the host of all Sites. A Global Administrator works at the instance layer; a Site Administrator works at the Site layer.
  • Slug vs Title — the Slug is the durable URL identifier; the Title is the display name. Changing the Slug changes URLs.
  • Site Template seeding vs ongoing config — Site Template defaults are applied once at creation. To roll out a new pattern across existing Sites, update each Site directly.

Limitations

  • Site Template seeding does not retroactively update existing Sites. Roll out changes per Site after updating the template.
  • Cross-Site operations require Global Administrator scope. Site Administrators cannot perform actions across tenant boundaries.