Worker

Rent a GPU

Running your own worker means owning (or renting) a machine with a GPU and installing Pendra on it. Rent a GPU skips all of that: choose a GPU and the jurisdiction it may run in, and a few minutes later a fully configured worker appears in your organisation, ready to serve models. You're billed by the hour, and you can stop it at any time.

On-demand GPUs are pay-as-you-go: before you can rent one, add a payment card and top up your credit balance. Renting then draws down that balance by the hour. See Credits & payment below.

Renting an instance

  1. Open Workers and click Add a Worker.
  2. Choose On-demand GPU.
  3. Optionally, pick the model you want to run — and the precision to run it at. Pendra then shows only the GPUs that can run that choice, suggests one, and installs it for you automatically once the instance is up, so it's ready to serve the moment it connects. Leave this blank to browse every GPU and install models yourself later.
  4. Choose where it may run (see below). This defaults to UK Sovereign.
  5. Pick a GPU — each card shows its memory and its price for the jurisdiction you chose. A GPU with no capacity right now is marked Currently unavailable.
  6. Click Rent.

The instance boots, installs everything it needs, and connects to your organisation automatically — usually within a few minutes. It appears in your Workers list straight away as a loading row and moves through each startup stage — finding a GPU, booting the instance, installing the Pendra worker, then downloading any model you chose — before settling in as a normal connected worker.

A rented worker is yours to manage like any other: open its worker page to install or remove models, change its settings, and rename it. Its running cost and uptime, and the Stop button, live on that page too. To end a rental, use Stop (see below) rather than deleting its worker key.

Choosing where it runs

You don't pick a cloud provider — Pendra does that, and may use different infrastructure at different times depending on what's available. What you choose is the jurisdiction it has to stay within:

  • UK Sovereign — runs in the UK, on hardware operated by a UK-domiciled company. Neither the data centre nor the company running it falls under a foreign jurisdiction.
  • UK Hosted — runs in a UK data centre, but the operator may be a foreign-owned company. Your data stays in the UK; the operator may still be subject to laws elsewhere.
  • Europe Hosted — runs in a European data centre (the UK, the EEA or Switzerland). The operator may be foreign-owned. Choose this when your data must stay in Europe but doesn't have to stay in the UK.
  • Global — runs wherever there is capacity. Cheapest, and appropriate when the workload has no residency requirement.

A jurisdiction only appears if you're allowed to use it, and a GPU with no capacity in the one you've chosen is marked Currently unavailable rather than letting you rent something we can't deliver. Capacity can still change between loading the page and renting, in which case the rental fails cleanly rather than running somewhere you didn't ask for. We never place a workload outside the jurisdiction you chose. If we can't honour it, the rental fails and tells you so.

Your organisation may have a minimum jurisdiction set, in which case any weaker options simply don't appear — you'll only see the ones you're allowed to rent.

Proving where it ran

Every rental keeps a record of where it was actually placed: the operator and its legal entity, the country it is domiciled in, the data-centre region, and the exact version of the jurisdiction rules that applied at the time. If you need to evidence a residency claim to an auditor, that record is what to use.

Credits & payment

On-demand GPUs run on prepaid credit. Under Settings, an organisation owner adds a payment card and tops up the wallet — the minimum top-up is £20. A card on file and a positive balance are both required to rent.

Your balance is made up of two parts, shown separately:

  • Wallet — credit you've purchased by topping up. It never expires.
  • Free credit — when you first upgrade to Pro you get a one-off £99 of GPU credit (roughly the cost of a month of Pro, back as credit) to spend on on-demand GPUs. It's use-it-or-lose-it: it expires 90 days after you upgrade and doesn't roll over.

Rentals draw down your free credit first (so it's used before it expires), then your wallet. On-demand GPUs are pay-as-you-go on every plan — including Enterprise — so a card on file and a topped-up balance are what you need to rent, whatever plan you're on.

Auto top-up & balance alerts

So a running rental never stops just because the balance ran dry, an owner can turn on auto top-up under Settings → Billing: choose a balance to watch and an amount, and whenever your available credit drops below that level we charge your saved card by that amount automatically. If a charge is ever declined, we email your owners so they can fix it.

You can also ask us to email you when your balance drops below a level you pick — a heads-up to top up before anything stops. And if a team member without billing access needs more credit, they'll see a Request a top-up button that emails your owners.

Only an owner can add a card, top up, or change these settings — everyone else can see the balance and request a top-up.

Billing

Rented GPUs are billed in whole hours, at the rate shown when you rent. Part-hours are rounded up, so any use at all costs at least one hour, and an instance you stop after 90 minutes is charged for two. Each hour is settled from your credit balance as it's used.

The clock starts when the instance connects to your organisation — not when you click Rent, so time spent booting is free — and stops when you stop the instance. Each hour is deducted from your credit balance as it's used. Each rented worker's page shows its cost so far and uptime, and Settings shows your balance and your total for the month with a per-instance breakdown.

If you need a short burst of GPU time, it's cheaper to run one instance for a continuous stretch than to start and stop several — each rental bills its own first hour.

Rented workers don't count towards your plan's worker limit — they're billed separately by the hour, so you can rent a GPU even if your self-hosted workers already use every slot on your plan.

Stopping an instance

Find the rented worker in your Workers list and open it, then click Stop and confirm. (While it's still starting up you can also stop it from its loading row in the list.) The instance shuts down, the worker disappears from your organisation, and billing ends. A stopped instance can't be restarted — renting is start-fresh each time, so treat anything on the instance as disposable.

Spending limits

Your credit balance is the hard limit: an instance keeps running until you stop it or your credit runs out, and it's stopped automatically the moment the balance reaches zero. There's no fixed maximum runtime — a well-funded instance can run as long as you like.

On top of that, an organisation owner can set two optional soft limits under Settings, and instances are stopped automatically when either is reached:

  • Monthly budget — a cap on total GPU rental spend per calendar month, sitting below your balance. Once reached, running instances stop and new rentals are blocked until the next month (or until you raise the budget).
  • Max runtime per instance — a cap on how long any single instance may run, useful as a forgot-to-stop-it safety net. When one is set, the rent screen shows it so an automatic stop is never a surprise.

Whenever an instance is stopped automatically — because it hit your max runtime, reached your monthly budget, or ran the balance to zero — we email your owners so you always know why a rental ended.

Separately, an instance whose worker never comes online is stopped after about 30 minutes. A healthy rental connects within a few minutes, so one still silent after half an hour isn't going to start — it's shut down rather than left sitting there. You'll see it in the console marked never connected within the provision timeout. Billing only starts when the worker connects, so an instance that never connected costs you nothing; just start another one, and tell us if it happens twice.

Good to know

  • Owners and operators can rent and stop instances; only owners can set spend limits; members can view.
  • A rented worker behaves like any other worker: it appears on the Workers page, you manage its models and settings from its worker page, and its requests show up in Usage as normal.
  • The one thing you don't do by hand is revoke a rented worker's key — Pendra issues it when the instance starts and removes it when you stop the instance, so end a rental with Stop rather than revoking its key by hand.