Skip to main content

Pay-per-Second compute.

Adaptive compute platform for modern workloads. You pay active seconds, not idle.

What is pay-per-second compute?

Pay-per-second is a billing model for compute workloads where you pay only for the seconds your workload actually consumes CPU cycles. Once load drops to zero, the workload pauses automatically — and billing stops.

Unlike classic cloud instances that run 24/7 and bill at full rate even when idle, pay-per-second compute scales with your real usage. Game servers, AI agents, microservices — anything without continuous load benefits measurably.

A typical game server runs 4 hours in the evening and sits idle 168 hours per week. Always-on pricing bills you for all 168 hours. Pay-per-second only for the 28 active hours — about 83% less.

Idle compute is the most expensive compute time there is: you're paying for nothing to happen.

How pay-per-second works

Three steps from account to running workload:

1

Deploy a workload

Pick a container image or modpack, set resources, deploy. Under 60 seconds from click to running service.

2

Scale adaptively

Workload starts on load and pauses on idle. Cluster-grade autoscaling, zero configuration on your end.

3

Bill per second

You see exactly how many active seconds each workload ran. Storage and egress itemized separately.

Billing per started second of active compute. No setup fee, no minimum term.

Pay-per-Second vs. always-on compute

Direct comparison of the two billing models:

FeaturePay-per-Second (xape)Always-on (hyperscaler)
BillingPer active second (from €0.063/h)Fixed monthly or hourly rate
Idle cost€0 — workload pauses automaticallyFull price even at 0% load
ContractNone — cancel anytimeOften 12-month or reserved instances
Cold-start< 60 secondsInstant (workload runs 24/7)
ScalingAutomatic (scale-to-zero to cluster)Manual sizing, often locked in
Data locationEU data centers, GDPR-compliantOften US / unclear
Best forAI agents, game servers, microservicesWorkloads with constant high load

Which workloads are pay-per-second a fit for?

Adaptive compute fits anywhere workloads aren't continuously busy:

🎮

AI agents and LLM backends

An AI agent is idle 95% of the time and only reacts when a user types. Pay-per-second eliminates exactly those idle costs — the agent is back in under a second.

🎮

Game servers (Minecraft, survival)

A friend group plays 4h per evening. At 30h active per month you save up to 85% versus always-on. World and data stay persistent.

🎮

Microservices with bursty load

Webhooks, ETL pipelines, batch workers — anything that runs in bursts and idles between. Scale-to-zero shuts them down automatically.

🎮

Test and staging environments

Staging clusters sit unused at night and on weekends. Pay-per-second pauses them automatically and saves 60-70% of compute cost.

🎉

Event workloads

Conference apps, tournament servers, short-lived demos — run for a few hours, then stop. You pay only the active time.

Cost examples

Concrete numbers for typical workloads:

AI agent (sporadic)
30h/month

Reacts to user requests, idle otherwise

xape:€4.42
24/7:€23.99
82% saved
Game server (friend group)
60h/month

About 2h per evening, 5 evenings per week

xape:€7.84
24/7:€23.99
67% saved
Microservice (regular)
120h/month

Active during the day, idle nights and weekends

xape:€14.68
24/7:€23.99
39% saved

Examples based on the Small plan (4 vCPU, 8 GB RAM, €0.114/h) plus 10 GB storage (€1/month).

Cost calculator

60h
0h150h300h
10GB
Compute time:60h x 0.114€ = 6.84€
Storage:10GB x 0.10€ = 1.00€
xape:7.84€/month
Always-on compute
23.99€
24/7 / month
xape
7.84€
60h / month
You save €16.15 (67%)

Compute your individual savings in the cost calculator →

Pros and cons

Pay-per-second is the right call for many workloads — but not all:

Pros

  • Up to ~85% cost savings on workloads with idle time
  • No contract, no minimum term
  • Per-second billing, transparent per workload
  • EU-hosted, GDPR-compliant
  • Self-service API for automation and CI/CD
  • Adaptive scaling, no manual sizing
  • Cluster-grade infrastructure (Kubernetes, Cilium, KEDA)

Cons

  • Cold-start ~60 seconds for paused workloads
  • More expensive than reserved-instance pricing at constant high load (>500 h/month)
  • Not optimal for always-on public services with constant traffic
  • Stateful components need explicit persistent volumes

If your workload has any idle component — true for >80% of modern workloads — pay-per-second is the more efficient choice.

Frequently asked questions

What happens when load drops to zero?
The workload pauses automatically (scale-to-zero). No more compute cost — only storage. On the next request it restarts within seconds.
How fast is cold-start?
Typically under 60 seconds from first request to response. For latency-sensitive workloads we offer warm-pool configurations.
Is there a monthly cost cap?
Yes. You can set hard caps per workload and per account. The workload pauses on overage instead of running unbounded.
Which container images are supported?
Standard OCI images (Docker). Bring your own image or pick from templates for game servers, AI agents and microservices.
When is pay-per-second not worth it?
If your workload is under load >500 hours/month (close to 24/7), always-on or reserved-instance pricing is usually cheaper.
Where does my compute run?
Exclusively in EU data centers (Hetzner, Germany and Finland). No data leaves the EU.

Ready for pay-per-second?

Create an account and deploy your first workload. Per-second billing, EU-hosted, no contract.

EU-hosted · Self-service API · Per-second billing

Pay-per-Second Compute | xape