Administration area

The Administration area (/management) is the installation operator’s own surface. It has its own sign-in, separate from product accounts - an operator account cannot open product pages and vice versa.

Overview

The landing page shows what the installation is and what it is doing: user/workspace/project counts, per-module status cards (ArchPilot, ArchScan, Code Health) behind an optional workspace filter, distribution charts, a working-pace gauge, activity for the last 28 days, and the update check when one is configured.

Workspaces

Every workspace on the installation, with a detail page per tenant:

members (accounts that sign in through LDAP are badged - their passwords live in the directory),
projects (a project without a credential is flagged: it explains a repository that never scans),
pending invitations with expiry,
an invitations on/off switch - closing it hides the invite action for that workspace’s members and the API refuses the call, whoever makes it. The workspace’s own admins cannot lift it.
a Reset module data card: pick modules (ArchScan, ArchPilot, ArchSecurity, Compliance, Git Health, engineering analytics, assistant history) and their results for this workspace are physically deleted - runs, scans, findings and facts. Rules, integrations, credentials and members stay; the next scan or sync starts from scratch. There is no undo, which is why it asks first.

ArchScan runs and ArchPilot reviews on the workspace module screens carry a Delete button for the same purpose: a trial run that should not count is removed with its findings, permanently.

Two more pages hang off the workspace detail:

Configuration - the half of a tenant’s setup only its own members could see: the credentials it can reach a Git provider with (workspace-owned and installation-shared, each with the last four characters and how many projects use it), everything it is connected to (Jira, Trello, Sonar, Slack, Teams, JMeter, Argo CD, Kubernetes, Dynatrace, New Relic), its scan schedules, its custom roles with the permissions each grants, and its project groups. Read-only, and no secret is readable there.
Project detail - click a project name: default branch, group, credential and its expiry, the runner token’s last four characters and how old it is, whether a webhook secret is set, scan scope include/exclude globs, architecture approaches, rule overrides, release tracking and who registered it. The token and the webhook secret are stored hashed and are not readable.

A deleted workspace can be restored from the workspaces list. The rows were never removed, so it comes back with its projects and history intact.

Module screens

Each module has an installation-wide screen, and most let you open one workspace exactly as its own members see it - the same dashboards, the same findings, the same reports, read-only where an action belongs to the tenant (exports, sync buttons, closing comments).

ArchScan - estate dashboard, per-workspace drill-down to runs and full reports; Code Health and Dependencies live on its tab strip with the same optional workspace/project filter.
ArchPilot - adoption and outcome (reviews passed / needs attention / failed), the most-triggered rules and how often their comments are acted on, per-workspace reviewed-MR lists with finding detail.
ArchSecurity - severity mix, per-workspace security dashboard and framework reports (OWASP, PCI DSS, DISA STIG, CASA ASVS), including open findings mirrored from GitLab/SonarQube - counted beside our own, never merged.
Compliance, Git Health, Service Catalog - installation-wide equivalents of the tenant screens, all narrowable by workspace and project.

Everywhere, never scanned is reported as unknown - not as healthy and not as zero.

On the compliance and Git Health screens the operator can also queue a scan for a project on behalf of the workspace. The run is recorded as triggered by operator and attributed to no tenant user, so a support action never looks like something a customer did.

Settings

One tabbed screen: Licence (with the limits the licence grants), E-mail (SMTP/Postmark, with a test send), Report e-mails, AI assistant (see Archito, the assistant), Sign-up & invitations - the self-service registration switch, the invitable e-mail domain allowlist, and the installation-wide two-factor switch -, Dashboard, Modules (turning a module off also stops its scheduled jobs), LDAP, Turnstile, Languages and Analytics. When the licence expires the installation keeps working for a 14-day grace period; once it is over, the installation stops until a new licence is installed - see Staying licensed for what that means and what else can stop it.

The Licence tab also shows the installation code. A licence works on one installation: the first installation that collects it online binds it to itself, and another installation asking for the same licence is refused. An air-gapped installation sends this code to AppArch and receives a .lic file that works on this installation only. Several pods sharing one database count as one installation. To move to a new server, ask AppArch to release the licence, then collect it again from the new server - see One licence, one installation.

Danger zone - factory reset

Settings > Danger zone wipes the installation back to first run: every workspace, member, invitation, user account, Git credential (shared ones included), project, integration, scan, finding and report is deleted and identity counters restart. Administrator accounts, the licence, the installation credentials, the settings, translations and the rule catalogues stay, so the setup wizard does not run again - the app simply has no users or workspaces. There is no undo; take a database backup first (docker compose exec postgres pg_dump ...).

The reset is deliberately slow to trigger:

Password - only an administrator holding every permission can start it, and must re-enter their password.
E-mail code - a six-digit code is sent to that administrator’s own address (valid 15 minutes, five attempts). Outgoing mail must be configured; there is no other way to confirm.
Typed confirmation - the licensed customer name, exactly as shown.
Ten-minute window - the wipe is scheduled, every active administrator is e-mailed a link, and any of them can cancel until the window closes. After that the job runs within thirty seconds and cannot be stopped.

Every request is logged in the administration database with who started it, from which address, and per-table counts of what was removed. Administrators receive a final e-mail with the totals. An optional switch deletes the licence as well - only for handing the installation to a different customer.

Operations

Updates - installed version against the vendor registry, per component, with a check-now button. The check goes through the vendor gateway with the installation credentials; air-gapped installations switch it off with UpdateCheck:Enabled=false.
Security advisories - the vulnerability data every scanned dependency is matched against, per registry, with the OSV import that refreshes it. See below.
Findings - what the installation noticed about itself: a job that threw, a project whose sync keeps failing, a mail that exhausted its attempts, a row the database rejected. One row per problem with how often it recurred and the last error; it closes itself when the subject succeeds again. Mark seen, close by hand, or mute a type for yourself only. Open findings show as a badge on the sidebar and on the landing strip.
Jobs - every scheduled job with a run-now button.
Capacity (its own page under System) - measured job load (each job’s average duration over its interval, summed) against the worker threads one Api pod brings, the live pods from the Quartz cluster table with their real CPU and memory, load by module group, the heaviest jobs with category filtering and column sorting, and a pod recommendation: one pod carries the load but two are advised for gap-free restarts, or N pods when the doubled load exceeds one pod. Appears after seven days of history.
System health - live PostgreSQL and Redis probes (never cached) plus scheduler state. For orchestrator probes, use the unauthenticated /health/live and /health/ready endpoints instead - see the on-prem installation guide.
Integrations - an inventory of everything the installation talks to, per workspace, with no secrets shown.
Users, invitations, administrators - account management for both planes.

Security advisories

Every ArchScan run reports the dependencies the repository declares. The Api matches that list against the installation’s own advisory catalog and raises a finding for any package whose installed version falls inside a published vulnerable window (CWE-1104, mapped to OWASP A06 and the PCI, STIG and CASA controls). The match happens here rather than in the runner for two reasons: a CI job on a customer network cannot reach a CVE service, and a collector image pinned a year ago would carry a year-old dataset.

The product ships a curated baseline for the eight registries the collectors read - NuGet, npm, PyPI, Maven (Java and Kotlin), Go, RubyGems, Packagist and SwiftPM. Vulnerability data ages in weeks, so refresh it under Administration → Security advisories: on a machine with internet, download the export of the registry you need from osv.dev (osv-vulnerabilities/<registry>/all.zip), join the records into a single JSON array, and upload the file. The next scan matches against it - no image rebuild and no outbound call from the installation.

An import adds and updates rows; it never deletes one, and it never re-enables an advisory an operator switched off after a false positive. The screen also shows which registries have no advisories at all, because that is the same thing as a language whose dependencies nobody is checking.

Every administration sign-in attempt is recorded - who, from which address, with which browser, and why it failed (wrong password, unknown e-mail, inactive account, locked account). The trail is on Audit > Sign-ins.

After five failed attempts an account is locked for fifteen minutes. The lock is per account, not per address: every sign-in reaches the API through the UI pod, so an address-based lock would count one machine. A locked account is badged on the administrators list and any administrator holding the Administrators permission can unlock it without waiting.

Every operator token now belongs to a session, and My sessions (from the administrators screen) lists them: device, address, when it started and when it was last used, with the one you are looking at marked. Ending a session signs that browser out on its next request, and it cannot be renewed afterwards either - so “sign out that laptop” really means it, rather than lasting until the token happened to expire. End every other session clears the rest in one action.

An administrator with the Administrators permission can also sign a colleague out everywhere from the list, without touching their account. Disabling them was the only way to do this before, and it takes their access away until somebody remembers to switch it back on.

Removing an administrator

Delete administrator on the list removes the account: it disappears from the list, cannot sign in, its live sessions end immediately, and its e-mail address is free for whoever replaces them.

The database row survives, and that is deliberate. The audit trail, the sign-in history and every “changed by” reference name their actor by that account’s id, with no foreign key behind it. Dropping the row would leave those saying “someone” - the trail would outlive the account but forget who was in it. So the account is emptied instead and hidden everywhere it could still be used.

You cannot delete your own account: a request that destroys its own credentials halfway through is a confusing way to spell “sign out”, and one mistyped click would lock you out of the panel. To retire your own account, have a colleague do it.

What each permission gates

An administrator’s permissions decide what they can do, not just what they see - the API refuses the call either way:

Licence - installing and replacing the licence.
Users - suspending, reactivating and deleting accounts, resetting passwords.
Administrators - creating administrators, changing permissions, unlocking.
Settings - every settings tab, integration settings and shared credentials.
Workspaces - lifecycle actions: ownership, membership, invitation switches, delete and restore.
Data - physical deletion: workspace purge, deleting a run or a review.
Operations - pausing and resuming jobs, exports, sending mail.

An administrator without a permission does not see the menu group it belongs to, and the matching endpoints answer 403.

Deleting a user

A user page carries the workspaces that person is in and, when they own none, a Delete user action. It removes every membership, external login, two-factor enrolment and recovery code, revokes their sessions and scrubs the identity - the sign-in history and the audit trail stay, because they are the record of what happened. A person who still owns a workspace cannot be deleted: transfer ownership first, which is one action on the workspace page.