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 administration 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 instance checks of First steps 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.

When an instance admin grants or removes the instance-admin role, Hephaestus sends an email to the affected person and to the other instance admins. The email names who made the change, when, and links to the instance audit log.

An admin who grants a higher role to their own account receives an email too. Lowering your own role sends none. Only the first bootstrap administrator of a fresh instance is silent.

The hephaestus.auth.bootstrap-admins setting also grants the role. That email names the setting as the source. The email goes only to a verified address, and only if the instance sends email.

A force sign-out ends the current sessions only. The person can sign in again through their provider at once.

Block an account

Block an account to stop a person from using the instance, for example after a security incident or when they leave.

1. In the row of the account, open the actions and select Block account.
2. Confirm.

Blocking ends every session of the account at once, including browser extension sessions. Sign-in through any linked provider is refused until an instance admin unblocks the account. The person sees that an admin blocked the account. Workspace memberships, feedback and other data stay as they are.

You cannot block yourself or the last active instance admin. Each block and unblock requires a recent sign-in. Each writes an Account blocked or unblocked audit record with the admin and the status before and after.

Only active or blocked accounts can change between these states. Unclaimed accounts and accounts whose deletion has started cannot be blocked or unblocked.

A block applies to the account and its linked identities. A provider login that is not linked to the account creates a new account at sign-in.

Unblock an account

1. In the row of the blocked account, open the actions and select Unblock account.
2. Confirm.

The person can sign in again. If the account has a verified email address, Hephaestus sends a security notice that the account is unblocked.

Workspaces

1. Inspect workspace metadata and status.
2. In the row of the workspace you need, select Open administration. The workspace administration opens on its settings.

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. In the row of the workspace, select View as user.
2. In the row of the member, select View as user.
3. 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 short name.
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.
Uses	The month's review attempts and conversation answers.

The table shows the highest shared-model spend first. Select Workspace, a Spend heading, or Uses 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. In those tables, No price set counts the uses that have usage without a price. AI usage 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.

The personal-data map states the scope of database, attempt-copy and provider-mirror erasure. If a workspace is installed on the person's own GitHub or GitLab account, the provider login stays as the name and namespace of that workspace. Erasure, an uninstall of the app and a workspace purge keep it. Tell the person this before you request the 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 administration → 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. Add the key HEPHAESTUS_AUTH_BOOTSTRAP_TOKEN to the release Secret that secret.name names. Generate its value as Generation and rotation gives it.
2. Restart the server, as Restart a role gives it.
3. Sign in with an account. In that session, get a CSRF token with GET /api/auth/csrf. The response body gives token and headerName, and the response sets the cookie __Host-XSRF-TOKEN.
4. In the same session, send POST /api/auth/bootstrap-admin with that cookie and the token in the header that headerName names. The JSON body must have a token field with the bootstrap token. Without a signed-in session, the endpoint returns 403.
5. Remove the key from the Secret.
6. Restart the server again.

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.