GPU blades and sessions

A blade is one GPU machine that razorBridge provisions for you on demand and takes away again when it is no longer needed. You reach it over SSH. There is no console to configure, no image to build and no capacity to reserve in advance — which is also why a blade is disposable, and why nothing on its disk survives teardown.

Sessions and events

Every blade comes from one of two flows, and the difference decides who pays and who controls its lifetime.

	Self-serve session	Event blade
Started by	You, in the web app	The schedule, before the event starts
Paid by	Your credit balance	The organizing account’s balance
Lifetime	A duration you choose	The event’s start and end times
Stopped by	You, or the duration expiring	Automatic teardown after the event
Extending	You, in the web app	The organizer, for the whole event

Both kinds appear in rb blade list and both are billed at the same published hourly rate for the GPU type.

What you actually get

A blade is a GPU host running your workload inside a container, with one Linux account per user. Your credentials are a username, a port and a password on the blade’s IP address — for example user01 on port 2201. The API hands them out only to the person the blade belongs to, and records the first time they were read.

Because access is password-based rather than key-based:

• rb blade ssh and rb run supply the password automatically if sshpass is installed, and otherwise print it once so you can paste it.
• An SSH config block from rb blade config works with any SSH client, VS Code Remote-SSH or JetBrains Gateway, but those clients will prompt for the password.

An event can also put more than one user on the same machine (the organizer sets Users per blade, which defaults to one), in which case each participant gets their own container and their own port on a shared GPU host.

Blade statuses

rb blade status and rb blade list report one of six values:

Status	Meaning
pending	Accepted, not yet handed to a provider
provisioning	The machine is being created and configured
running	Ready — you can connect
stopping	Teardown in progress
stopped	Gone. Billing for it is final
failed	Provisioning or a health check failed. Not billed for runtime

There is no idle status and nothing observes whether you are actually using a blade — see Limits and guardrails for what does stop it.

Lifecycle of a self-serve session

1. You pick a GPU type and a duration of 1, 2, 4 or 8 hours in the web app under GPU Sessions.
2. Before starting it, razorBridge checks that your balance covers the whole duration, that you are under your concurrent-blade limit, and that the session would not exceed your monthly spend cap.
3. The blade is provisioned. This usually takes a few minutes; the row updates from Pending through Provisioning to Running.
4. Select SSH on the row to reveal the connect command and password, or use rb blade ssh.
5. You can extend a running session by 30, 60 or 120 minutes, as many times as you like, up to the maximum total session length for your account.
6. The session stops when the duration expires, when you choose Stop, or if its accrued cost reaches your balance. You are charged for the time it ran.

An expiry warning email is sent for self-serve sessions roughly 10-15 minutes before auto-stop. Do not rely on it as your only reminder.

Lifecycle of an event blade

1. The organizer schedules an event with a start time, an end time and a GPU type.
2. Participants join with the event’s code, or are added by the organizer.
3. Blades are provisioned shortly before the start time — 30 minutes ahead by default. Joining earlier does not create a blade earlier.
4. Each participant receives an email when their GPU is ready, containing the host, port, username and ready-made SSH command. The password is not emailed: fetch it with rb blade ssh, or GET /v1/blades/<id>/ssh/.
5. Blades are torn down a few minutes after the event’s end time. Participants get no warning before this happens.
6. The organizer’s account is charged once, for the total runtime of every blade the event used.

If a blade fails a health check while its event is still running, razorBridge terminates it and provisions a replacement. The replacement has new SSH credentials, so run rb blade ssh again rather than reusing the old command — and note that the replacement starts with an empty disk.

Limits and guardrails

These defaults apply to a new account and can be raised per account on request:

Limit	Default
Concurrent self-serve blades	2
Longest single session	8 hours
Spend per calendar month	€50

Two more safety behaviours are worth knowing about:

• Balance-triggered teardown. A running self-serve blade whose accrued cost reaches your available balance is stopped immediately, without waiting for its duration to expire.
• Orphan reaping. A blade stuck in pending or provisioning for more than 20 minutes is terminated and marked failed; a blade still running well past its expiry is torn down. Nothing needs to be cleaned up by hand.

Nothing stops an idle blade. A session you forget about bills for its full duration, whether you were connected or not.

Caution

The blade’s filesystem is discarded at teardown, and neither auto-stop nor an event’s end is preceded by a reliable warning. Copy results off the blade as you produce them — rb blade scp blade:~/outputs/metrics.json ./ for a single file, or rsync -avP rb-abc12345:~/outputs/ ./outputs/ once you have an SSH config block — rather than at the end of the session.

Related pages

• Quickstart — get onto a blade for the first time.
• Credits and billing — how runtime turns into a charge.
• CLI reference — rb blade, rb run, rb status.
• Run an event — the organizer’s side of the event flow.