Users
By the end of this page you will know how to find any account, create one, pre-authorise a plan for someone who has not signed in yet, change a user's plan and limits, grant or remove admin rights, see the platform as a user sees it, and move everything a departing user owns to someone else.
Admin Panel → Platform → Users → All Users (/admin/users)
The user list
The page is headed User Management and has up to three tabs:
| Tab | Shows |
|---|---|
| All Users | Every account |
| Admins | The same table, filtered to admins |
| Faculty | Faculty members. Only shown when the Education module is on. Faculty cannot use the admin panel in this release. |
It also lists GitLab instance administrators and anyone whose role label reads "Admin", neither of which grants admin rights here. For the real answer, open the user and read the Admin access card.
Finding someone
Search by name, email or username. After two characters a dropdown offers matches you can jump straight to. Narrow the table with the role filter (All Roles, User, Faculty, Admin) and the plan filter (All Plans, Free, Paid).
The table shows User, Role, Plan, Status, Last Sign In, Created and Actions. The row menu offers:
| Item | What it does | Confirmation |
|---|---|---|
| View Details | Opens the user's page | — |
| Impersonate | Signs you in as this user. See Impersonation. | Yes |
| Set Faculty / Set User | Changes the role label | Yes |
| Set Pro plan / Set Free plan | Changes the plan as an administrator override | Yes |
Adding people
1. Pre-authorise a plan with Authorise user
Use this when someone will sign in through your identity provider and you want their plan ready for them.
Click Authorise user and fill in Email address, Plan (Pro or Free) and, optionally, Expires.
- If the account already exists, the plan changes now.
- If not, the plan is applied at their first sign-in.
- When the expiry date passes, the plan drops back and any labs over the new limit are stopped.
Pending lists the emails you have authorised, with their plan and whether the account exists yet or is Awaiting first login. Revoke removes an entry immediately, without confirmation.
2. Create a local account with Add user
Use this for someone who will sign in with a username and password rather than through an identity provider.
Click Add user and fill in:
| Field | Notes |
|---|---|
| Required | |
| Username | Optional |
| Password | Optional, at least 8 characters. Needed for username and password sign-in. |
| Plan | Free or Pro |
| Make platform admin | Grants local admin rights on this platform |
| Account limits | Optional overrides: running labs, VPN devices, storage (GB), custom domains, managed services, WireGuard interfaces, and whether the user may create their own WireGuard interfaces |
Click Create account. Account creation and any admin grant are audited.
The user's page
Open View Details from the list, or go to /admin/user/ followed by the
person's email, username or ID. The banner shows their name, email and role,
plan and state badges.
Profile
| Control | What it does | Applies | Audited |
|---|---|---|---|
| Role (User, Faculty, Admin) + Save | Changes the role label. "Admin" here does not grant admin rights. | Immediately, no confirmation | Yes |
| Platform moderator | Makes the user a moderator. See the admin guide overview. | Immediately, no confirmation | No |
| Plan (Free, Default (Paid)) + Save | Changes the plan. Same effect as the list's plan items. | Immediately, no confirmation | See below |
| Impersonate User | See Impersonation | After confirmation | Yes |
| Transfer Entitlements | See Handing over what a user owns | After typed confirmation | Yes |
The stat tiles below show the user's Zeal and Jolt earned and spent, achievements, quizzes completed, active and total instances, clan and cohorts.
Admin access
This card is the authoritative view of whether someone is an admin.
| Grant | Buttons | Notes |
|---|---|---|
| Local platform admin | Make platform admin / Revoke local admin | This platform only |
| GitLab admin group | Add to group / Remove | Shown only when GitLab sign-in is set up, and not for local-only accounts. Applies to every platform sharing that GitLab. |
Both ask for confirmation, both are audited, and both take effect at the user's next sign-in. The panel refuses to let you remove your own last admin grant, so you cannot lock yourself out.
Plan and limits
Shows the user's plan, where it comes from, and when it expires if it does. For each limit the table shows the Plan default, your Override, and the Effective value the user actually gets.
Limits you can override: running labs, VPN devices, storage (GB), custom domains, managed services and WireGuard interfaces, plus per-service caps and the switch that lets the user create their own WireGuard interfaces.
Enter a number and click Save limits. Blank or 0 means "use the plan default". There is no confirmation. Each changed field is audited.
A storage change is applied and checked on the server, which can take minutes. The other limits save even if the storage change fails. Storage in depth is on Storage quotas.
What a plan change does
A plan change you make is an administrator override: it is not reverted the next time the user signs in.
A background job then enforces it and notifies the user:
- a downgrade stops labs over the new limit and suspends excess VPN devices
- an upgrade re-provisions the user's storage
The change and its outcome appear on the user's Lifecycle timeline: old plan, new plan, who changed it, how many labs were stopped or devices suspended, or "enforcement pending" until the job has run. Plan changes are recorded there and in server logs, not in the audit trail.
The job runs every few minutes when it is scheduled. If a downgrade stays pending, open Config (Advanced) → Cron Workers and check that the plan-limits worker is scheduled. See Platform settings.
Other cards
| Card | What is there |
|---|---|
| User Details | Email, username, user ID, created, sign-in and activity times, plan. Links to the public profile and to Transactions. |
| Zeal Earnings Breakdown | Earnings by type, with count and total |
| Lifecycle | Plan timeline, suspended devices, storage retirements, dormancy status |
| Recent Transactions (Zeal) | The user's latest Zeal movements |
| Lab Instances | Every lab the user has, with status |
| Cohort Membership | Links to each cohort they belong to |
| GitLab Actions | Account state on GitLab, see below |
| GitLab Groups | Add the user to a GitLab group at an access level, or remove them |
| SSH Keys | The user's GitLab SSH keys, with Delete |
| Page Visits | Pages the user visited, filtered by day or the last 7 days |
The Transactions → View All link opens the Transactions page for everyone, not just this user. Pick the user in its User filter. See Economy.
Impersonation
Impersonation signs you in as the user so you can see exactly what they see: their labs, tiles, shared resources and limits.
- Open the user's page and click Impersonate User, or use Impersonate in the list's row menu.
- Confirm.
- When you are done, open the profile menu and choose End Impersonation.
Two limits:
- It needs a recent sign-in. If yours is too old you see "Re-authentication required". Sign out, sign back in, and try again.
- It works only for accounts that sign in through GitLab, not local-only accounts.
Starting and ending impersonation are both audited. Everything you do while impersonating is done as that user, so treat it as acting on their behalf.
Signing someone out and blocking them
The GitLab Actions card controls the user's GitLab account:
| Button | Effect |
|---|---|
| Sync from GitLab | Refreshes the user's details from GitLab. No confirmation. |
| Block / Unblock | Blocks or unblocks the GitLab account |
| Deactivate / Activate | Deactivates or reactivates the GitLab account |
Block and Deactivate take effect on GitLab immediately and sign the user out of every session they already have on this platform. These are audited and ask for confirmation.
The card also shows the GitLab state, a link to the GitLab profile, two-factor status and when the account was last synced.
Handing over what a user owns
Transfer Entitlements moves everything a user owns to another user. Use it when someone leaves and their work must carry on.
- Click Transfer Entitlements. A preview lists what they own, with counts: organization and department ownership, domains, VPN devices, reserved addresses, lab templates, provisioned services, home storage data, and their access grants (which are revoked).
- Read the two warnings in the preview:
- what is never transferred: running instances, Zeal and Jolt balances, SSH keys, the GitLab account link, uploads and notifications
- any running labs, which are stopped before the transfer
- Pick the recipient and the categories to move.
- Type
TRANSFERfollowed by the recipient's email. - Optionally tick Override the recipient's services cap (audited) if the recipient would otherwise go over their services limit.
- Click Execute transfer.
You get a report for each item: moved, queued, skipped or failed. If anything failed, Retry failed tries those items again.
The only way back is another transfer in the opposite direction. The whole transfer is audited.
Offboarding and personal data
To offboard someone, transfer what should be kept, then Block or Deactivate their GitLab account so they are signed out everywhere.
Exporting or erasing a person's data on request has no button in the panel in this release. Ask your engineering team. Erasure is irreversible: it removes stored files permanently and de-identifies the person's records, and it refuses to run until the person's live resources have been offboarded.