Labs and instances
A running lab is an instance. This page covers how to find any instance on the platform, see what it is doing, and step in when one misbehaves. It also covers the admin-only controls that appear on the normal dashboard pages.
Admin Panel → Labs → Instances → All Instances (/admin/instances)
The Labs group only appears while the Labs module is on.
All Instances
The page is headed Instance Management. Summary cards show Total Instances, Active, Inactive and This Week.
Filter by status (All, Active, Inactive) or search. Columns: Lab, Owner, Instance ID, Status, Resources, Created, Actions. Click a row to open its detail page, or use Stop in the row (with confirmation).
Instance detail
Opens at /admin/instances/ followed by the instance ID.
Actions
| Button | What it does | Available |
|---|---|---|
| Stop | Stops the lab. Recorded on the lab's timeline as an admin action. | Active labs, with confirmation |
| Restart | Stops and starts the lab | Active labs, with confirmation |
| Force Kill | Kills the lab when a normal stop does not work | Active labs, with confirmation |
| View as User | Opens the lab's normal page, as yourself. This is not impersonation. | Always |
The panel marks the lab stopped even if the stop or kill failed underneath. Refresh the page after a few seconds and check Container Inspection or the owner's lab page. On some platforms Force Kill is not permitted at all.
Stop, restart and kill are recorded in server logs, not in the audit log.
What else is on the page
| Section | What is there |
|---|---|
| Connection Information | How the owner connects. Passwords are hidden. |
| Real-Time Metrics | Live CPU, memory, network and disk |
| Historical Metrics | The same over 24 hours, 7 days, 30 days or all time |
| Container Inspection | The lab's runtime details, with Show Raw JSON |
| Usage History | Past runs of this lab |
| Terminal | The admin shell. See below. |
Admin shell
The Terminal section gives you a shell as root inside the lab. Click Open Shell; Ctrl+C interrupts the running command.
It works only when Settings → Security → Admin shell into lab containers is on. On customer platforms it is off by default. See Platform settings.
Anything you run can read or destroy the owner's work. Use the shell for diagnosis, tell the owner what you did, and prefer impersonation when you only need to see what they see. Shell use is recorded in server logs only.
Launchable Reviews
Admin Panel → Labs → Instances → Launchable Reviews
(/admin/instances/reviews), headed "Launchable App Reviews".
Users who build a custom app can ask for it to appear on every user's home launcher. Those requests queue here.
- Approve (optional note) makes the app appear for everyone.
- Reject takes a note.
The app's owner is not reliably notified of your decision in this release. Tell them yourself if it matters.
Failed deploys
The admin Dashboard counts failed deploys, but there is no failed-deploy list in the panel yet. To investigate, open the lab's own page and its Deployments tab, which shows each attempt with its error. Retrying or rolling back a failed deploy on someone's behalf needs your engineering team in this release.
Admin-only controls on normal pages
Some admin features live on the ordinary dashboard pages rather than in the admin panel. You see them only while signed in as an admin.
| Where | What admins get |
|---|---|
| Profile menu → Global Stats | Platform-wide analytics |
LabStore (/store) | Install apps for the platform, with a live server log while they install |
Services catalogue (/services) | Running and total counts, and each service's runtime state |
Labs catalogue (/labs) | Platform-wide running counts and an Admin filter |
| Lab template editor | Publish to LabStore, where the platform has a GitLab publishing credential set up |
To start and stop the platform's own backend services, see Platform settings.
Next
- Users — impersonation and plan limits
- Storage quotas
- Certificates and VPN