Operate the instance admin console

This console requires the instance-admin role. Workspace administration configures one workspace. Instance administration operates the deployment.

1. Open Instance admin at the bottom of the sidebar.

Overview

The overview shows silent mode, configuration readiness, release information, workspace counts, and recent authentication activity.

1. Before you invite members or enable feedback, check readiness.
2. Use the first sign-in checks to resolve missing configuration.
3. Use the configuration readiness reference.

Users

You cannot demote yourself or remove the last instance admin. Sensitive access changes require a recent sign-in.

1. Find the account.
2. Change its instance role or force sign-out of its sessions.

A connected provider account identifies a person. An instance role does not create workspace membership.

Workspaces

1. Inspect workspace metadata and status.
2. Open the workspace administration you need.

Instance admins have ADMIN access to any active workspace, even without membership. Elevation does not grant OWNER privileges. Owner-only operations require explicit OWNER membership. It does not give them Hephaestus or a member's private Practice profile in ordinary workspace navigation.

Hephaestus audits this access. Instance administration owns the authority. See the elevated-access audit policy.

View as user

View as user gives access to a member's permitted read-only pages for support. It requires a recent sign-in. Each read about the member has a USER_VIEW audit record with the instance admin, member, workspace, and reason. If Hephaestus cannot record the audit, it refuses access.

1. Select View as user.
2. Supply a reason.

The view permits reads only. It cannot send a Hephaestus reply, submit feedback, change settings, or run a review as that member. Your own session remains the identity that acts. This is not a sign-in as the member.

1. Use the view's exit control to return to your own account.

Audit

You cannot edit audit entries through the console. For retention and access policy, use the data-protection documentation.

1. Read authentication events, user views, and configuration changes.
2. Use the available filters to find who changed a setting and when.

Usage

The instance admin sets or clears a workspace's cap on shared-model spend. A workspace admin sets the separate cap for that workspace's own provider. A cap blocks new spend. It is not a refund or a guarantee that the provider's bill is correct. AI providers owns model setup, prices, model access, and assignments.

1. Inspect monthly AI usage by workspace.

The table of workspaces has one row for each workspace:

Column	What it shows
Workspace	The workspace's name and its slug.
Shared models: Spend, Budget	The month's spend on the instance's shared models. Budget shows the shared-model budget and the share of it that the month used. It also shows a state when it applies: Paused, Near the budget, or No price set. A workspace without a budget shows a dash, and still shows No price set when it applies.
Own provider: Spend, Cap	The same figures for the workspace's own provider, against its provider cap. Its near state is Near the cap. Only the workspace's admins set this cap. These columns appear when at least one workspace uses its own provider in the month.
Runs	The month's review attempts and conversation turns.

The table shows the highest shared-model spend first. Select Workspace, a Spend heading, or Runs to sort by that column. The table filters by workspace name and shows 25 workspaces on each page. The address keeps the filter, the sort, and the page, so you can share the view.

In the current month, Set budget or Change budget on a row sets the workspace's shared-model budget. Details shows the usage of one workspace below the table, under its name and Usage details, with its practices. In those tables, No price set counts the runs that have usage without a price. In the table by practice, it counts reviews. Usage by practice describes those tables.

Person data

The person-data console handles access and erasure requests, including people who have never signed in.

Do not substitute a display name for a provider ID.

1. Select an account ID or exact provider identities.
2. Preview the resolved person and workspace scope before you request an export or erasure.

Use the data-protection documentation for identity verification, scope, retention, and external-copy obligations. This console is separate from a member's own Danger zone.

Silent mode

New instances start with silent mode on. It blocks new writes to GitHub, GitLab, and Slack, and all email. Inbound events, sync, practice reviews, and result storage continue. The kill-switch map lists what silent mode stops and what it does not stop.

A stale settings view cannot turn off a newer silent mode setting. If you turn silent mode off, Hephaestus does not replay feedback withheld while it was on. For incidents, deployment checks, and recovery, follow the production operations runbook.

1. Open Instance admin → Instance settings to inspect or change silent mode.
2. Before you turn it off, read the current state.

Bootstrap and recovery

Promotion occurs on sign-in. This setting never demotes an existing admin.

1. Before first sign-in, set HEPHAESTUS_AUTH_BOOTSTRAP_ADMINS as First steps describes.

The recovery endpoint promotes an account only while no admin exists. Do not publish the token or keep it in shell history.

If no admin exists, use this recovery procedure:

1. Temporarily set HEPHAESTUS_AUTH_BOOTSTRAP_TOKEN.
2. Restart the application server.
3. From a signed-in account, submit the token to POST /api/auth/bootstrap-admin with normal CSRF protection. The JSON body must have a token field.
4. After recovery, remove the token from deployment configuration.
5. Restart the application server.

For normal bootstrap configuration, use provider-specific numeric IDs where possible.

Contributor details belong in Instance administration implementation.

Accounts before sign-in

Roster sync can create an Unclaimed human account with membership before the person signs in. It creates no sign-in credential and gives bots no account. A verified sign-in claims the existing identity rather than creating another developer. Account choices apply across connected identities and workspaces. View-as remains an audited admin read and cannot establish the developer's private feedback delivery.