ClodeiCLODEI
April 22, 2026 · 4 min read

From signup to running model in 60 seconds: a Clodei walkthrough

What happens between clicking 'Launch a GPU' and your first inference. A literal click-by-click of Clodei, with timings.

A lot of GPU rental flows in 2026 are still 30-minute affairs. Pick a region, request a quota increase, wait for approval, configure networking, debug an SSH key, eventually get a JupyterLab tab. We measured ours at 60 seconds end-to-end and we want to keep it that way. Here is the literal click-by-click.

What "60 seconds" includes

We measure from the moment you click Launch a GPU on the homepage until a JupyterLab tab loads in your browser, on a fresh account. That covers:

  • Account creation.
  • Email verification.
  • Plan selection.
  • Provisioning the GPU container.
  • DNS propagation for the per-instance hostname.
  • Cloudflare tunnel handshake.
  • Traefik routing the request to the container.
  • JupyterLab serving its first page.

Roughly half the time is provisioning. The other half is networking handshakes and JupyterLab's own startup.

Step 1: Sign up (~10 seconds)

Click Launch a GPU on the landing. You go straight into a single-step form: email, password. No company size. No "select your role". No marketing checkboxes.

You get a magic-link email. The link confirms your email and signs you in at the same time. No separate "log in" step.

Step 2: Pick a plan (~10 seconds)

You land on /plans with the four standard tiers visible:

  • S (24 GB VRAM): €0.39/h. Small models, short fine-tunes.
  • M (48 GB VRAM): €0.64/h. 7B–13B class.
  • L (80 GB VRAM): €1.73/h. A100 80GB tier.
  • XL (141 GB VRAM): €3.46/h. H200 territory.

The tile shows the per-hour price, the GPU class, and the recommended workload. There is no separate "configure region" step. Clodei is EU-only, so the region is implicit.

You pick a plan and click Launch.

Step 3: Provisioning (~25 seconds)

What happens behind the scenes:

  1. The control plane reserves capacity on a node that has the right GPU available. If no capacity is available, the API responds with 409 Conflict immediately. No instance gets created in failed state. (This is one of the contracts in our internal docs that we do not bend.)
  2. The node agent receives a launch command, pulls the Docker image (cached on most nodes), starts the container with GPU passthrough.
  3. JupyterLab and SSHd start inside the container.
  4. The node opens a Cloudflare tunnel for i-<instance-id>.clodei.com.
  5. Traefik on the node accepts the routing rule for /i/<instance-id>.

Step 4: Open JupyterLab (~15 seconds)

The dashboard polls the instance until ingress is healthy. As soon as the tunnel handshake completes, the Open JupyterLab button activates. Click it, a new tab opens, JupyterLab loads.

You're in. From here you can:

  • Open a notebook and import torch.
  • Use the bundled clodei CLI to manage your runtime.
  • SSH in via ssh-i-<id>.clodei.com with the key you registered (for non-Jupyter workflows).

The container is yours until you stop it. Per-minute billing means leaving it running for an extra five minutes while you Slack a colleague costs about €0.04 on a Plan S. That is the kind of margin you do not have to architect around.

What we don't ask you to do

A short list of things hyperscalers make you do that Clodei deliberately doesn't:

  • Quota increase tickets. Launches are not gated behind support tickets. The only limit is your wallet.
  • Region selection. EU-West is the default. If we add regions in the future, they will be opt-in.
  • VPC, subnet or security group config. The instance is reachable through the Cloudflare tunnel. Nothing else is exposed. No NACLs to debug.
  • IAM roles for storage. S3-compatible storage is provisioned with the instance and accessible via env vars.
  • Choosing instance type by SKU code. Plans are S, M, L and XL. The underlying GPU is named in the plan card.

The fewer decisions you make at launch, the faster you launch.

What's actually happening on the node

For curious infra folks, here is what the node agent does, briefly:

  1. Receives a job descriptor from the control plane (image, GPU mode, env, networking class).
  2. Pre-flights two gates: GPU runtime is healthy, ingress is reachable. If either fails, the launch fails with an actionable error code (gpu_runtime_unavailable, ingress_unavailable, corporate_network_restriction).
  3. Runs docker run with --gpus, the customer's image, env vars, and the right network attachment.
  4. Health-probes the container's :8888 (Jupyter) and :22 (SSH).
  5. Tells the control plane that the instance is running.

The state machine is provisioning → pending → running → stopping → terminated|failed. It is deterministic. There is no place for an instance to vanish into "unknown".

Why we care about the 60-second number

Cold-start latency for a developer experience is one of those metrics that compounds. If launching a GPU is a 30-minute project, you launch one a week and treat the GPU as scarce. If it's 60 seconds, you launch one for every coffee and stop it on the way back. Behaviour around the platform changes, and the bill changes with it (smaller, surprisingly, because you stop leaving GPUs running "just in case").

That is the design intention. Try it. See if 60 seconds holds for you. Tell us where it doesn't.