Stop, pause and delete
Stop, Pause and Terminate each keep different things and remove different things, so they are not interchangeable. The table below sums them up, and the rest of the page gives the detail.
| Stop | Pause | Terminate | |
|---|---|---|---|
| The running lab | Shut down and removed | Frozen, memory kept | Destroyed |
| Your home directory | Kept | Kept | Shared home: untouched. Isolated copy's home: moved to trash, or erased with Delete permanently |
| Everything else in the lab | Reset on next deploy | Kept exactly as it was | Gone |
| Your private tunnel address | Released | Kept | Released |
| Attached domains | Released, but kept in the lab's settings and attached again on the next deploy | Kept | Released |
| Counts toward your running-labs limit | No | Yes | No |
| Restart with | Deploy | Resume — instant | Restore from trash, within 30 days |
Pause is the gentle option. It freezes the lab as it is — running processes, memory, your tunnel address — and resumes instantly. Stop removes the running lab; only your home directory comes back.
Stop
Shuts the lab down and removes the container. Your home directory is untouched, so your files are waiting when you deploy again — but anything you installed outside your home directory is gone, and the lab's tunnel address is released.
Use it when you are done for a while and want to free your running-lab slot.
Stopping also:
- clears the lab's expiry timer — the next deploy starts a fresh one
- fails any challenge mission you had in progress in that lab
- in a scale group, hands the group's domain to a replica that is still running, so the site stays up
A lab with always-on switched on is deployed again within about ten minutes of a Stop. Turn always-on off first if you want it to stay down.
Pause and resume
Freezes the lab in place. It uses no CPU, keeps its memory, keeps its address, and comes back instantly with every process exactly where it was.
Use it when you are stepping away mid-task.
- Only a running lab can be paused. The pause button sits next to Stop on the lab's page; a paused lab shows a paused badge and a Resume button instead.
- A paused lab still counts toward your running-labs limit. Stop it if you need the slot.
- Redeploy on a paused lab replaces it with a fresh machine — the frozen state is lost.
If the lab is part of a scale group and has no health check configured, a paused replica stays in the load-balancer pool and traffic keeps being sent to it. Configure a health check, or stop the replica instead.
Paused by the platform
An administrator can pause a lab on the platform's behalf — for example, because a subscription lapsed. Resume then refuses with This lab was paused by the platform (subscription). Renew your plan to resume it. Once your account is on a paid plan again, Resume works and everything is as it was.
Terminate
Destroys the lab and frees its slot. You can terminate only extra copies. Your main lab of a given type is a permanent record, so it is stopped instead of destroyed.
Only the owner can terminate a copy, unless they granted the Terminate extra when sharing it. You cannot terminate a copy while it is deploying — wait for the deploy to finish.
Terminate offers two options:
| Option | What happens |
|---|---|
| Move to trash (default) | The copy's full configuration — and, for an isolated copy, its data — is recoverable for 30 days |
| Delete permanently | Immediate and irreversible. An isolated copy's data is erased. |
Either way, the copy's tunnel address and domains are freed at once. A copy that used your shared home leaves your files where they are — they belong to every lab you run.
The trash panel shows each item with the number of days before it is purged automatically. Restoring brings it back as a copy with its configuration and data intact.
A restored copy comes back not deployed, in a new slot — select Deploy on its row. Restoring needs a free copy slot, the same as creating one.
Redeploy
Redeploying rebuilds the lab from its image and reapplies your saved settings — passwords, SSH keys, startup script, routing.
Redeploy to apply most configuration changes. It costs nothing, and it resets the expiry clock.
Your home directory survives. Everything else is rebuilt.
When labs shut down on their own
| Situation | What happens |
|---|---|
| The lab has a session timer | Challenge labs run for a set time, then stop |
| You have not signed in for a while | Running labs are stopped — your home directory is kept |
| Sustained heavy CPU use | You are warned, then the lab is stopped |
| Your plan is downgraded | Labs over your new running-labs limit are stopped |
Session timers and Renew
Some labs — most challenge labs, and some machine labs — run for a fixed time from the moment they were deployed. While one runs, its page shows an Expires in countdown with a red bar.
When the countdown reaches zero, the lab is stopped, any challenge mission in progress fails, and you get a notification.
To get more time, select Renew on the lab's page:
- The dialog shows the Cost in Jolt and the Extended Time you get.
- Drag the slider to choose how much time to buy — the cost updates as you go.
- Confirm. If you do not have enough Jolt, the renewal fails.
Renew appears only while the lab is running. You need to be the owner, or an Operator or Manager on a shared lab. How much time a renewal buys and what it costs are set by the lab.
Redeploying starts a fresh timer from zero. Between challenge missions that is a free way to get more time; after a paid renewal it throws the renewal away.
Idle labs
The platform stops running labs whose owner has been away for a long time:
| Plan | Stopped after | Measured from |
|---|---|---|
| Free | 7 days | Your last activity on the platform |
| Paid | 1 month | Your last sign-in |
These are the defaults; your platform may use different windows. Free-plan users get a notification when a lab is stopped this way.
Your home directory is kept. Deploy again to carry on. Labs with always-on are never stopped for idleness, and neither are labs owned by an organization.
Plan downgrades
If your plan changes to one with a lower running-labs limit, the labs over the new limit are stopped — the ones deployed longest ago first — and always-on is switched off on them so they stay down. You get a notification saying how many were stopped. Home directories are kept; redeploy the ones you want within the new limit.
A lab set to always-on is brought back automatically after an unexpected stop.
If a lab stops and you are not sure why, its Activity tab lists recent lifecycle events and who or what caused each one.
Do it with an AI assistant
You can also do this by asking an AI assistant connected to your account — see Connect an AI assistant to set one up.
| Ask | What the assistant does |
|---|---|
| “Stop all my running labs” | Lists them with list_labs, then stop_lab for each one |
| “Pause my lab, I'll be back after lunch” | pause_lab — and resume_lab when you ask it to continue |
| “Redeploy my ubuntu lab” | deploy_lab, then waits with wait_for_deploy |
| “Delete my testing copy” | Finds the copy's id with list_labs, then terminate_lab |
A redeploy rebuilds the lab from its image: your home directory survives, anything installed elsewhere does not. Terminate removes a copy for good. Check that the assistant names the right lab before it goes ahead.