Cannot connect to a lab
Use this page when you cannot reach a lab through the tunnel (the WireGuard VPN between your device and your labs), SSH or the browser editor. Start with the one check that tells you which half the problem is in.
First: does VS Code in the browser work?
Open the lab and select Code. The browser editor needs no tunnel and no keys.
- It works — the lab is fine; the problem is between your machine and the lab. Go to Tunnel and SSH.
- It does not — the problem is the lab itself. Go to The lab or the browser editor.
The tunnel
| Symptom | Likely cause | Fix |
|---|---|---|
| WireGuard shows no handshake | The tunnel is not activated, or the device was deleted in the dashboard | Activate it. Check that the device still exists on My Devices; if not, add it again and import the new config. |
| Handshake, but nothing answers | The lab is stopped, so it has no address | Check that the lab is deployed. If it is not, deploy it. |
Handshake, but ping to an address fails | You pinged a network or gateway address | Ping the lab's own Device IP, shown on its page |
| It worked yesterday, not today | The device had no reserved address and was given a new one | Download the config again, and reserve the address |
| The lab's address changed | Stopping a lab releases its address | Use the Device IP on the lab's page now, or request a reserved address in the lab's Preferences |
| Imported config says the key is invalid | You registered your own public key, and the {private_key} placeholder was not replaced | Put your private key into the config on your machine |
| Works on one network, not another | That network blocks outgoing UDP | Try another network, such as a phone hotspot, to confirm |
| Device status stays Offline | The tunnel is not up on that machine | Activate it in the WireGuard app on that machine |
| Device status is No Connection | The tunnel has never connected from that machine | Import the tunnel file or QR code again, and check the key: if you use your own key, replace the {private_key} placeholder with your private key |
| The lab has no Device IP | You were at your device limit when the lab deployed. Running labs use device slots too. | Delete a device you no longer use on My Devices, then redeploy the lab. See Devices. |
| The lab has a Device IP but your device cannot reach it | Your device and the lab are on different private networks | Check the interface chip on both entries on My Devices. Add the device to one of the lab's networks, or add that network to the lab. See Private networks. |
SSH
| Symptom | Likely cause | Fix |
|---|---|---|
Connection timed out | Tunnel down or lab stopped | Fix the tunnel first — see above |
| Asks for a password | Your SSH key is not in the lab | Add it under Account Settings → SSH Keys, make sure it is enabled, then redeploy — keys are installed at deploy time |
Permission denied (publickey) | Wrong user name, or the lab uses a narrower key selection | Use the user from the SSH Command row. Check the lab's Preferences → SSH keys. |
REMOTE HOST IDENTIFICATION HAS CHANGED | The lab was rebuilt, and with it its host key | Remove the old entry: ssh-keygen -R <your-lab-ip>, then connect again |
Connection refused | The lab is running but SSH is not | Redeploy. If it persists, check the lab's Activity tab. |
SSH is private only
Port 22 is never published to the internet. SSH always goes through the tunnel.
The lab or the browser editor
| Symptom | Likely cause | Fix |
|---|---|---|
| code-server URL says Not running | The lab is not deployed, or its editor did not start | Redeploy the lab |
| The editor's password is rejected | You set a custom code-server password | Use your own password, not the generated one. Leaving the field empty generates a new one on each deploy. |
| Browser warns the editor's site is not secure | Certificate problem on its domain | See HTTPS not secure |
| Lab page shows it is paused | Paused labs are frozen | Select Resume |
| Lab is stopped and you did not stop it | Idle shutdown, expiry, CPU or memory | See Lab stopped unexpectedly |
| Lab never reaches deployed | The deploy failed | See Deploy failed |
A published app will not load
| Symptom | Fix |
|---|---|
| 502 or 504 error page | The app is not listening on the port you published, or it is still starting. Check it inside the lab with curl -I http://localhost:<port>. |
| Your domain shows nothing new | Domain and port changes apply only after a redeploy. Use Apply & Redeploy now. |
| Works over the tunnel, not publicly | The port is not published. See Publishing ports. |
Still stuck
Note the lab's name, when the problem happened, and what you tried. Then ask in community chat or contact your administrator.
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 |
|---|---|
| “I can't reach my lab over the VPN” | list_devices to see when your device last connected, then lab_status and lab_info |
| “SSH says permission denied” | Checks your keys with list_ssh_keys, then redeploys with deploy_lab so they are installed |
| “My published app will not load” | lab_status, lab_probe, then list_domains |
Keys and passwords arrive at deploy
A key or password you just added reaches a lab only when it is redeployed. If you never set a sudo password, the lab uses a fixed default, shown in its connection details.