Secure tunnels and networking
Your labs are private by default. Nothing about them is on the public internet until you publish it. This page explains the ways into a lab and how each one is secured.
The ways in
| Way in | Who can use it | Secured by |
|---|---|---|
| VS Code and terminal in the browser | You, and people you shared code access with | Your signed-in session, over HTTPS |
| Private tunnel (SSH, any port) | Only your registered devices | WireGuard encryption, one key per device |
| Public domain | Anyone, only for the domain and port you publish | HTTPS with an automatic certificate |
| AI assistant (MCP) | Clients you connected and approved | OAuth sign-in plus a per-command permission. See How MCP connections are secured |
The private tunnel
Each device you register (laptop, phone, server) gets its own WireGuard tunnel to the private network your labs are on. WireGuard is a modern, audited VPN protocol. All traffic between your device and your labs is encrypted.
- One key per device. Each device has its own key pair and its own address. Losing one device means deleting one device, not changing everything.
- Keep your private key private. Choose Auto Generate Keypair for convenience, or register your own public key. With your own key, the platform never sees the private half, and the configuration it gives you has a placeholder you fill in on your machine. With Auto Generate, the platform keeps the private key, so anyone signed in as you can download the tunnel file again. Another reason to protect your account.
- Deleting a device cuts its tunnel immediately. Do it the moment a device is lost or you no longer use it.
- Reserved addresses keep a device's address stable for firewall rules and SSH configs. See Private networks.
Set up a device: Devices.
A downloaded tunnel file or QR code contains the device's private key when the platform generated it. Anyone with that file can join your private network as that device. Do not share it, commit it to Git, or paste it into a chat.
SSH over the tunnel
SSH into a lab goes through the tunnel, using the SSH keys in Account Settings → SSH keys. Keys are installed when a lab deploys. Switch off or delete a key you no longer trust, then redeploy. See Connect to a lab.
The private network is shared
By default, your devices and labs join one private network together with other users' devices and labs. It is private from the internet, not from other users. Anything your lab listens on there can be reached by them, so:
- Put a password on every service you run: databases, admin panels, notebooks, dev servers.
- Bind anything that only you need to
localhost(127.0.0.1), and reach it over SSH port forwarding. - Do not assume a port is safe because it is not published.
Separate networks for organizations
An organization can have its own private network that only its members' devices and labs join. It can be shared with other people or groups using the Use role. See Private networks.
Publishing: an explicit choice
A lab becomes reachable from the internet only when you do both:
- attach a domain to it, and
- publish a port on that domain.
Published sites get HTTPS automatically, with certificates issued and renewed for you. See HTTPS certificates. Unpublish a port or detach the domain, and it is private again.
Publish only the port your users need. Keep database admin tools, dashboards and debug servers private, and reach them over the tunnel instead.
Your lab is isolated
- Each lab is its own container. Being root in a lab means root inside that lab only, not on the server, and not in anyone else's lab.
- Your home storage is yours. It is shared across your labs, not with other accounts, unless you give someone code access to one of your labs.
- Labs are stopped after long idleness, and inactive free accounts are suspended (see Plans and limits), so forgotten labs do not stay exposed forever.
Checklist
- Register each device separately. Never copy one tunnel file to several machines.
- Delete devices you no longer use, and any you lose, straight away.
- Prefer your own key pair for servers and shared machines.
- Publish only the ports that need to be public.
- Password-protect services on the private network, or bind them to
localhost. - Remove SSH keys you no longer trust, then redeploy.
- Give code access on a shared lab only to people you fully trust.