Skip to main content

Regions

Every offer names the place its machine physically sits. You see it on the offer card as a flag and a code such as US-CA or FI-HEL, and it follows the instance through deploy and onto the instance page.

What a region tells you​

A region is a location: a country, and a site within that country. It is a fact about the hardware, not a service tier. Two offers in different regions with the same GPU model give you the same GPU.

What it changes:

ConcernHow region affects it
Interactive latencyThe round trip between you and the machine. A distant region makes a shell feel sluggish and a JupyterLab cell slower to acknowledge, even though the work itself runs at the same speed.
Data transferMoving a dataset up or checkpoints down crosses that distance. The further away, the longer the copy.
Where your data sitsWhile the instance exists, your disk lives on that machine, in that country.

What it does not change: how fast the GPU executes your job. Once the data is on the machine, an hour of training in Finland is an hour of training in California.

The practical rule: pick a nearby region when you will be typing into a terminal or shuttling large files, and stop worrying about it for a job you launch and leave alone overnight.

Data location in plain terms​

Everything you write to the instance's disk — datasets, checkpoints, credentials you paste into a shell — is stored on that physical machine in that region until the instance is destroyed. Destroying deletes the disk.

If you have a rule about where data may be processed, the region field is the control you have over it. Read it as a statement of where the hardware is, not as a compliance certification.

Filtering by region​

The marketplace's Region filter narrows by country. Its list of choices is built from the offers in the catalog at that moment, so it shows the countries that have something to rent right now rather than every place Superheat has ever operated. To narrow to one site, put the region code into the search box, which matches the GPU model, the hostname and the region.

Through the API, the region parameter on GET /v1/offers accepts either a region code or a country code, so you can be as specific or as loose as you want:

# every offer in Finland
curl -s "$SUPERHEAT_API/v1/offers?region=FI&sort=price_asc" \
  -H "Authorization: Bearer $SUPERHEAT_KEY"

# only the Helsinki site
curl -s "$SUPERHEAT_API/v1/offers?region=FI-HEL" \
  -H "Authorization: Bearer $SUPERHEAT_KEY"

A filter is not a guarantee​

Choosing a region narrows the offers you can see. It does not reserve anything, and it does not make capacity appear.

  • If nothing in that region matches your other filters, the page is empty. The fix is to widen the filter, not to wait — there is no queue and no capacity request.
  • Availability moves. A region with four free 4× offers this morning can have none this afternoon, because other people rented them.
  • The choice applies to one deployment. Destroy that instance and deploy again, and you land wherever you pick at that moment. Instances do not migrate, and there is no setting that pins future deployments to a region.
  • Stopping an instance holds the exact machine you were on, so its region is held too. Destroying releases it.

If a specific region matters to your work, check the marketplace before you plan around it, and keep the instance stopped rather than destroyed when you intend to come back to that same machine.