# GPU cloud by location: how to pick a country for your GPU URL: https://cloudj.net/blog/gpu-cloud-by-location-guide Published: 2026-11-12 ยท Updated: 2026-11-12 > How GPU cloud by location works on Cloudj: filter a live list of machines by country code, decide between near users, lowest price or data rules. GPU cloud by location sounds like a dropdown of data centres, but on Cloudj it works differently, and knowing how saves you time. Cloudj GPUs come from a live inventory of independent host machines in many countries. You do not pick a Cloudj region; you filter that list by country code and choose a machine from what is listed right now. This guide explains how the filter behaves, what the results tell you, and how to decide which country to search in the first place. ## How GPU cloud by location works on Cloudj On the GPU deploy page in the console there is a **Country** field. It takes two-letter ISO country codes, for example `US`, `DE` or `JP`. You can type several codes at once, separated by commas or spaces, and the list then shows machines in any of those countries. The United Kingdom is `GB`, not `UK`, which catches many people the first time. Four things are worth knowing before you start: - **Country is the finest level.** Each machine in the results shows its country and nothing finer: no city, no data-centre name, no region inside the country. If you need a specific city, a GPU listing cannot promise it. - **Stock is live.** Which models are listed in which country changes during the day as hosts come online and machines are rented. A search that returns nothing in the morning may return several machines in the evening, and the reverse. - **Every machine is its own host.** Two RTX 4090 listings in the same country can differ in reliability, download speed, bandwidth price and how long they stay available. - **The list is sorted by total price**, lowest first, and shows up to 50 machines per search. For a screen-by-screen walkthrough of the deploy page, read [how to choose a GPU server country in the console](https://cloudj.net/blog/filter-gpu-by-country-console). The rest of this article is about the decision behind the search. ## What each result tells you When you search, each machine in the list shows: | Field | Why it matters for location | |---|---| | Country | The host's country; the only location detail you get | | Reliability | A percentage that reflects how dependable the host has been | | Max duration | How many days the machine stays available; the instance and its disk are removed at that date | | Datacenter badge | Shown when the host sits in a data centre; the "Datacenter only" switch filters to these | | Download speed | Matters when you pull large models or datasets | | Bandwidth price (down / up per TB) | Matters when you move a lot of data to or from that country | | Storage price | What you pay while the instance is stopped | Location is only one column. A machine one country farther away with better reliability and a longer max duration is often the better rent. The live "from" prices per model are on the [GPU cloud page](https://cloudj.net/gpu-cloud). ## Decide what location is for Before you type a country code, decide why location matters for this job. There are three common reasons, and they lead to different searches. ### 1. You serve users in real time A chatbot, an image generator behind a web app or a voice assistant sends every request to the GPU and waits. Here the distance between your users and the GPU host adds to every response. Search the country where most users are, then add neighbouring codes. Measure before you commit; [measuring latency to a GPU host](https://cloudj.net/blog/measure-latency-to-gpu-host) shows how to do it from your own location. ### 2. You run batch work Fine-tuning, LoRA training, rendering, transcription of an archive or embedding a document set does not care where the GPU is, as long as the data gets there. Leave the Country field empty or use a broad list, sort by price and check bandwidth prices. The trade-off is covered in [GPU near users vs cheapest GPU](https://cloudj.net/blog/gpu-near-users-vs-cheapest-gpu) and [batch inference in the cheapest region](https://cloudj.net/blog/batch-inference-cheapest-region). ### 3. Your data has to stay in certain countries Some teams want work kept inside a set of countries, for example only EU codes. The Country filter lets you do that at the machine level. It does not make any legal claim for you: check your own obligations and contracts. The [EU data location guide](https://cloudj.net/blog/eu-data-location-gpu-cloud) covers how to build such a search. ## A simple decision tree 1. Is the GPU in the request path of a live user? If no, search broadly and pick by price, reliability and bandwidth. Done. 2. If yes, where are most of those users? Start with that country's code. 3. Is anything listed for the model you need? If yes, check reliability and max duration, then deploy. 4. If nothing is listed, add neighbouring codes (for example `JP, KR, TW`), lower the minimum reliability a little, or drop the Datacenter-only switch. 5. Still nothing? Try a different model with similar VRAM, or accept a farther host and put a VPS near users in front of it. ## Where to start by region Each region has its own hub article with country codes, fallbacks and VPS pairings: - **Asia:** the [GPU cloud Asia guide](https://cloudj.net/blog/gpu-cloud-asia-guide) covers `JP`, `KR`, `SG`, `HK`, `TW` and nearby codes. Readers in Vietnam should also read [GPU cloud for Vietnam](https://cloudj.net/blog/gpu-cloud-vietnam): Cloudj has no data centre in Vietnam, you can try `VN` in the filter but machines there are not guaranteed to be listed, and `SG` and `HK` are the usual alternatives. - **Europe:** the [GPU cloud Europe guide](https://cloudj.net/blog/gpu-cloud-europe-guide) covers `DE`, `NL`, `FR`, `GB`, `PL`, `SE` and others. - **North America:** the [GPU cloud North America guide](https://cloudj.net/blog/gpu-cloud-north-america-guide) covers `US` and `CA`. - **Middle East:** [GPU cloud for the Middle East](https://cloudj.net/blog/gpu-cloud-middle-east) covers `AE`, `IL`, `TR` and the European fallback. ## Pair a GPU with a VPS when location must be stable Because a GPU machine has an end date and no hardware SLA, many teams keep the stable parts of a product on a Cloudj VPS: the domain, TLS, API gateway, queue and database. VPS locations are fixed cities in 14 countries, listed on the [cloud servers page](https://cloudj.net/cloud-servers). The GPU then becomes a replaceable backend that you can move between countries when stock changes. [A VPS front end for a GPU backend](https://cloudj.net/blog/vps-frontend-gpu-backend) explains the pattern. ## When Cloudj is not the right fit Be honest about the limits. If you need a guaranteed machine in one specific country every day, a named city or data centre, or a contract that commits to availability, a live list of independent hosts is the wrong tool. Cloudj works best when you can treat the GPU as replaceable: back up your data, script your setup, and redeploy where a suitable machine is listed. ## FAQ ### Can I choose a city for a GPU on Cloudj? No. GPU machines show their country only. City choice exists for Cloudj VPS locations, not for GPUs. ### Why did my country search return nothing? Stock changes during the day. Add neighbouring country codes, loosen reliability or bandwidth filters, turn off Datacenter only, or check again later. ### Is the country shown the host's real location? The country is the location the host reports for the machine, and it is the only location detail the console shows. ### Does a closer GPU always mean a better result? Only for real-time work. For batch jobs, price, reliability, max duration and bandwidth matter more than distance. ## Start your search Open the [GPU deploy page](https://app.cloudj.net/deploy/gpu), pick a model, type one or more country codes and see what is listed right now. Live "from" prices for every model are on [GPU cloud](https://cloudj.net/gpu-cloud), and the console shows the exact price before you deploy.