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.