Workspace rentals

Choose a workspace image

The catalog includes accelerator- and architecture-specific variants. Current families include Ubuntu Workbench, PyTorch Notebook, a PyTorch compatibility release, vLLM API Server, Ollama + Open WebUI, and ComfyUI Studio. The selection screen shows the image version, badges, accelerator support, and advertised service ports.

New rentals use the chosen image revision. Existing rentals keep their original image when the catalog is updated. Fresh notebook images use Transformers 5; test projects written for Transformers 4 with a small model before starting longer jobs.

Images provide software, not your data or model weights. vLLM, Ollama, and creative workspaces may download models at runtime. Budget disk, startup time, and network transfer accordingly. A recommended badge indicates a useful default, not compatibility with every project.

Open WebUI is the chat application in the optional Ollama + Open WebUI workspace, separate from the Console's API playground. Custom embedding models that include Python code require an explicit trust setting. Review that code before enabling it; a model stored on disk is not automatically trusted.

Signing out of Open WebUI in this workspace invalidates all Open WebUI sessions for that account. Sign in again on any other browser or client you want to keep using.

Multiple GPUs retain separate device memory. Ubuntu workspaces provide GPU tools, but driver visibility alone does not establish that a framework or service can run on the selected hardware. The published PyTorch CUDA 12.8, ComfyUI CUDA 12.8 and vLLM stacks are unsupported on Pascal GPUs such as the GTX 1050 Ti. The catalog marks these combinations and GPU rental quotes reject them. Choose a compatible image; installing a different stack does not qualify the original published image.

Ollama and other applications need their own model and memory compatibility checks. A multi-GPU benchmark does not guarantee distributed inference, faster training, or automatic memory pooling. CPU-only slices receive no GPU performance claim. New rental details retain the measurements associated with allocation, including their date; they are distinct from live utilization. Historical rentals without an attributed snapshot show no per-device measurement.

Generate and install the rental profile

1. 01

   Wait for ready

   The Generate profile action stays disabled until the rental is active and its workspace is ready.
2. 02

   Generate

   Create the profile on the rental detail page. A profile contains a private key and allowed private destinations; treat the entire file as a secret.
3. 03

   Import or install

   Import it into the WireGuard desktop/mobile client, or save it as /etc/wireguard/wg0.conf on Linux and bring the interface up.
4. 04

   Verify handshake

   The Console reports waiting, stale, or connected plus the last handshake and rental peer IP. Do not troubleshoot SSH until the tunnel is connected.

# Linux example (review the downloaded file first)
sudo install -m 600 rental-1234abcd-wg0.conf /etc/wireguard/wg0.conf
sudo wg-quick up wg0
sudo wg show wg0

Connect with SSH

When ready, the rental shows its private SSH host, port, user, controller proxy status, and an exact example command. Copy that command. The public key selected at launch is already authorized in the workspace.

Each workspace has its own SSH server identity, retained when its container restarts. A different rental has a different identity even if a connection address is reused.

ssh -p <port> <user>@<wireguard-host>

If the client reports “Permission denied,” verify that it is using the private key matching the public key selected for the rental. If it reports a timeout, verify WireGuard handshake and allowed routes before changing SSH settings.

Open workspace services through SSH tunnels

JupyterLab, vLLM, Open WebUI, Ollama, and ComfyUI are not opened to the public internet. The rental page builds a local-forwarding command for every service port. Keep the SSH session running, then open the displayed 127.0.0.1 address in a browser or API client.

# Example for JupyterLab on port 8888
ssh -L 8888:127.0.0.1:8888 -p <ssh-port> <user>@<wireguard-host>
# Then open http://127.0.0.1:8888

If a local port is already occupied, use a different port on the left side, such as -L 18888:127.0.0.1:8888, then open http://127.0.0.1:18888.

Data, secrets, and shutdown

Assume workspace storage will be removed when the rental ends. Synchronize code and results to your own repository or object storage. Avoid baking long-lived tokens into notebooks, shell history, or model configuration. Rotate credentials if they were exposed inside an ended or failed workspace.

Stop writes, copy data, close tunnels, and then end the rental in the Console. Turning off WireGuard or closing SSH does not end billing.

Workspace isolation keeps the selected node and resource allocation through retries. SSH and sudo operate inside the workspace container; host namespaces, host storage and Kubernetes API credentials are not exposed. Supported GPU images use the allocated device resources without privileged host access. Public downloads and the workspace connection remain permitted, while direct access to other tenants is blocked.

A full-node workspace reserves the advertised capacity and still runs inside a container. It does not grant host administration or guarantee recovery of a provider machine's disk. Keep independent backups of important work.

The rental page includes Your rental reliability history, available only to you. It saves observed service interruptions, container restarts, and supported GPU measurements after a delay of at least six hours and five minutes. It remains useful after the raw chart window expires. See past rental reliability for coverage, sensor interpretation, and public aggregation rules. Historical chart windows for ended rentals end at that rental's completion time.