RunPod alternative for Russia: pay in roubles, launch in minutes

RunPod is a foreign cloud platform for renting GPUs. Users start containers, called pods, from ready templates, pay for the time they run and connect through the browser or SSH. Using such services from Russia can be inconvenient, because many foreign platforms do not accept Russian bank cards. gpu.nz rents GPU servers by the minute to users in Russia: a balance in roubles, ready templates, a REST API and a command-line tool. For an overview of services for Russia, see where to rent a GPU for AI from Russia.

What to check when you choose

Compare prices against current rates: on gpu.nz they are on the pricing page, and RunPod's hourly rates are on its own website.

How to move a project

If your RunPod workflow is built on a Docker image and a volume with data, the move comes down to three things: the image, the data and the access.

1. The container image

On gpu.nz, choose the Your own Docker image template, enter the image name from Docker Hub or your registry, and list the ports to open. The form takes up to ten ports, and port 22 is reserved for SSH. The CUDA version in the image has to suit the server's driver; nvidia-smi on the server shows it.

The form does not take environment variables. Move anything you used to pass through variables into a launch script or into a config file inside the image.

The service inside the image must listen on all interfaces, not only on 127.0.0.1, otherwise the protected link cannot reach it. Check with ss -ltn, if the tool is installed.

2. Data and volumes

A persistent RunPod volume corresponds to the gpu.nz disk: it stays with the server until the server is deleted. Move data over SSH. For large amounts, rsync is more convenient because it can resume an interrupted transfer:

rsync -avP -e "ssh -p <port>" ./dataset <user>@<address>:/workspace/

Models and large archives are easier to download straight to the server by link with wget than to push through your own computer. Before you delete the old volume, check that the data opens and works on the new server.

3. SSH and web interfaces

Every gpu.nz server has SSH. Add your public key to your account before you rent; the SSH guide has the details. Web interfaces open through protected links of the form https://<id>-<port>.run.gpu.nz. A link works only with the rental token, so other people cannot open it.

4. Automation

If you started and stopped servers through the RunPod API, gpu.nz has a REST API. It lets you search offers, and create, start, stop and delete servers. The gpunz command-line tool covers most of the same actions from a terminal: search, create, SSH, stop and destroy. Its commands are described in the CLI documentation.

What does not carry over directly

gpu.nz rents whole servers: you start a server, work on it and stop it. The platform does not offer automatic scaling or a serverless mode, so that logic has to be built yourself, for example with the API on a schedule or with your own load balancer.

What you need for the move

• The image name with a pinned version tag, not latest: otherwise a later start may pull a different image.
• The list of ports the image listens on.
• The path to the data inside the volume and its size; check it with du -sh.
• The commands you used to start the service on RunPod. On gpu.nz you run them after connecting over SSH.
• Your public SSH key, added to your account before you rent.

Example: moving a data folder

A single archive is the simplest way to move a data folder. Pack the folder on the old server and unpack it on the new one:

tar -czf dataset.tar.gz -C /workspace dataset
# on the new server, after copying the archive:
tar -xzf dataset.tar.gz -C /workspace

For large sets of images or video, which are already compressed, an archive gains little. Copy the folder with rsync instead: it skips the packing step and can resume an interrupted transfer.

Before you delete the old volume, compare the checksum of the archive on both servers. The values must match:

sha256sum dataset.tar.gz

After the start

A gpu.nz server usually starts in 2 to 5 minutes, and the first start of an image with large weights takes longer. Do not assume your service starts by itself: after you connect over SSH, check whether it is running. Test the service from inside the server first, for example with curl http://localhost:<port>, and only then open the protected link.

If the service does not respond, read the process logs. The RunPod image may have relied on environment variables or volumes that the new server does not have. Replace those dependencies with paths inside the image or with files on the disk.

How to compare the cost of a task

Compare the cost of the whole task, not the price of an hour: how many hours of work the card needs on your data set, plus the time spent on setup. A card that finishes the job faster can cost less, even at a higher price per minute. Take the price from the catalogue and time the job with a test run.

During the move, keep enough balance for a few days of two servers running. Until the old pod is stopped, it is billed. Balance warnings arrive in advance, 24 hours, 3 hours, 1 hour and 15 minutes before it runs out, so there is time to top up without rushing.

Secrets and access

Do not put API keys or passwords into the image. Pass them with a command when you connect over SSH, or keep them in a file on the disk with restricted permissions. That way they do not end up in an image you might share.

If the move is complicated, for example because the image was built for a specific driver or needs a build step, it is simpler to prepare a clean server with Ubuntu + CUDA and install the environment with the same commands, rather than moving the image as a whole.

Questions to answer before the move

• Do you need all of the data, or only the models and the results?
• Is it worth keeping a model cache on the disk, so you do not download the models at every start?
• Does the service run in the background, and how will you restart it after a pause?

Before you move

1. Test the image on your own machine or on a small server before you move working data.
2. Copy the data and check the file sizes. Choose a disk with some room to spare: it is billed while the server exists, including while the server is stopped.
3. Stop the old pod on RunPod only after the check on gpu.nz is done, because two running servers are billed at the same time.
4. Stop the server after you finish work, and delete it together with its disk if you no longer need it. The guide on not overpaying for GPU rental explains what is billed.

Everyday work

Daily work on gpu.nz looks like work on RunPod: start the server, connect, work, stop. The difference is that stopping ends the processes and clears memory, so a service has to be started again after a pause. Put that step into a launch script and run it straight after you connect over SSH. Keep a copy of the script on the disk, so you do not have to dig commands out of the terminal history.

Model cache and volumes

On RunPod, volumes often serve as a Hugging Face model cache, so models are not downloaded again. On gpu.nz, move the cache together with your data if you need it, and point the HF_HOME variable at it in the launch script. Then each start finds the models on the disk and does not download them again.

Logs and card load

Write process logs to files on the disk and read them with tail -f. Watch the card's load with nvidia-smi -l 5: the output refreshes every five seconds until you stop it with Ctrl+C.

What to check after the move

• The service answers from inside the server and opens through the protected link.
• The data opens, and its checksum matches the old archive.
• The results match the earlier ones for the same input.
• The process survives an SSH disconnect: it runs inside tmux or as a service.
• The old pod on RunPod is stopped, and old copies of the data are deleted after the check.

A simple image with a modest amount of data moves in a single working session. Large volumes and complicated images take longer, so plan the move ahead of time, not on the day of a deadline.