Users
By the end of this page you will know how to find any account, create one, pre-authorize 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-authorize a plan with Authorise user
Use this when someone will sign in through your identity provider and you want their plan ready for them.
Select 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 authorized, 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.
Select 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 |
Select 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 switch off your own local admin when it is your only route to admin rights, so you cannot lock yourself out that way.
A session that is already open keeps its admin rights until it ends (up to 7 days). To remove access immediately, also block or deactivate the account, which ends all of its sessions.
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 select 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.
Reading the Lifecycle card
| What you see | Meaning |
|---|---|
| "No lifecycle events" | No plan change has been recorded and nothing has been suspended or retired |
| A plan timeline row with "N labs stopped · N devices suspended" | A downgrade was enforced and this is what it did |
| A plan timeline row with enforcement pending | The change is saved but the enforcement job has not run yet |
| Suspended devices | VPN devices switched off, with the reason and the date |
| Storage retirements | Storage set aside rather than deleted, with its size and state |
| Amber "Dormant since …" banner | The account was idle long enough to be treated as dormant: its devices are suspended and its storage retired. The storage can still be recovered until the grace period ends. |
| Red "Dormant account finalized" banner | The grace period has ended and the retired storage has been permanently deleted. Database records are kept. |
By default an account becomes dormant after a year without activity, and its retired storage is deleted a year after that. The dormant-account worker is not on the schedule by default: it runs when an administrator runs it by hand from Config (Advanced) → Cron Workers, where it is listed as On-demand only.
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 select 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.
Good to know about impersonation
- "Recent" means recent. By default you must have signed in within the last 15 minutes. Your platform may use a different window.
- You land on the user's dashboard. There is no banner saying whose account you are in; the only sign is the End Impersonation item in the profile menu. Your own admin session is kept aside and comes back when you choose it.
- The user is not told. Nothing is sent to them. The audit trail records that you started and ended it.
- Closing the browser is not the same as ending it. If you close the tab without End Impersonation, sign out and sign back in to return to your own account.
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.
- Select 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.
- Select 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.
Common questions
| Question | Answer |
|---|---|
| I granted admin but they still cannot open the admin panel | Admin rights are worked out at sign-in. Ask them to sign out and back in. |
| I revoked admin but they can still use it | Their open session keeps it until it ends. Block or Deactivate the account to end every session now. |
| I downgraded someone and their labs are still running | The enforcement job has not run yet. Look for enforcement pending on the Lifecycle card. |
| Impersonate says "Re-authentication required" | Your sign-in is older than the allowed window. Sign out, sign in, and try again straight away. |
| Impersonate fails for one particular person | Their account is local-only. Impersonation works only for accounts that sign in through GitLab. |
| The plan went back after the expiry date | That is how Authorise user with Expires works. Authorise them again with a later date, or none. |
| A limit override seems to do nothing | 0 or blank means "use the plan default". The Effective column shows what they really get. |