Deploy and redeploy
Deploying turns a lab from a catalog entry into a running machine. Redeploying throws the running machine away and builds a fresh one with your saved settings. By the end of this page you will know what each one does, what you see while it runs, and where to look afterwards.
Deploy a lab
- Open the lab from Labs. A lab that is not running shows a large Deploy button.
- A Confirm Deploy? dialog opens with the lab's settings — networking, domains, HTTP proxies, SSH keys and, where the lab offers them, TCP ports. Check them, or leave the defaults.
- Select Confirm Deploy.
If something in the dialog is not allowed — a reserved port, the same port listed twice, a domain another lab is using — you get a message and the dialog stays open so you can fix it. Nothing has started yet.
Passwords, the startup script and always-on are not in this dialog. They live on the lab's Preferences tab and are applied on every deploy.
Checks before anything starts
The platform refuses a deploy straight away, with a message, when:
- you are already running as many labs as your plan allows
- a deploy of the same lab is already in progress
- your storage is being moved to another pool
- a domain in the settings is not on your account, or is attached to another running lab
Every message and its fix is in Deploy failed.
While it deploys
- Where
- Dashboard, Labs, open a lab, just after clicking Confirm Deploy
- What it shows
- The lab banner showing the 'Deploying…' progress bar with its percentage, and the Server Logs panel at the bottom of the screen streaming deploy lines.
| What you see | What it means |
|---|---|
| Deploying… bar under the lab's buttons, with a percentage | Progress of this deploy. The pace is an estimate based on how long this lab usually takes, corrected as real steps finish. |
| Server Logs panel at the bottom of the screen | The deploy's log, line by line. It opens by itself even if you had minimized it. |
| An Error dialog | The deploy reported an error. The dialog shows the reason — read it before trying again. |
| A Warning dialog | Something worth knowing that did not stop the deploy. |
When the deploy finishes successfully, the page refreshes itself and the lab shows as running, with its Code or Launch buttons. If it fails, the progress bar disappears and the log ends with Deploy finished with status: followed by the result.
You can leave the page while a deploy runs — it carries on without you.
The bar moves at the pace of this lab's recent successful deploys, then jumps as each real step completes. A deploy that is slower than usual — a large image, a long startup script — sits near a milestone for a while. Watch the log to see what it is doing.
Redeploy
A running or paused lab has a Redeploy button. It opens Confirm Redeploy? — the same settings dialog — and then:
| Kept | Reset |
|---|---|
| Your home directory | Everything outside your home directory |
| Your saved preferences, domains and proxies | Running processes and memory |
| Your reserved address, if you chose one | The expiry timer, including any time you bought with Renew |
| The browser-editor or launch password, unless you set your own |
Redeploying costs nothing. It is how most setting changes reach a running lab, and the cure when a lab is half-working.
Redeploying a challenge lab while a mission is in progress fails that mission. The dialog warns you before you confirm.
Who can deploy
| You are | Deploy / Redeploy |
|---|---|
| The owner | Yes |
| An Operator or Manager on a shared lab | Redeploy the owner's lab — it stays the owner's |
| A Viewer | No |
The Activity tab
Open the lab and go to Activity. It has two cards.
Recent lifecycle
The last 25 things that happened to this lab, newest first, each with who and when:
| Who | Meaning |
|---|---|
| You | You did it in the dashboard |
| A person's name | Someone you shared the lab with did it |
| Your agent · via MCP | An AI assistant connected to your account did it |
| Admin · name | A platform administrator did it |
| System | The platform did it on its own — expiry, a CPU limit, always-on, a crash |
| Event | Meaning |
|---|---|
| Started / Redeployed | A deploy finished |
| Stopped | Someone selected Stop |
| Auto-stopped · expiry | The session timer ran out, or the lab was idle too long |
| Auto-stopped · high CPU | Sustained heavy CPU use |
| Auto-started · always-on | Always-on brought it back |
| Paused / Resumed | Frozen and unfrozen |
| Out of memory (OOM) | A process inside was killed for using too much memory |
| Crashed | The lab's main process exited on its own |
| Stopped unexpectedly | The machine disappeared without a normal stop |
| Admin stopped it | An administrator stopped it |
| Health check failing / Health recovered | The template's health check stopped or started passing |
What to do about each one is in Lab stopped unexpectedly.
Deploy attempts
Below the timeline, Deploy attempts lists the last 15 deploys of this lab and whether each one worked:
| Field | Meaning |
|---|---|
| Badge | succeeded, failed, or running for one still in progress |
| When | How long ago it started |
| took Ns | How long it ran |
| exit N | The result code. 0 means success. |
| A name | Who started it |
| Red text | The error, when it failed |
An amber note — The deploy command failed but a container is running — means the machine came up but a later setup step did not finish. Redeploy it. See Deploy failed.
Next
- Lab settings — what every deploy applies
- Stop, pause and delete — the other half of the lifecycle
- Deploy failed — every refusal message and its fix