Choose a Provider
Laboratory OS is a Docker image, so provider choice mostly comes down to how much of the host you want to manage.
| Option | Best when | You manage | Start here |
|---|---|---|---|
| GPU virtual machine | You want a durable workstation and full control | Linux, Docker, NVIDIA drivers, storage, and updates | GPU virtual machine |
| Managed container platform | You want quick, disposable GPU capacity | Image settings, environment variables, and persistent storage | Managed container platform |
In either case, confirm these capabilities before paying for a resource:
- the GPU has enough VRAM for your models;
- the platform can run the
openlaboratoryorg/laboratory-osimage with NVIDIA GPU access; - outbound HTTPS and tunnel traffic are allowed;
- logs are available so you can read the assigned Laboratory URL;
- a durable volume can be mounted at
/workspaceif you want to keep apps, models, and settings; and - billing stops, or drops to storage-only charges, when you stop the resource.
No inbound application ports are required. If a virtual machine needs SSH for setup, restrict port 22 to your own IP and remove it when you no longer need it.
Provider starting points
These are links to provider home or compute consoles, not provider endorsements. Interfaces, GPU availability, quotas, and pricing change frequently; use the provider’s current documentation when creating the resource.
Virtual machines: AWS EC2, Google Compute Engine, Microsoft Azure, DigitalOcean, Oracle Cloud, Akamai Cloud, Alibaba Cloud, Lambda, Nebius, Paperspace, TensorDock, Verda, and Vultr.
Container platforms and marketplaces: Runpod, Vast.ai, JarvisLabs, and Salad.
If a provider offers both models, choose based on whether you need host control or fast container startup—not on a provider-specific Laboratory OS integration.