Security
Laboratory OS is built to make a private remote workstation reasonably safe to expose on the public internet without asking the user to manage open ports, a public reverse proxy, or a collection of manually shared secrets.
In practice, its security model is based on four ideas:
- Run all workloads inside a Docker container with OS-level sandboxing
- Access through an outbound tunnel rather than host port exposure
- Separate authentication patterns for admin desktop and shareable apps.
Container Sandboxing
Laboratory OS runs inside a Docker container, which provides OS-level isolation between your workloads and the host machine. The container has its own process namespace, filesystem view, and network stack. Code running inside the container cannot directly affect the host OS, other containers, or hardware outside its namespace.
This containment layer applies to everything running in the environment: installed apps, notebooks, servers, and any processes you start. This container boundary is enforced by the Linux kernel.
When the /workspace volume is mounted into the container, persistent files survive container restarts. Everything else is scoped to the container’s lifetime, no data from the container is saved to external servers.
Network Tunnel Access
Laboratory OS uses an outbound tunnel. Your container connects out to the assigned OpenTunnels relay, and external traffic is sent back through that existing connection.
For a user, the main benefit is simple: you do not have to expose local ports, run a public nginx instance yourself, or open inbound firewall rules just to reach the machine remotely.
Sharing Apps
Published app tokens are meant for narrow external sharing. They exist so you can expose one app without exposing the whole workstation. For any served app or API, a token can be generated that can be used externally to access that specific service.
Desktop And Tool Access
The Laboratory OS desktop is the most privileged surface. Once someone has the desktop, they can usually reach the rest of the user-facing tools on the machine.Tools like VS Code, terminals, file browser, and Jupyter sit behind the strict desktop authentication system.
The Laboratory desktop is accessed through your openlaboratory.com account. You can launch it from the account page or open the laboratory URL directly. Either way the managed edge authenticates you with your Open Laboratory account (SSO) before the request reaches the container — only your signed-in account can reach the desktop.
Data And Control
Your workloads run in your own container on infrastructure you control. Your models, files, and installed apps live in the mounted /workspace volume on your machine or VM.
Open Laboratory provides the authentication system and connectivity layer. It does not change the fact that the actual workload and storage are yours.
Bottom Line
Laboratory OS is secure in the ways that matter most for a self-hosted remote workstation: it avoids direct inbound exposure, keeps the desktop behind its own session, and separates published app sharing from full workstation access.
That does not make it risk-free. If you install untrusted software inside your container, that software is still running on your machine. The platform can reduce exposure from the outside; it cannot make arbitrary code safe to run.