Getting started
From an empty account to a GPU you can SSH into. It takes about two minutes, most of which is the image pull.
On this page
1. Add an SSH key
Every instance is reached over SSH, so RunKey needs your public key before it can hand you a GPU. If you do not have one yet:
ssh-keygen -t ed25519 -C "you@laptop"
cat ~/.ssh/id_ed25519.pubCopy the output — it starts with ssh-ed25519 — and paste it into Settings → SSH keys. Never paste the file without the .pub extension; that one is private and should never leave your laptop.
Keys are written into the instance when it boots, so the keys that matter are the ones on your account at the moment you deploy. Add them first.
2. Buy credits
Instances spend credits. Pick a pack on the Billing page — there is no subscription, and credits do not expire. The larger the pack, the lower the price per credit; the current packs and rates are on the pricing page.
Picking a pack opens a checkout page of ours showing what you are buying — the amount, the credits it is worth, and the ways to pay. Choose one and you are handed to that provider's own payment page. Card details are entered there and never pass through RunKey. When the payment confirms, the credits are on your balance and a top-up line appears on your statement, usually within seconds.
A few things worth knowing about that page:
- The checkout link is addressed by a payment id, not by your session, so you can send it to whoever is holding the card. It shows the purchase and nothing about your account.
- Changing your mind about the method is fine — go back and choose another. It stays the same purchase and only one lot of credits is ever delivered.
- That payment id, printed under the card, is the reference to quote if you ever need to write to us about a payment.
- If no method is offered, payments are temporarily unavailable rather than broken for you specifically. Write to support@runkey.ai and we will get credits onto the account.
You need at least one hour of an instance's rate on your balance before a deploy is accepted, which keeps an instance from starting only to be killed seconds later.
3. Deploy an instance
On the Deploy page you make three choices:
- GPU — A4000, 3090, 4090 or 5090. The credit rate is fixed per model.
- Node — the specific hardware your GPU comes from, with its vCPU count, RAM, disk, bandwidth and region. Every node listed has passed a reliability check and publishes the open ports that Direct SSH needs.
- Name — optional, only for your own bookkeeping.
There is no image to choose. Every instance boots the same one: Ubuntu with CUDA and cuDNN matched to the driver the node is running, plus an SSH server. What runs on top is yours to install.
Hit Deploy and the instance page opens. It moves through provisioning and starting while the node is reserved and the image is pulled, then flips to running. Billing starts at that moment, not before.
4. Connect over Direct SSH
Once the instance is running, its page shows a connection line you can copy straight into a terminal:
ssh -p 41277 root@198.51.100.24This is a direct connection to the instance, not a relay, so file transfers run at the node's own speed. You land as root. nvidia-smi works immediately, and so does torch.cuda.is_available() once you have installed a framework — the driver and CUDA are already matched to each other.
Moving files works the way you would expect:
# push a checkpoint up
scp -P 41277 sdxl.safetensors root@198.51.100.24:/workspace/
# pull your outputs back down
scp -P 41277 -r root@198.51.100.24:/workspace/output ./output5. The desktop panel
SSH is one way in. The other is the panel: every instance installs a full desktop environment that runs in a browser tab — a taskbar, windows you can move and resize, and a set of applications for working on the instance without a terminal in front of you. It finishes initialising about a minute after the instance starts, and the instance page shows Open panel once it is up.
Open panel opens it in a new tab, already signed in. The link it uses is valid for under a minute and is signed for that one instance, so there is no panel password to invent or store. The panel itself publishes no port — it reaches the outside through a tunnel of its own, which is why it works on a node behind NAT and why nothing about it is exposed to the internet at large.
What is in it
- Terminal — a root shell in the browser. The same shell SSH would give you, from a laptop that does not have your private key on it.
- File manager — browse the disk, upload and download, rename, unpack and edit files in place. Handy for dropping a config onto
/workspaceor pulling one image out of an output folder without reaching forscp. - Port forwarding — take something listening on
localhostinside the instance, like a ComfyUI or a Jupyter on8188, and reach it through the panel. It is the no-terminal equivalent of an SSH tunnel, and it means you never have to publish that port to the internet. - Task manager — what is running, what it is using, and a way to kill a job that has run away with the GPU.
- Resource monitor — CPU, memory, disk and network over time. The quickest way to tell a training run that is saturating the GPU from one that is waiting on the data loader.
- BitTorrent client — pull a large dataset or a model release straight onto the instance at the node's bandwidth, rather than down to your laptop and back up again.
There is more in the launcher than that list, and the set grows; open it and look.
What to keep in mind
The panel runs as root on your instance, so everything it does is real: a file deleted in the file manager is deleted, and a process killed in the task manager is killed. It is also part of the instance — the panel, its settings and anything you did through it go when the instance is terminated.
For moving real bulk — a 12 GB checkpoint — prefer scp over the Direct SSH connection. That goes straight to the node at its own speed, while a browser upload goes through our tunnel. Use the file manager for the things where convenience is the point.
6. Run whatever you need
The instance is a clean Ubuntu environment with the NVIDIA stack on it — nothing else is installed and nothing is listening. Install ComfyUI, a training stack, or pull your own container; the 80 GB at /workspace is the volume to keep things on.
If what you install serves a web UI, do not publish its port. Forward it over the SSH session you already have instead:
ssh -p 41277 root@198.51.100.24 -L 8188:localhost:8188Tools like ComfyUI ship without a login of their own, so an instance that published one openly would let anyone who found the address queue jobs on the GPU you are paying for. If you would rather not hold a terminal open for it, the panel's port forwarding does the same job from the browser.
7. Terminate when you are done
Hit Terminate on the instance page. The resources are released and spending stops immediately. Everything on the instance's disk is destroyed with it, so download anything worth keeping first.
How billing works
Each instance has a fixed credit rate per second — 0.0127 credits for an RTX A4000, 0.0294 for a 4090. RunKey meters from the moment it reports running until it is terminated, and draws the credits down continuously. Your statement groups usage into one line per instance per hour so it stays readable. If the balance reaches zero, running instances are terminated automatically — an account cannot quietly run up a debt.
Nothing is charged for an instance that never reached running, and nothing is charged after termination. The event log on the instance page carries the timestamps the meter used, so a line on the statement can always be traced back to an instance and a period.
How payments work
Payments are handled by a payment service and the card processors behind it. RunKey stores no card number, and the price you see on the processor's page is the price it holds for that pack — we send it which pack you picked, never an amount.
How much a payment is worth in credits is decided here, from the pack recorded when the purchase started. That is deliberate: nothing outside RunKey can change what a payment delivers, only whether it happened.
If a payment is taken and the credits do not appear within a few minutes, do not pay again — send us the payment id from the checkout page. Money that arrives and cannot be placed lands in a queue a person works through, and a double payment is refunded rather than absorbed.
Troubleshooting
The instance refuses my SSH key
Keys are installed when the instance boots, so a key added after an instance started is not on that instance. Add the key first, then deploy. Check you are connecting as root and using the port from the instance page, not 22.
The instance failed to start
Occasionally a node becomes unavailable between listing and launch. The instance is marked failed, you are not billed for it, and the event log on the instance page says what happened. Deploy again and the picker will offer a different node.
nvidia-smi says no devices
An instance reports running as soon as the container is up, which can be a second or two before the GPU is attached. Give it a moment and try again. If it persists, terminate and deploy again — you are not billed for an instance that never worked, and the next node will be a different one.
The panel button never becomes clickable
The panel sets itself up in the background after the instance boots, so it lags the runningbadge by about a minute. If it is still initialising after a few minutes, SSH in and read /var/log/vsh-install.log — a node with slow or filtered outbound networking is the usual cause, and terminating and deploying again lands you on a different one. SSH is unaffected either way.
I paid and the balance did not move
Reload the Billing page first; the credit lands when the processor confirms, which is usually seconds but can take longer on a card that goes through an extra verification step. If it still has not arrived, write to us with the payment id rather than starting a second payment.
Still stuck?
Write to us from the contact page with your instance ID — it is on the instance page — and we will look at what happened.